An architecture for real-time global multicast session discovery

Transcription

1 An architecture for real-time global multicast session discovery Piyush Harsh 1 Introduction IP multicast is generally better suited for stored multimedia transmission to large subscriber base. The bandwidth savings compared to IP unicast streams becomes increasingly significant with growing subscriber base. Still the level of deployment is negligible. ISPs have been reluctant to deploy multicast on their networks citing network complexity and low end user demand as prime reasons. With the general migration from IGMP (Internet Group Management Protocol) v2 to IGMP v3 and shift in multicast technology from ASM (Any Source Multicast) to SSM (Source Specific Model), much of the complexity will be shifted from network layer (in ASM) to higher layers (in SSM). This will entail greater burden on the end hosts. The source discovery that was done in the network layer (MSDP - Multicast Source Discovery Protocol) must now be done at the end hosts in order for them to be able to receive multicast data. A major stumbling block to widespread multicast deployment remains end-user demand for this technology. Usability plays a significant role in determining acceptance. The popularity of IP unicast is in part due to supporting technologies such as DNS and existence of search engines like Google c that enables content discovery. DNS enables end-users to bookmark popular sites. Further ease of recall due to text based and descriptive URLs (Uniform Resource Locator) plays a major role in improving usability as compared to ciderized / dotted-decimal IP addresses. This white-paper describes a global and hierarchical architecture for multicast session discovery that tries to address few usability concerns described above as well. mdns or DNS aware multicast directory architecture that will be described in next few sections enables end users to discover, in real time, even fleeting and short-lived multicast sessions. In addition it incorporates a naming scheme that enables multicast sessions to be assigned a long term URLs irrespective of critical session parameters that might change with time. It in turn allows even multicast sessions to be book marked just like a typical IP unicast site. mdns also incorporates geocoding capabilities that allows sessions to be tagged using geographical coordinates. This allows for an additional search dimension. mdns allows few interesting applications of multicast to come to light which were not easily conceivable earlier. Those will be described later in the broader impact section of this white-paper. 2 mdns Construction For successful mdns operation, we made few assumptions. Each mdns domain has a functional DNS server. Further it has been assigned a valid FQDN (Fully Qualified Domain Name). Each mdns domain knows the details of it s parent domain (with the exception of the root) Each mdns domain houses a URS (URL Registration Server) and one or more MSD (Multicast Session Directory) server(s). A domain might deploy more than one MSD servers to provide redundancy and robustness in the face of intermittent MSD server failures. The DNS server has an additional record called MCAST that points to the URS server. For instance if a domain s FQDN is cons.cise.ufl.edu., then mcast.cons.cise.ufl.edu. must resolve to URS server in this domain. URS servers also contain the global multicast channels that facilitate MSD servers to communicate with the parent and children MSD servers in the mdns hierarchy. It is recommended that these channels be allotted from the GLOP addressing range (233/8) and hence must be ISP assigned. These global GLOP 1

2 multicast channels are called PMCAST and CMCAST channels in our design. In addition to these channels, we also use an administrative scope multicast channel MCAST for handling session registrations and end users search requests originating from within the domain. Figure 1 shows a typical mdns hierarchy. If multiple MSD servers are installed in a domain, then using leader election algorithm, one of them is chosen as the designated server. Servers with label D in the figure are the designated servers of their respective domain. Using PMCAST and CMCAST channels for respective domains, the designated servers form the global hierarchy among themselves. The architecture uses soft-state parameter refreshes and is inherently robust. If the designated MSD server fails, the backup servers take up its role. mdns design is also immune to different modes of multicast (ASM or SSM) technologies. If pure SSM is to be used, the uplink channels may be replaced by unicast links (downlink via SSM) and mdns would continue to provide the necessary services. In our design we have assumed that port numbers of certain channels and server applications are Figure 1: example mdns hierarchy well known (possibly IANA assigned). Currently we have proposed to use port for MCAST channel ( ) and port 1528 (currently unassigned) for URS server application. Port numbers and IP addresses of other channels are most likely variable as they are under the control of respective ISPs and not necessarily domain administrator s control. Figure 2 shows the typical mdns domain setup. In addition to typical network components, the figure shows the URS server and one MSD server along with several end users and multicast content providers (or multicast sources). URS server s main task is to enforce uniqueness among the registered sessions locator. This unique locator when combined with the network s FQDN creates the globally unique mdns-url which becomes associated with the registrant multicast source (channel). For instance, if a network s FQDN is cons.cise.ufl.edu. and suppose a multicast source (must reside in the same admin-domain as URS server) registers a locator netsec-seminar with the URS server, then because this locator is guaranteed to be unique within cons.cise.ufl.edu., Figure 2: typical mdns domain components the associated mdns-url mcast.cons.cise.ufl.edu/netsec-seminar will be globally unique as well. End users can even bookmark mdns-urls. The architecture has been conceived to associate the mdns- URLs to resolve to the latest multicast channel parameters even though they might have changed since the session locator s registration with the URS server. 3 Managing registration and discovery Multicast session registration is handled by MSD servers. The source sends the registration request on MCAST channel. Regardless of session scope (administrative or local), MSD server stores the session details for all sessions originating in it s domain. Each designated MSD server in a domain also has an additional responsibility of maintaining session details of globally scoped multicast sessions, irrespective of the session origin, for those sessions whose keyword hash value falls in the range assigned to it. This additional requirement helps in efficient search routing to that MSD server which is likely to have the session parameters (if any) for a specific keyword. 2

3 Each MSD servers maintain three cross-referenced data structures - LDB - Local Database - Stores session details originating within it s own domain GDB - Global Database - Stores globally scoped session details whose keyword hash falls under its jurisdiction GeoDB - Geographic Database - Maintains the cross-referenced (with GDB and LDB) session entries depending on their geographical coordinates. In order to maintain data-structure space efficiency, periodically each data structure is traversed and all stale sessions are removed (session that have expired). 3.1 Search routing Each mdns domain MSD designated server keeps a count of sub-domains under it s domain and reports the count on the PMCAST channel towards the parent domain. The leaf domains in the hierarchy just report a value of 1 (includes itself) to their parents. When this count reaches the root domain, it uses the value to divide the hash space proportionately to ensure almost equal hash-range assignments to each designated MSD servers in the hierarchy. The idea being equal workload assignment among designated MSD servers. Since the true workload depends on the keyword frequency distribution among all active sessions, it is hard to a-priori guarantee equal workload distribution. The hash space distribution percolates down from the Figure 3: An example mdns domain tree hierarchy root node towards the leaf nodes. The count reporting upstream is periodic in nature to allow for network hierarchy to change dynamically. Each node in the hierarchy computes the routing table based on the hash range assignment from the parent node and the number of sub-domains below it. The table below shows a sample routing table computed at node A shown in figure 3. Based on this hash routing Table 1: Routing table at node A Hash Start Hash End Channel Out Node ID Is Orphan 0000 xxx...xxx/ xxx...xxx/4 MSD-LOCAL-MCAST Self ID (A) NO 0001 xxx...xxx/ xxx...xxx/4 CMCAST Node B NO 0110 xxx...xxx/ xxx...xxx/4 CMCAST Node C NO 1011 xxx...xxx/ xxx...xxx/4 CMCAST Node D NO 1110 xxx...xxx/ xxx...xxx/4 CMCAST Node E NO scheme, the search requests from end users are routed to the appropriate MSD servers that are responsible for the keywords provided and they return the candidate sessions parameters directly to the end-user search application. 3.2 Session databases in mdns In order to enable search filtering based on a given location and search radius, MSD servers maintain a special database to keep track of sessions and their corresponding geographical coordinates. Level 0 of the database is represented by a sparse matrix representation where each entry corresponds to 1 1 latitude-longitude 3

4 space. Since at equator, 1 1 represents an area km 2, each grid is further subdivided into k k subdivisions where k represents the branching factor. The depth of the tree rooted at each 1 1 position is computed based on the branching factor k and the areal-resolution desired. In fact since the earth is not a perfect sphere, Figure 4: Geo-tagged database design the distance between a degree longitude decreases at the poles but it can be computed mathematically for any given latitude degree. All these factors have been taken into account while implementing the search module for GeoDB data structure. The results are cross referenced with search results obtained by querying LDB and/or GDB and appropriate filtering operations applied before the results are returned back to the end-users. Session creators during registration process are required to provide the physical location of the session. This physical location could be the originating location of the session, or it could be the location information appropriate to the content being multicasted. Together with the keywords provided to describe the session, the location information allows end users to perform session queries not just based on keywords but also location proximity. mdns has provision to allow domain specific search as well. In that case, the search request does not follow the usual hash routing scheme, but arrives directly at the target MSD server using mdns- URL resolution process. The search is only restricted to LDB database because it contains those sessions parameter that originate from within the target domain. After querying the database for candidate sessions, only those sessions whose scope is global are returned to the end user. Sessions that are administratively scoped are not returned because these streams can not cross the domain boundary and hence the querist application can not receive such sessions. 4 Improving usability mdns enables each multicast session to be assigned a globally unique mdns-url. These URLs can be book-marked at the end user site and later on the corresponding session can be joined just by using this URL string. This in itself has the potential to improve multicast usability tremendously as users are spared the trouble of remembering the dotted decimal IP address. Figure 5 shows the essential steps involved in URL resolution. The FQDN portion of the mdns-url is resolved using usual DNS name resolution. This returns the IP address of the URS server (called MCAST in DNS records). Figure 5: mdns URL resolution In the next step, the URS server is contacted and is queried for the session locator. If it is found, the URS server returns the session parameters to the client application. The client application, using the just received session parameters, is now able to join the multicast session. Assume the session in question was a short duration session. After it s lease expires, corresponding session parameters are removed from the MSD servers as well as URS servers in order to conserve space. And the session locator is released as well. Next time the same stream re-registers with the MSD and URS servers, if it uses the same locator keyword, the URL will be mapped to the same stream, even if the session parameters might have changed. The question becomes what if the locator could not be re-registered because someone else used it while the stream was dormant? This scenario can be easily dealt with at the policy enforcement level by the system administrators. We will leave this issue at that for now. Another important aspect of mdns is its delay characteristics. As soon as a session is registered and the session details propagated to appropriate MSD server depending on the hash routing scheme, it becomes 4

5 discoverable by end users in every domain in the hierarchy. This delay characteristic is lot better than tens of minutes or even more delay in any SDP/SAP based approaches and some of the other proposals. This real-time discovery of sessions by end users is most vital for on-the-fly short duration extremely volatile multicast sessions. Keyword based session searches along with location specific query makes life a lot easier for end users. Compare this to the usual long list of sessions one must browse through in order to locate a session of interest (if it exists) in the traditional push based session directory approaches. 5 Usage scenarios and broader impact Consider a massive traffic pileup on a major inter-state highway. A citizen on location could start a video transmission using his mobile device and register his session with mdns and immediately many people from around the world can locate his session. mdns has tremendous potential to usher in a citizens news/eye witness journalism era. Location specific searches would enable people to subscribe to local disaster alert multicast bulletins. Innovative schemes could be devised using multicast that could help emergency rescue workers better manage a disaster zone, including auto discovery of services using multicast beacon schemes. Increase in multicast deployment would free costly bandwidth in traditional networks, which in turn could make other services more cost efficient including VoIP telephony. It has the potential to change how people communicate. Multicast sessions does not need permanently assigned or unique IP unicast addresses, end user can create multimedia transmissions for free. This could enable NGOs to provide life-critical services like tele-medicine sessions with remote physicians who otherwise would not prefer to visit rural areas (for cheap). Hence widespread multicast deployment has far reaching effect in all sphere of human existence and our proposal hopes to achieve just that. 5