idnits 2.17.1 draft-mdns-rfc-informational-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 16, 2009) is 5269 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IP' is mentioned on line 1910, but not defined == Missing Reference: 'Time' is mentioned on line 684, but not defined == Missing Reference: 'URS-Identifier' is mentioned on line 2834, but not defined == Missing Reference: 'Geographic CN' is mentioned on line 1797, but not defined == Missing Reference: 'Lat' is mentioned on line 1882, but not defined == Missing Reference: 'Long' is mentioned on line 1882, but not defined == Missing Reference: '0' is mentioned on line 1836, but not defined == Missing Reference: '0x01' is mentioned on line 1778, but not defined == Missing Reference: '0x03' is mentioned on line 1796, but not defined == Missing Reference: '17' is mentioned on line 1871, but not defined == Missing Reference: '11' is mentioned on line 1881, but not defined == Missing Reference: '0x02' is mentioned on line 1639, but not defined == Missing Reference: '0x09' is mentioned on line 1646, but not defined == Missing Reference: '0x0A' is mentioned on line 1910, but not defined == Missing Reference: '19' is mentioned on line 1195, but not defined == Missing Reference: '0x04' is mentioned on line 1188, but not defined == Missing Reference: '0x08' is mentioned on line 1881, but not defined == Missing Reference: '10' is mentioned on line 1216, but not defined == Missing Reference: '7' is mentioned on line 1238, but not defined == Missing Reference: '6' is mentioned on line 1849, but not defined == Missing Reference: '0x0B' is mentioned on line 1372, but not defined == Missing Reference: '0x07' is mentioned on line 1871, but not defined == Missing Reference: '5' is mentioned on line 1828, but not defined == Missing Reference: 'ID hash' is mentioned on line 1510, but not defined == Missing Reference: 'Geographical CN' is mentioned on line 1872, but not defined == Unused Reference: 'RFC1321' is defined on line 3341, but no explicit reference was found in the text == Unused Reference: 'ICOMP08' is defined on line 3351, but no explicit reference was found in the text == Unused Reference: 'ICOMP09' is defined on line 3355, but no explicit reference was found in the text == Unused Reference: 'SAC09' is defined on line 3358, but no explicit reference was found in the text == Unused Reference: 'RFC1112' is defined on line 3366, but no explicit reference was found in the text == Unused Reference: 'RFC3618' is defined on line 3369, but no explicit reference was found in the text == Unused Reference: 'RFC4601' is defined on line 3372, but no explicit reference was found in the text == Unused Reference: 'RFC1075' is defined on line 3376, but no explicit reference was found in the text == Unused Reference: 'RFC2201' is defined on line 3380, but no explicit reference was found in the text == Unused Reference: 'RFC2236' is defined on line 3383, but no explicit reference was found in the text == Unused Reference: 'RFC3810' is defined on line 3386, but no explicit reference was found in the text == Unused Reference: 'RFC3376' is defined on line 3391, but no explicit reference was found in the text == Unused Reference: 'RFC4607' is defined on line 3395, but no explicit reference was found in the text == Unused Reference: 'RFC3180' is defined on line 3398, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 40 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Harsh 3 Internet-Draft R. Newman 4 Intended status: Informational CISE, University of Florida 5 Expires: May 20, 2010 November 16, 2009 7 A Hierarchical Multicast Session Directory Service Architecture 8 draft-mdns-rfc-informational-00 10 Abstract 12 This document describes a globally scalable and hierarchical approach 13 to multicast session directory service architecture. This approach 14 allows for sessions to be discovered using keywords as soon as they 15 are registered with the system. It allows session registration to be 16 tagged with geographical data to provide location-based search 17 capability to the end users. It is able to assign URI strings to 18 multicast sessions. This document provides a general overview of the 19 architecture and describes the protocol used. The architecture is 20 able to operate in networks supporting either traditional ASM or the 21 newer SSM. 23 Status of this Memo 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on May 20, 2010. 48 Table of Contents 50 1. Definitions and Assumptions . . . . . . . . . . . . . . . . . 3 51 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1. mDNS Domain Components . . . . . . . . . . . . . . . . . . 4 53 2.1.1. URI Registration Server . . . . . . . . . . . . . . . 4 54 2.1.2. Multicast Session Directory Server . . . . . . . . . . 5 55 2.1.3. DNS Server . . . . . . . . . . . . . . . . . . . . . . 6 56 2.1.4. Client Tools . . . . . . . . . . . . . . . . . . . . . 6 57 2.2. Workload Distribution (Key-Space Allotment) . . . . . . . 6 58 2.3. Hierarchy Setup and Maintenance . . . . . . . . . . . . . 7 59 3. Session Records Structure . . . . . . . . . . . . . . . . . . 9 60 3.1. Domain local database session record . . . . . . . . . . . 10 61 3.2. Global session database record . . . . . . . . . . . . . . 12 62 3.3. URS Multicast Session Record . . . . . . . . . . . . . . . 12 63 4. Protocol Message Formats . . . . . . . . . . . . . . . . . . . 13 64 4.1. Common message fields . . . . . . . . . . . . . . . . . . 15 65 4.2. URL Registration Server - Message Formats . . . . . . . . 18 66 4.3. Session Registration Tool - Message Formats . . . . . . . 23 67 4.4. Multicast Session Directory Server - Message Formats . . . 26 68 4.5. End User Search Tool - Message Formats . . . . . . . . . . 38 69 5. Protocol Message Semantics . . . . . . . . . . . . . . . . . . 42 70 5.1. URS Protocol Message Semantics . . . . . . . . . . . . . . 43 71 5.2. Registration (Reg.) Tool Protocol Message Semantics . . . 46 72 5.3. MSD Server Protocol Message Semantics . . . . . . . . . . 48 73 5.4. End User Search Tool Protocol Message Semantics . . . . . 62 74 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 65 75 6.1. Routing Table Management . . . . . . . . . . . . . . . . . 65 76 6.1.1. Protocol Messages and Routing Table . . . . . . . . . 68 77 6.2. Leader Election Algorithm . . . . . . . . . . . . . . . . 70 78 6.3. Node Failures . . . . . . . . . . . . . . . . . . . . . . 70 79 6.4. Data Syncing Among Local MSD servers . . . . . . . . . . . 71 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 72 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 73 83 9.1. Normative References . . . . . . . . . . . . . . . . . . . 73 84 9.2. Informative References . . . . . . . . . . . . . . . . . . 73 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75 86 Intellectual Property and Copyright Statements . . . . . . . . . . 76 88 1. Definitions and Assumptions 90 This section defines some of the terms used throughout this document. 92 o Any Source Multicast (ASM) - Any network that conforms to RFC-1112 93 and supports some shared distribution tree, typically using 94 rendezvous points (RP) based tree, implements MSDP, runs some 95 version of multicast routing protocol such as PIM-SM, DVMPR, CBT, 96 etc., and supports IGMP v 1 or higher or MLD v 1 or greater. 98 o Source Specific Multicast (SSM) - Any network that conforms to 99 RFC-4607 and runs PIM-SM as its multicast protocol, supports IGMP 100 v 3 or MLD v 2, and may or may not implement MSDP or any shared 101 multicast distribution tree. 103 o Network Administrative Domain - Any domain with a managed DNS 104 server and a fully qualified domain name URL string (FQDN) 105 assigned to it. 107 We will assume that the network administrator of any network 108 administrative domain knows the IGMP or MLD protocol version 109 supported by the multicast routers installed in that domain and also 110 knows the FQDN string of its parent domain. 'domain' at several 111 places in this document is also referred as 'node'. Thus 'node' and 112 'domain' is used interchangeably. Also unless explicitly stated 113 otherwise, any reference to MSD server should be read as designated- 114 MSD server. 116 2. Introduction 118 Multicast has long been considered an efficient mechanism for 119 relaying live multimedia streams to multiple receivers. Still the 120 use of this technology is not widespread compared to IP unicast 121 delivery. One of the possible obstacles is the lack of a scalable 122 session discovery service that will enable an end user to search for 123 a session. With IGMP version 3 becoming a standard, and with 124 emerging deployment of SSM capable networks, multicast source 125 discovery is increasingly becoming the responsibility of end users. 126 SSM with IGMP v 3 and MLD v 2 aims to reduce some of the network 127 complexity inherent in the traditional ASM deployment. The purpose 128 of this document is to describe a hierarchical multicast session 129 directory architecture that is globally scalable and which enables 130 user-friendly access to multicast streams. The proposed approach 131 also solves the delay problem between session registration and 132 session discovery by the end users present in some of the alternative 133 solutions. Sessions can now be discovered in real time. Geotagging 134 of registered sessions grants even finer search/query parameter 135 control to the clients. 137 The hierarchy construction is similar to the DNS hierarchy. The 138 architecture is also tightly integrated with the existing DNS service 139 and because of this it supports assignment of a long term URI to each 140 multicast stream. This allows an end user to bookmark multicast 141 sessions just like any normal domain URI. On subsequent occasions, 142 the end user can access the multicast session through the bookmarked 143 URI instead of initiating a fresh search or remembering an IP 144 multicast address. The architecture is capable of translating the 145 URI string and mapping it to the correct multicast session parameters 146 that allow the end user to access the stream. The architecture is 147 also designed for incremental deployment. 149 2.1. mDNS Domain Components 151 Each domain under an mDNS hierarchy must have at least the first 152 three domain components listed below. 154 1. URI Registration Server (URS) 156 2. Multicast Session Directory (MSD) server(s) 158 3. DNS Server 160 4. Client Tools 162 2.1.1. URI Registration Server 164 One of the main tasks of a URS is to enforce uniqueness among the 165 registered session identifier keywords relative to its own domain. 166 Assuming that each domain has a DNS server running and it has a valid 167 FQDN assigned to the network domain, one can construct a unique URI 168 for every multicast session that has a unique identifier registered 169 with the URS. The URI will be relative to the URS server URI. For 170 example, if the FQDN for a domain is dom1.somenetwork.example, and 171 the URS server has an 'A' entry in the DNS server with value 'mcast', 172 then the URI of the URS becomes mcast.dom1.somenetwork.example. 173 Furthermore if a multicast session creator has registered a unique 174 identifier 'netstream' with this URS server, the URI for his 175 multicast stream in this architecture becomes 176 mcast.dom1.somenetwork.example/netstream. In every participating 177 domain there must be a URS installed and operational. 179 A URS also acts as bootstrap node for one or more MSD Servers (see 180 Section 2.1.2) running in that domain that helps the designated MSD 181 server join the mDNS hierarchy. It can also be configured to act as 182 a relay point for intra-domain MSD Server communication to facilitate 183 leader election and data synchronization among multiple MSD servers 184 running in the same domain. 186 System administrators must configure at least these 4 parameters in 187 the URS during startup - 189 1. PMCAST 191 2. CMCAST 193 3. IGMP version support 195 4. URL string of the parent domain, if no root URL exist/specified, 196 then set to 'void' 198 PMCAST is the multicast address for the channel used to receive 199 communication from the parent domain. CMCAST is the multicast group 200 address for this domain to send communication to the children 201 domains. More details on PMCAST and CMCAST are given later in this 202 document. The inclusion of the URL string of the parent domain 203 enables the URS to query the unicast host details of the designated 204 MSD server in that domain, which are needed to subscribe to the 205 PMCAST channel using IGMP v 3. 207 2.1.2. Multicast Session Directory Server 209 Every domain that joins our service hierarchy must have one or more 210 MSD server(s) installed and operational. If multiple MSD servers are 211 installed in a network administrative domain, then they must be 212 capable of running some leader election algorithm. They choose one 213 MSD server to act as designated MSD server (leader) of that domain. 214 Other servers act as standby and can take the role of designated MSD 215 server in case the leader fails. 217 The designated MSD server in a domain is responsible for registering 218 multicast sessions originating in that domain. It also handles 219 session search requests from users in that domain. Additionally it 220 is responsible for maintaining globally scoped multicast session 221 registration records against keywords whose hash values lie in the 222 hash space assigned to this server. The designated MSD server is 223 also responsible for establishing communication links with designated 224 MSD servers in its children domains and its parent domain. Finally, 225 it maintains a correct keyword routing table in order to handle 226 registration and search request forwarding towards the correct 227 domain. 229 2.1.3. DNS Server 231 Proposed approach requires every domain's URS server to have an 'A' 232 entry in the DNS Server database. We suggest using an alias 'mcast' 233 for the URS. This enables a client to resolve the multicast session 234 URI assigned under this scheme. Upon successful resolution, a client 235 has all the pertinent details that allow it to subscribe to the 236 multicast session and start receiving the content stream, if one is 237 active at that time. We suggest that a client should not cache the 238 session details received upon successful URI resolution, as they may 239 change in future. The URI itself could be bookmarked, as we foresee 240 it to be long-lived. 242 2.1.4. Client Tools 244 Several end user clients that work with the service hierarchy can be 245 provided depending on the functionality they support. A session 246 registration tool that allows a session creator to register its 247 session is a must. Tools that allow the intended receivers to search 248 for candidate sessions and receive selected sessions may be provided. 249 These functions may be combined as a single package or they may be 250 implemented as separate packages. 252 2.2. Workload Distribution (Key-Space Allotment) 254 During session registration step, the registrant must provide a few 255 keywords describing the session s/he is trying to register, in 256 addition to other details. These keywords later allow the multicast 257 session to be reported to the end user in case s/he searched for 258 sessions using one of the keywords the registrant provided. 259 Currently the number of keywords that can be assigned to a multicast 260 session is limited to a maximum of 10 keywords. Each keyword is 261 hashed using the MD5 hashing algorithm resulting in a 128 bit hash. 262 This 128 bit hash value is used to route the registration and search 263 queries to an appropriate MSD server. In order to balance the data 264 load at every designated MSD server participating in the service 265 hierarchy, every domain is assigned a fraction of the overall keyword 266 hash space for which the designated MSD server in that domain is 267 responsible for maintaining the session registration database. 269 +-------+ 8 270 |A | 271 +-------+ 272 1 1 | 5 273 +-----------------+-----------------+ 274 | | | 275 +-------+ +-------+ +-------+ 276 |B | |C | |D | 277 +-------+ +-------+ +-------+ 278 1 1 | 1 1 279 +-----------------+--------+--------+-----------------+ 280 | | | | 281 +-------+ +-------+ +-------+ +-------+ 282 |F | |E | |G | |H | 283 +-------+ +-------+ +-------+ +-------+ 285 A simple domain hierarchy. 287 Figure 1 289 Each domain periodically reports to its parent domain. The 290 periodicity of this report is SELF_REPORT_CYCLE_TIME. In the report, 291 the total count of children domains including self is also sent. 292 Refer to Figure 1, the number on top of every domain shows the domain 293 count being reported to the parent domain. This mechanism allows the 294 root node to determine the total count of domains participating in 295 the hierarchy. It uses this information to approportion the overall 296 keyword-hash space among itself and all the children domains. 297 Ignoring the bias introduced by asymmetrical keyword usage frequency, 298 this hash space division mechanism tries to distribute the database 299 load evenly across all the participating domains. 301 2.3. Hierarchy Setup and Maintenance 303 Every MSD server contacts the domain local URS server to discover 304 channel details of three different multicast channels: 306 1. MSD-LOCAL administratively scoped multicast channel (deprecated) 308 2. PMCAST - globally scoped (GLOP) multicast channel 310 3. CMCAST - globally scoped (GLOP) multicast channel 312 If a network domain supports traditional ASM mode of multicast, MSD- 313 LOCAL multicast channel may be used. Its use is deprecated and all 314 the functionality achieved using MSD-LOCAL channel can also be 315 achieved over unicast. MSD-LOCAL multicast channel is 316 administratively scoped. If used, all session registration and 317 search query requests as well as domain local control messages 318 including leader election requests arrive at this multicast channel. 319 Every MSD server in traditional ASM network may subscribe to this 320 channel (deprecated). The use of MSD-LOCAL channel is discouraged as 321 such a communication channel can not be supported in a network that 322 does not support shared distribution tree. 324 PMCAST is an acronym for 'Parent Multicast'. This is a globally 325 scoped multicast channel belonging to the GLOP address range (IPv4). 326 Therefore this address must be obtained from the ISP and configured 327 into the URS server by the system administrator during URS startup. 328 Any communication from the parent domain is received on this 329 multicast channel provided a multicast path exists between the parent 330 and the child domain. 332 CMCAST is an acronym for 'Child Multicast'. This is a globally 333 scoped multicast channel belonging to the GLOP address range. 334 Therefore this address must be obtained from the ISP and configured 335 into the URS server by the system administrator during URS startup. 336 Any communication to the children domains is sent on this multicast 337 channel. 339 Any communication to be sent to the parent domain by the children 340 domains is done via unicast. In the absence of a continuous 341 multicast path from the parent domain to any child node, the top-down 342 (parent to child) communication also resorts to IP unicast (upon 343 notification by the affected child domain). 345 Upon completion of the leader selection algorithm at every domain, 346 the designated MSD server subscribes to the PMCAST multicast channel 347 and uses the CMCAST channel to send any communication to the children 348 domains. In addition it may also subscribe to MSD-LOCAL channel 349 (deprecated). The values of PMCAST and CMCAST channels are set such 350 that the CMCAST channel at the parent domain is same as the PMCAST 351 channel at each child domain. Figure 2 shows a very simple two level 352 hierarchy with two domains, A and B. The CMCAST details at domain A 353 are the same as PMCAST channel at domain B, thus enabling the two 354 domains to form a hierarchy. This scheme is replicated at all the 355 domains thereby allowing multiple domains to join in a large scale 356 global multicast session directory hierarchy. 358 +-----------------------Domain A----+ 359 | +-------+ +-------+ | 360 | |URS | |MSD | | 361 | |Server | |Server | | 362 | +-------+ +-------+ | 363 | | | | 364 | +--------+--------+ | 365 | | | | | 366 | +-------+ O | | 367 | |DNS | /|\ CMCAST | 368 | |Server | | \|/ | 369 | +-------+ / \ V | 370 | User | | 371 +---------------------- | ----+ 372 +---- | ----------------------+ 373 | PMCAST | 374 | | | 375 | +-------+ | +-------+ | 376 Domain |MSD |----+----|DNS | | 377 | |Server | | |Server | | 378 B | +-------+ | +-------+ | 379 | +-------+ | O | 380 | |URS |----+---- /|\ | 381 | |Server | | | | 382 | +-------+ | / \ | 383 | User | 384 +-----------------------------------+ 386 Figure 2 388 3. Session Records Structure 390 Multicast session registration data are maintained as registration 391 records in various databases maintained at MSD and URS servers. In 392 our scheme we make use of three types of records: 394 1. Domain local session database records - part of MSD database 396 2. Global session database records - part of MSD database 398 3. Multicast session records - part of URS database 400 Administratively scoped multicast channels are registered only with 401 the domain local MSD server that operates in the same domain as the 402 multicast channels themselves. No keyword hash based registration 403 routing happens in this case. The URS registers and maintains a 404 record for every multicast session that originates in that domain 405 regardless of the scope of such multicast sessions. In the 406 subsections that follow, any mention of the word in parenthesis 407 (optional) in the record structure must be read as being optional for 408 the session creator to provide the value for that field. Logically, 409 there will be one record for each keyword for each session. How the 410 database is implemented is up to the MSD implementer. The database 411 must be capable of handling geo-specific searches as well. 413 3.1. Domain local database session record 415 As the title suggests the 'Domain local database session record' 416 forms the basic data component of the database used to store the 417 session details of all multicast sessions hosted in a given mDNS 418 domain. 420 o Expiration Time - Time after which session record may be purged 421 from the MSD database 423 o Start Time - Time before which a session may not exist 425 o Keyword - One of possibly several keywords used to tag this 426 session 428 o URS Identifier - Unique session identifier registered with the URS 429 Server 431 o Channel IP - Multicast session IP 433 o Channel Port - Multicast session port 435 o Source IP - if network type is SSM, this IP determines the content 436 host machine 438 o Fail Over Unicast IP - backup unicast stream source IP address 439 (optional) 441 o Fail Over Unicast Port - backup unicast stream port (optional), 442 mandatory if 'Fail Over Unicast IP' is provided, must not be 443 present if 'Fail Over Unicast IP' field is not present. 445 o Channel Scope - Multicast stream scope (global/local) 447 o Geographical Common Name - Common Name of the place associated 448 with the stream 450 o Latitude - Latitude value associated with this session 451 o Longitude - Longitudinal value associated with this session 453 o Network Type - multicast compatibility of the session's hosting 454 network (ASM/SSM) 456 o Stream Type - identifies the type and nature of the multicast 457 stream (optional) 459 o Preferred Application - Identifies the suggested application to be 460 used to access the stream data (optional) 462 o Command Line Interface Arguments (CLI) - arguments to be supplied 463 to the preferred application (optional) 465 o Mime Type - MIME type of the stream data (optional), must be one 466 of the IANA registered MIME types 468 The keyword, application name, and stream type in this scheme can 469 contain only alpha-numeric symbols or the underscore character, and 470 must begin with an alphabetic character. The maximum size of any 471 keyword is limited to 32 characters. Expiration time is the absolute 472 CPU time in seconds. Stream Type currently could be one of these 473 possible values: 475 NULL if type not specified 477 OTHER@value - 'value' is string literal describing the session 479 Text Stream 481 Video Stream 483 Audio Stream 485 Audio/Video Stream 487 Conference 489 Whiteboard 491 Disaster Alert 493 Weather Alert 495 Network Alert 497 Before storing/transmitting the stream type, preferred application 498 and CLI arguments, their values are cleansed using character stuffing 499 where any occurrences of SPACE character [' '] or a new line 500 character [\n] must be replaced with their HTML number codes [1] of 501 the form [&#..;]. For example, a SPACE character [' '] must be 502 replaced with 504 3.2. Global session database record 506 This record structure describes the format of database element stored 507 in the global session database. This database is used to store 508 details of sessions whose keywords lie in the hash space assigned to 509 an MSD server. Logically, there will be one record for each keyword 510 for each session. How the database is implemented is up to the MSD 511 implementer. 513 o Keyword 515 o URI - URI of the URS server in the domain of the MSD server where 516 the registration request was originated 518 o URS Identifier 520 o Expiration Time 522 o Latitude 524 o Longitude 526 o Network Type 528 o Stream Type 530 o Inversion Flag - this flag denotes whether the keyword hash- 531 validity for storage is determined using regular MD5 hash value or 532 the value computed using bit-inverted hash value 534 The URI string must begin with the alias 'A' entry value for the URS 535 server. We suggest using 'mcast'. Refer to Section 3.1 for details 536 on record elements already mentioned there. 538 3.3. URS Multicast Session Record 540 URS multicast session records help in resolution of an mDNS URI 541 assigned to a multicast session. If a receiver uses a bookmarked 542 mDNS URI string to access a session, the URI resolves to a URS server 543 and the URS identifier part of the URI is used to locate the relevant 544 multicast session record. This contains all necessary parameters for 545 the client to join the multicast group and start receiving the stream 546 data. The records structure is almost same as Section 3.1 with minor 547 differences. Elements from Section 3.1 that are NOT maintained as 548 part of a URS multicast session record are: 550 o Start Time 552 o Keyword 554 See Section 3.1 for details of URS database record elements and their 555 usage. 557 4. Protocol Message Formats 559 The proposed multicast session directory service uses both unicast as 560 well as multicast to send/receive protocol messages. These messages 561 can be broadly categorized into two types: 563 o Data messages - related to end user activity and multicast 564 sessions 566 o Control messages - used in establishment, maintenance, and upkeep 567 of service hierarchy 569 Unicast messages are transmitted using TCP or UDP datagrams. The 570 specified protocol will be clearly stated in this document wherever 571 necessary. The protocol messages are made of US-ASCII character 572 streams unless otherwise stated. Each message component is separated 573 from others using a single SPACE character and every protocol message 574 ends with a new line character [\n]. Further every message component 575 in this document will be enclosed within square brackets [ ... ] for 576 representation clarity, the square brackets [ ] do not themselves 577 form part of the actual protocol field. Protocol fields are case- 578 insensitive unless otherwise noted. Any occurrence of a space 579 character [' '] or a new line character [\n] within a protocol field 580 must be replaced with their HTML number codes of the form [&#..;]. 581 In the situation where the HTML number codes for SPACE and [\n] 582 themselves appear in the protocol variable, they must be character 583 stuffed by inserting their corresponding duplicate codes. 585 Protocol messages before being processed by the corresponding mDNS 586 network components must be converted to all lowercase symbols. 588 Major network components are: 590 1. URL Registration Server 592 2. Session Registration Tool 593 3. Multicast Session Directory Server 595 4. End User Search Tool 597 Protocol messages' syntax for the above components are presented 598 next. The message purpose and actions (semantics) will be described 599 in Section 5. 601 Wherever MD5 hash is mentioned, we will assume the big-endian 602 representation of the hash value is used so that the most significant 603 bit is stored in the leftmost bit position. 128 bits of hash output 604 will always be represented as 32 bytes of hexadecimal representation 605 as a US-ASCII string. 607 Every protocol field is constructed/interpreted using the US-ASCII 608 character set unless otherwise stated. Every protocol message 609 described next is of the form: 611 [Message Type] [Message Direction] [Number of Fields] [variable 612 part][\n]. 614 [Message Type] is the constant string literal that specifies the type 615 of the protocol message. Refer to Table 1, Table 2, Section 4.4, and 616 Table 4 for list of various [Message Type] values. 618 [Message Direction] field is a 1 byte long field that contains the 619 message transmission direction information. This value is 620 interpreted as a binary value and not as US-ASCII encoded string 621 literal. This field is set according to the rules described below: 623 0x00 : Client to MSD Server - sent on MSD-LOCAL multicast channel 625 0x01 : Client to URS Server - unicast 627 0x02 : MSD Server to URS Server - unicast 629 0x03 : URS Server to Client - unicast 631 0x04 : MSD Server to MSD Server - sent on MSD-LOCAL channel 633 0x05 : URS Server to URS Server - unicast 635 0x06 : MSD Server to MSD Server - sent on CMCAST channel 637 0x07 : MSD Server to Client - unicast (UDP) 638 0x08 : MSD Server to Client - unicast 640 0x09 : URS Server to MSD Server - unicast 642 0x0A : Client to MSD Server - unicast 644 0x0B : MSD Server to MSD Server - unicast 646 0x0C - 0xFF : Reserved 648 [Number of Fields] protocol field denotes the count value of total 649 number of variable message fields that follows after this field. It 650 is represented as an US-ASCII encoded decimal number. This count 651 excludes the mandatory [\n] terminating character. 653 [variable part] represents the 0 or more SPACE delimited protocol 654 fields present in a protocol message. This is governed by the 655 [Message Type] field. 657 4.1. Common message fields 659 Before describing the protocol syntax for various network components, 660 we list here some of the frequently used protocol elements and their 661 syntax and meaning. 663 Syntax for IP addresses including [channel IP], [unicast IP], 664 [source IP], [IP], and [msd IP] will be governed by the syntax 665 specification for [IP address] given below. Syntax for any time 666 representations including [expiration time] and [start time] 667 fields will be governed by the syntax specification for [Time] 668 given below. Syntax for all the port values including [unicast 669 port], [msd port], [client port], [port], and [cached port] will 670 be governed by the syntax specification for [port] given below. 671 The syntax for keyword specified by [keyword] or for each 672 individual \ keywords specified in [keyword list] is governed by 673 the syntax specification for [keyword] specified below. 675 [IP address] represents the dotted-decimal IP (IPv4) addresses or 676 colon (:) separated IPv6 addresses. This parameter if not 677 provided must be set to 0.0.0.0. If IPv6 addressing is used, it 678 is represented as US-ASCII encoding of eight groups of four 679 hexadecimal digits, where each group is separated by a colon (:). 680 If no value is provided - IPv6 value must be set to 681 '0:0:0:0:0:0:0:0'. The maximum allowed size of this field is 16 682 bytes (IPv4) or 40 bytes (IPv6). 684 [Time] represents the US-ASCII encoded UNIX time. It is the 685 elapsed time in seconds since midnight Jan 1, 1970. 687 [port] represents the US-ASCII representation of the port value. 688 If not set - the value is set to 0000 - four zeroes. The maximum 689 allowed size is 8 bytes (no comma ',' allowed). 691 [char-set] represents the character encoding standard that is used 692 to interpret the [URS-Identifier], [keyword] and [keyword list] 693 fields. It can be up to 16 bytes long and must be an IANA 694 registered character set [2]. Wherever available a preferred MIME 695 name must be used. If preferred MIME name is not defined, then an 696 MIB number may be used. [RFC1345] [RFC3808] 698 [keyword] can be up to 32 bytes long. Interpretation of keywords 699 are governed by [char-set]. Keywords must not contain any SPACE 700 [' '] or comma (,) or (&) or (%) or (:) characters in them. 702 [channel IP] represents the multicast channel group IP address. 704 [channel port] represents the US-ASCII representation of the 705 multicast group port value. The maximum allowed size is 8 bytes 706 (no comma ',' allowed). 708 [Geographic CN] represents the common name for the geographical 709 location associated with the channel. Generally this will be the 710 US-ASCII encoded city name. SPACE in the name must be replaced by 711 (_) an underscore character. 713 [Lat] represents the US-ASCII representation of the latitude in 714 the floating point decimal-degrees format [3]. 716 [Long] represents the US-ASCII representation of the longitude in 717 the floating point decimal-degrees format [3]. 719 [unicast IP] represents the dotted-decimal fail-over unicast IP 720 address for the multicast channel. This field is optional. 722 [unicast port] represents the fail-over unicast stream port value. 723 This field is optional but must be provided if [unicast IP] value 724 has been provided. 726 [channel scope] represents the scope of the multicast channel. 727 Must be either "local" or "global". 729 [URS-Identifier] is the registered unique session identifier whose 730 session details are being sought. It can be up to 32 bytes long 731 and must not contain any SPACE character. Its interpretation is 732 governed by [char-set] value. 734 [network type] represents the nature of multicast supported at the 735 content host. The value must be "asm" or "ssm". 737 [source IP] represents the IP address of the host machine. 739 [start time] represents the time before which the multicast 740 session may not exist. 742 [expiration time] represents the time after which the multicast 743 session record may be erased. 745 [preferred application] if set represents the name of the target 746 application of the client machine that should be used to access 747 this multicast stream. It is set to 'null' if the value is not 748 set by the content creator. It can be maximum of 32 US-ASCII 749 bytes long. The interpretation of this field is left up to the 750 implementers. 752 [CLI argument] is the optional command line argument that could be 753 supplied to the [preferred application] for accessing this 754 multicast stream. It must be US-ASCII encoded. Any occurrence of 755 SPACE or [\n] character must be replaced by the HTML number codes 756 of the form [&#..;]. In the scenario where the HTML number codes 757 for SPACE [' '] and [\n] themselves appear in the [CLI argument], 758 they must be character stuffed by inserting their corresponding 759 duplicate codes. The maximum allowable size for [CLI argument] is 760 128 bytes including any stuffed characters. 762 [mime-type] represents the MIME encoding of the multicast stream. 763 It may be used by the receiving application to interpret the 764 stream correctly. This protocol field is optional. The value 765 must be one of the IANA registered MIME types [4]. If this value 766 is not set, then this value is set to 'null', US-ASCII 767 representation of the word 'null'. 769 [stream type] describes the nature of the multicast session data 770 stream. It is set to 'null' if the value is not set by the 771 session creator. It can take one of these possible values: 773 null 774 text_stream 776 video_stream 778 audio_video_stream 780 conference 782 whiteboard 784 disaster_alert 786 weather_alert 788 network_alert 790 other@[value] 792 If [stream type] 'other' is set then [value] after @ specifies the 793 type of the session. [value] must not contain any SPACE or [\n] 794 character in it. This [stream type] field can be a maximum of 32 795 US-ASCII bytes long. 797 4.2. URL Registration Server - Message Formats 799 +-----------------------+--------------+-----------+----------------+ 800 | Message Type | Message | Number of | Variable | 801 | | Direction | Fields | Parameters | 802 +-----------------------+--------------+-----------+----------------+ 803 | bye | 0x01 0x02 | 0 | none | 804 | | 0x03 0x05 | | | 805 | | 0x09 | | | 806 | query | 0x01 | 2 | see details | 807 | query-response | 0x03 | 1 | null | 808 | query-response | 0x03 | 17 | see details | 809 | check | 0x01 | 2 | see details | 810 | check-response | 0x03 | 1 | true / false | 811 | register | 0x01 | 17 | see details | 812 | register-status | 0x03 | 1 | true / false | 813 | request | 0x01 0x02 | 1 | mcast_param / | 814 | | 0x05 | | designated | 815 | request-response | 0x03 0x05 | 11 or 3 | see details | 816 | | 0x09 | | | 817 | unicast-update | 0x02 | 3 | see details | 818 | unicast-update-status | 0x09 | 1 | true / false | 819 | resync | 0x02 | 0 | none | 820 | resync-status | 0x09 | 1 or 3 | see details | 821 +-----------------------+--------------+-----------+----------------+ 822 Summary of [message types] and possible [message direction] values 823 for a URS server. 825 Table 1 827 Table 1 shows the summary of all the message types processed by any 828 URS server. We present the detailed syntax of each of the protocol 829 messages next. Wherever the fields [true] or [false] appear, they 830 stand for the US-ASCII encoding of words 'true' and 'false'. 832 4.2.1. bye 834 [bye] [message direction] [0][\n] 836 See Table 1 for possible [message direction] values. 838 4.2.2. query 840 [query] [0x01] [2] [char-set] [URS-Identifier][\n] 842 See Section 4.1 for more details on the interpretation of the fields. 844 4.2.3. query-response 846 URS server could send two types of [query-response] protocol 847 messages. Both are described next. 849 4.2.3.1. query-response - type 1 851 [query-response] [0x03] [1] [null][\n] 853 [null] is US-ASCII representation of the word 'null'. 855 4.2.3.2. query-response - type 2 857 [query-response] [0x03] [17] [char-set] [channel IP] [channel port] 858 [Geographic CN] [Lat] [Long] [unicast IP] [unicast port] [channel 859 scope] [URS-Identifier] [expiration time] [network type] [source IP] 860 [stream type] [preferred application] [CLI argument] [mime-type][\n] 862 See Section 4.1 for more details on the interpretation of the 863 commonly used message fields. 865 4.2.4. check 867 [check] [0x01] [2] [char-set] [keyword][\n] 869 See Section 4.1 for more details on the interpretation of the fields. 871 [keyword] represents the element that is to be checked against all 872 registered URS-Identifiers so find whether this value can be 873 registered as an URS-Identifier. 875 4.2.5. check-response 877 [check-response] [0x03] [1] [true][\n] 879 [check-response] [0x03] [1] [false][\n] 881 4.2.6. register 883 [register] [0x01] [17] [char-set] [expiration time] [URS-Identifier] 884 [channel IP] [channel port] [unicast IP] [unicast port] [channel 885 scope] [Geographic CN] [Lat] [Long] [network type] [source IP] 886 [stream type] [preferred application] [CLI argument] [mime-type][\n] 888 See Section 4.1 for more details on the interpretation of the 889 commonly used message fields. 891 4.2.7. register-status 893 [register-status] [0x03] [1] [true][\n] 895 [register-status] [0x03] [1] [false][\n] 897 4.2.8. request 899 URS server can handle two kinds of [request] messages, both are 900 described next. 902 4.2.8.1. request - type 1 904 [request] [message-direction] [1] [mcast_param][\n] 906 4.2.8.2. request - type 2 908 [request] [message-direction] [1] [designated][\n] 910 See Table 1 for possible [message direction] values. 912 4.2.9. request-response 914 MSD server can return two kinds of [request-response] messages, both 915 are discussed next. 917 4.2.9.1. request-response - type 1 919 [request-response] [message-direction] [11] [mcast_param] [cmcast IP] 920 [cmcast port] [pmcast IP] [pmcast port] [pmcast source IP] [msd-local 921 IP] [msd-local port] [msd IP] [msd port] [IGMP version][\n] 923 See Table 1 for possible [message direction] values. 925 [mcast_param] is the US-ASCII representation of the string constant 926 'mcast_param'. 928 [cmcast IP] is the child multicast channel IP address. 930 [cmcast port] is the US-ASCII representation of the child multicast 931 channel port value. 933 [pmcast IP] is the parent multicast channel IP address. 935 [pmcast port] is the US-ASCII representation of the parent multicast 936 channel port value. 938 [pmcast source IP] is the unicast IP of the designated MSD server in 939 the parent domain. 941 [msd-local IP] is the MSD-LOCAL multicast channel IP address. This 942 field is deprecated. 944 [msd-local port] is the US-ASCII representation of the MSD-LOCAL 945 channel port value. This field is deprecated. 947 [msd IP] is the unicast server IP running at the designated MSD 948 server in that domain. 950 [msd port] is the port value of the unicast server running at the 951 designated MSD server in that domain. 953 [IGMP version] tells the IGMP version supported by the network 954 multicast routers in this domain. This value could be 1, 2, or 3. 956 4.2.9.2. request-response - type 2 958 [request-response] [message-direction] [3] [designated] [msd IP] [msd 959 port][\n] 961 See Table 1 for possible [message direction] values. 963 [designated] is the US-ASCII representation of the string constant 964 'designated'. 966 [msd IP] is the unicast server IP running at the designated MSD 967 server in this domain. 969 [msd port] is the port value of the unicast server running at the 970 designated MSD server in thais domain. 972 4.2.10. unicast-update 974 [unicast-update] [0x02] [3] [idhash] [msd IP] [msd port][\n] 976 [idhash] is the US-ASCII representation of the unique ID of the MSD 977 server sending this message. The maximum size of this field could be 978 32 bytes. This is generally set to the MD5 hash of the MSD domain 979 URI string represented as hexadecimal US-ASCII encoded character 980 string of 32 bytes. 982 [msd IP] is the unicast server IP running at the designated MSD 983 server in that domain. 985 [msd port] is the port value of the unicast server running at the 986 designated MSD server in that domain. 988 4.2.11. unicast-update-status 990 [unicast-update-status] [0x09] [1] [true][\n] 992 [unicast-update-status] [0x09] [1] [false][\n] 994 4.2.12. resync 996 [resync] [0x02] [0][\n] 998 4.2.13. resync-status 1000 URS server can send two kinds of [resync-status] protocol messages. 1001 Both are described below - 1003 4.2.13.1. resync-status - type 1 1005 [resync-status] [0x09] [1] [false][\n] 1007 4.2.13.2. resync-status - type 2 1009 [resync-status] [0x09] [3] [true] [msd IP] [msd port][\n] 1011 [msd IP] is the unicast server IP running at the designated MSD 1012 server in that domain. 1014 [msd port] is the port value of the unicast server running at the 1015 designated MSD server in that domain. 1017 4.3. Session Registration Tool - Message Formats 1019 Table 2 shows the summary of all the message types processed by any 1020 session registration tool. The detailed syntax of each of the 1021 protocol messages is given in the following sub-sections. Wherever 1022 the fields [true] or [false] appear, they stand for the US-ASCII 1023 encoding of words 'true' and 'false'. 1025 +------------------+----------------+-------------+-----------------+ 1026 | Message Type | Message | Number of | Variable | 1027 | | Direction | Fields | Parameters | 1028 +------------------+----------------+-------------+-----------------+ 1029 | bye | 0x01 0x03 0x08 | 0 | none | 1030 | | 0x0A | | | 1031 | check | 0x01 | 2 | see details | 1032 | check-response | 0x03 | 1 | true / false | 1033 | register | 0x0A 0x01 | 19 or 17 | see details | 1034 | register-status | 0x03 0x08 | 1 | true / false | 1035 | request | 0x01 | 1 | designated | 1036 | request-response | 0x03 | 3 | see details | 1037 +------------------+----------------+-------------+-----------------+ 1039 Summary of [message types] and possible [message direction] values 1040 handled by a client session registration tool. 1042 Table 2 1044 4.3.1. bye 1046 [bye] [message direction] [0][\n] 1048 Refer to Table 2 for possible values of [message direction] field. 1050 4.3.2. check 1052 [check] [0x01] [2] [char-set] [keyword][\n] 1054 See Section 4.1 for more details on the interpretation of the fields. 1056 [keyword] represents the element that is to be checked against all 1057 registered URS-Identifiers so find whether this value can be 1058 registered as an URS-Identifier. 1060 4.3.3. check-response 1062 [check-response] [0x03] [1] [true][\n] 1064 [check-response] [0x03] [1] [false][\n] 1066 4.3.4. register 1068 Session registration tool has to process two different types of 1069 [register] protocol messages, both are described next. 1071 4.3.4.1. register - type 1 1073 [register] [0x0A] [19] [char-set] [expiration time] [start time] [URS 1074 Identifier] [channel IP] [channel port] [unicast IP] [unicast port] 1075 [channel scope] [Geographic CN] [Lat] [Long] [keyword list] [network 1076 type] [source IP] [stream type] [preferred application] [CLI 1077 argument] [mime-type][\n] 1079 See Section 4.1 for more details on the interpretation of the 1080 commonly used message fields. 1082 [start time] represents the time before which the multicast session 1083 may not exist. 1085 [keyword list] is the comma (,) separated list of keywords provided 1086 by the session creator to tag the multicast session. Up to a total 1087 of 10 keywords are allowed. 1089 4.3.4.2. register - type 2 1091 [register] [0x01] [17] [char-set] [expiration time] [URS-Identifier] 1092 [channel IP] [channel port] [unicast IP] [unicast port] [channel 1093 scope] [Geographic CN] [Lat] [Long] [network type] [source IP] 1094 [stream type] [preferred application] [CLI argument] [mime-type][\n] 1096 See Section 4.1 for more details on the interpretation of the 1097 commonly used message fields. 1099 4.3.5. register-status 1101 [register-status] [message-direction] [1] [true][\n] 1103 [register-status] [message-direction] [1] [false][\n] 1105 Refer to Table 2 for possible values of [message direction] field. 1107 4.3.6. request 1109 [request] [0x01] [1] [designated][\n] 1111 [designated] is the US-ASCII representation of the string constant 1112 'designated'. 1114 4.3.7. request-response 1116 [request-response] [0x03] [3] [designated] [msd IP] [msd port][\n] 1118 [designated] is the US-ASCII representation of the string constant 1119 'designated'. 1121 [msd IP] is the unicast server IP running at the designated MSD 1122 server in that domain. 1124 [msd port] is the port value of the unicast server running at the 1125 designated MSD server in that domain. 1127 4.4. Multicast Session Directory Server - Message Formats 1129 +---------------------+----------+--------+-------------+-----------+ 1130 | Message Type | Directio | No. of | Variable | Category | 1131 | | n Bits | Fields | Parameters | | 1132 +---------------------+----------+--------+-------------+-----------+ 1133 | register | 0x0A | 19 | ... | user/data | 1134 | register-status | 0x08 | 1 | true/false | user/data | 1135 | remote-register | 0x06 | 10 | ... | user/data | 1136 | | 0x0B | | | | 1137 | invalidate | 0x0A | 7 | ... | user/data | 1138 | msd-probe | 0x06 | 6 | ... | user/data | 1139 | | 0x0B | | | | 1140 | msd-probe-reply | 0x0B | 5 | ... | user/data | 1141 | search | 0x0A | 3 | ... | user/data | 1142 | redirect | 0x07 | 5 | ... | user/data | 1143 | hello | 0x0B | 5 | ... | control | 1144 | rep-hello | 0x06 | 3 | ... | control | 1145 | | 0x0B | | | | 1146 | unicast-update | 0x02 | 3 | ... | control | 1147 | unicast-update-stat | 0x09 | 1 | true/false | control | 1148 | us | | | | | 1149 | dsearch | 0x0A | 2 | ... | user/data | 1150 | bye | 0x02 | 0 | none | user/data | 1151 | | 0x08 | | | | 1152 | | 0x09 | | | | 1153 | | 0x0A | | | | 1154 | ext-search | 0x0A | 5 | ... | user/data | 1155 | null-space | 0x06 | 1 | ID-Hash | control | 1156 | | 0x0B | | | | 1157 | add-space | 0x06 | 4 | ... | control | 1158 | | 0x0B | | | | 1159 | ext-search-invalid | 0x08 | 2 | ... | user/data | 1160 | search-response | 0x07 | 11 or | ... | user/data | 1161 | | | 17 | | | 1162 | ext-search-response | 0x08 | 11 | ... | user/data | 1163 | tx-end | 0x07 | 3 | ... | user/data | 1164 | | 0x08 | | | | 1165 | resync | 0x02 | 0 | none | control | 1166 | resync-status | 0x09 | 1 or 3 | ... | control | 1167 | request | 0x02 | 1 | mcast_param | control | 1168 | request-response | 0x09 | 11 | ... | control | 1169 | get-backup-msd | 0x0A | 4 | ... | user/data | 1170 +---------------------+----------+--------+-------------+-----------+ 1172 [message types] and [message direction] values used at an MSD server. 1174 Table 3 1176 MSD servers handle the majority of protocol messages. For 1177 convenience we have clubbed these messages under two categories 1178 namely: 1180 o Control messages - protocol messages that are used in construction 1181 and maintenance of the global service hierarchy. 1183 o Data / User messages - protocol messages dealing with user 1184 activity including session registration, query, etc. 1186 The use of MSD-LOCAL multicast channel for communication among intra- 1187 domain mDNS components is discouraged (deprecated). Any protocol 1188 message that is sent with [message-direction] bits set to [0x04] is 1189 deprecated. We present the detailed syntax of each of the protocol 1190 messages next. Wherever the fields [true] or [false] appear, they 1191 stand for the US-ASCII encoding of words 'true' and 'false'. 1193 4.4.1. register 1195 [register] [0x0A] [19] [char-set] [expiration time] [start time] [URS 1196 Identifier] [channel IP] [channel port] [unicast IP] [unicast port] 1197 [channel scope] [Geographic CN] [Lat] [Long] [keyword list] [network 1198 type] [source IP] [stream type] [preferred application] [CLI 1199 argument] [mime-type][\n] 1201 See Section 4.1 for more details on the interpretation of the 1202 commonly used message fields. 1204 [keyword list] is the comma (,) separated list of keywords provided 1205 by the session creator to tag the multicast session. Up to a total 1206 of 10 keywords are allowed. 1208 4.4.2. register-status 1210 [register-status] [0x08] [1] [true][\n] 1212 [register-status] [0x08] [1] [false][\n] 1214 4.4.3. remote-register 1216 [remote-register] [message-direction] [10] [char-set] [URS- 1217 Identifier] [keyword] [host URI] [expiration time] [Lat] [Long] 1218 [network type] [stream type] [inversion flag][\n] 1220 Refer to Table 3 for possible values of [message direction] field. 1222 See Section 4.1 for more details on the interpretation of the 1223 commonly used message fields. 1225 [keyword] is that keyword for which the MD5 hash routing resulted in 1226 registration to be forwarded to a domain external to the originating 1227 mDNS domain. 1229 [host URI] is the URI string of the URS server in the original domain 1230 where the session registration request was first sent. 1232 [inversion flag] must be set to 'true' or 'false'. This represents 1233 whether the message routing is to be done based on actual [keyword] 1234 hash value or using inverted bits of the hash value. 1236 4.4.4. invalidate 1238 [invalidate] [0x0A] [7] [char-set] [keyword] [cached IP] [cached 1239 port] [IP] [port] [inversion flag][\n] 1241 See Section 4.1 for more details on the interpretation of the 1242 commonly used message fields. 1244 [keyword] represents the cached remote MSD server's entry at the 1245 domain local MSD server cache that has to be invalidated. 1247 [cached IP] is the unicast IP address of the remote MSD server that 1248 has to be invalidated. 1250 [cached port] is the port value of the unicast server running at the 1251 remote MSD server whose cached value is to be invalidated. 1253 [IP] is the unicast IP address of the client that requested this 1254 invalidation. This is the IP address where the new MSD connection 1255 details are to be sent once the cached entry is refreshed. 1257 [port] is the port value of the unicast server running at the client 1258 that requested the cache invalidation. This forms the part of the 1259 reply-back address for sending the new MSD connection details to the 1260 requesting client. 1262 [inversion flag] must be set to 'true' or 'false'. This represents 1263 whether the regular MSD server cache entry has to be invalidated or 1264 the inversion-cache entry has to be invalidated. 1266 4.4.5. msd-probe 1268 [msd-probe] [message-direction] [6] [char-set] [keyword] [msd IP] 1269 [msd port] [hop count] [inversion flag][\n] 1271 Refer to Table 3 for possible values of [message direction] field. 1273 See Section 4.1 for more details on the interpretation of the 1274 commonly used message fields. 1276 [keyword] represents the session keyword for which the target MSD 1277 connection details are being sought. 1279 [msd IP] is the IP address of the MSD server where the [invalidate] 1280 protocol message was originally received. 1282 [msd port] is the port value of the unicast server running at the MSD 1283 server where the [invalidate] protocol message was originally 1284 received. 1286 [hop count] is the US-ASCII representation of the number of domains 1287 traversed so far from the mDNS domain where this [msd-probe] message 1288 originated. 1290 [inversion flag] must be set to 'true' or 'false'. This represents 1291 whether the message routing is to be done based on actual [keyword] 1292 hash value or using inverted bits of the hash value. 1294 4.4.6. msd-probe-reply 1296 [msd-probe-reply] [0x0B] [6] [char-set] [keyword] [msd IP] [msd port] 1297 [hop count] [inversion flag][\n] 1299 See Section 4.1 for more details on the interpretation of the 1300 commonly used message fields. 1302 [keyword] represents the session keyword for which the target MSD 1303 connection details are being sought. 1305 [msd IP] is the unicast address of the designated MSD server that 1306 generates this protocol message. 1308 [msd port] is the port value of the unicast server running at the 1309 designated MSD server that generates this protocol message. 1311 [hop count] is the US-ASCII representation of the number of domains 1312 traversed so far from the mDNS domain where the [msd-probe] message 1313 originated that resulted in generation of this protocol message. 1315 [inversion flag] must be set to 'true' or 'false'. This value is 1316 simply copied from the original [msd-probe] protocol message. 1318 4.4.7. search 1320 [search] [0x0A] [3] [char-set] [parameter] [client port][\n] 1322 See Section 4.1 for more details on the interpretation of the 1323 commonly used message fields. 1325 [parameter] refers to the search parameter string. The format of the 1326 parameter string can be described using BNF regular expression - 1328 keyword(:keyword)*(&keyword(:keyword)*)*%local-scope:global-scope 1329 (%lat:long%radius)? 1331 Any occurrence of [:] is the US-ASCII representation of COLON 1332 character, [&] is the US-ASCII encoding for AMPERSAND and [%] is the 1333 US-ASCII encoding for PERCENT symbol in the [parameter] field. local- 1334 scope is set to 'yes' if administratively scoped sessions are to be 1335 included in the search result otherwise it must be set to 'no'. 1336 Similarly 'yes' or 'no' must be set for the global-scope placeholder 1337 in the [parameter] element. At least one must be set 'yes'. lat and 1338 long represents the US-ASCII encoding of the latitude and longitude 1339 values (represented as a floating point number) of the search 1340 epicenter and radius is the search radius from the epicenter in 1341 kilometers (km). lat, long, and radius [parameter] sub-components are 1342 optional. Any keyword must be interpreted using the syntax rules for 1343 [keyword] already described above 1345 [client port] is the port value of the unicast server running at the 1346 client that can be used to send locally scoped and other search 1347 results from the domain local MSD server asynchronously and in a non- 1348 blocking manner. 1350 4.4.8. redirect 1352 [redirect] [0x07] [5] [char-set] [keyword] [msd IP] [msd port] [hop 1353 count][\n] 1355 See Section 4.1 for more details on the interpretation of the 1356 commonly used message fields. 1358 [keyword] is the search keyword whose MD5 hash lies beyond the hash- 1359 space managed by the client's domain local MSD server. 1361 [msd IP] is the unicast address of the target MSD server that manages 1362 the hash space in which the [keyword] hash lies. 1364 [msd port] is the port value of the unicast server running at the 1365 target MSD server. 1367 [hop count] is the US-ASCII encoded number that represents the count 1368 of domain traversed including the current MSD domain. 1370 4.4.9. hello 1372 [hello] [0x0B] [5] [domain count] [ID hash] [msd IP] [msd port] 1373 [pmcast status][\n] 1375 [domain count] is the US-ASCII encoded number that represents the 1376 count of domains rooted at the reporting domain including itself to 1377 be sent to the parent node. 1379 [ID hash] is the 32 byte US-ASCII encoded hexadecimal string 1380 representing the unique ID assigned to the reporting domain. 1382 [msd IP] is the unicast IP address of the designated MSD server 1383 sending this protocol message. 1385 [msd port] is the port number of the unicast server running at the 1386 designated MSD server. 1388 [pmcast status] is set to 'true' if the child domain is receiving 1389 communications from the parent MSD server on its PMCAST channel. If 1390 no communication is received on this channel for 2 timeout intervals 1391 (60 seconds) this parameter is set to 'false' to notify the parent 1392 node of failure to receive any communication on the child node's 1393 PMCAST channel. 1395 4.4.10. rep-hello 1397 [rep-hello] [message direction] [3] [ID hash] [address start] 1398 [address end][\n] 1400 Refer to Table 3 for possible values of [message direction] field. 1402 [ID hash] is the 32 byte US-ASCII encoded hexadecimal string 1403 representing the unique ID assigned to the sending domain. 1405 [address start] is the 32 byte US-ASCII encoded hexadecimal 1406 representation of the start value of the keyword address space 1407 delegated to this node by its parent node. If this is the root node 1408 then this value is all '0' zeroes. 1410 [address end] is the 32 byte US-ASCII encoded hexadecimal 1411 representation of the end value of the keyword address space 1412 delegated to this node by its parent node. If this is the root node 1413 then this value is all 'F's. 1415 The keyword address space related fields does not correspond to any 1416 assignment at any of the children node. It just signifies the total 1417 range of key-space managed by the subtree rooted at the reporting 1418 domain. 1420 4.4.11. unicast-update 1422 [unicast-update] [0x02] [3] [ID hash] [msd IP] [msd port][\n] 1424 [ID hash] is the 32 byte US-ASCII encoded hexadecimal string 1425 representing the unique ID assigned to the sending domain. 1427 [msd IP] is the unicast IP address of the designated MSD server 1428 sending this protocol message. 1430 [msd port] is the port number of the unicast server running at the 1431 designated MSD server. 1433 4.4.12. unicast-update-status 1435 [unicast-update-status] [0x09] [1] [true][\n] 1437 [unicast-update-status] [0x09] [1] [false][\n] 1439 4.4.13. dsearch 1441 [dsearch] [0x0A] [2] [char-set] [parameter][\n] 1443 See Section 4.1 for more details on the interpretation of the 1444 commonly used message fields. 1446 [parameter] is the domain specific search parameter sent by the end- 1447 user on which the receiving MSD server acts. The format of the 1448 parameter string can be described using the following BNF regular 1449 expression: 1451 keyword(:keyword)*(&keyword(:keyword)*)* 1453 Any occurrence of [:] is the US-ASCII representation of COLON 1454 character, [&] is the US-ASCII encoding for AMPERSAND in the 1455 [parameter] field. Any keyword must be interpreted using the syntax 1456 rules for [keyword] already described above. Session scope 'global' 1457 is assumed while performing the search operation. 1459 4.4.14. bye 1461 [bye] [message direction] [0][\n] 1462 Refer to Table 3 for possible values of [message direction] field. 1464 4.4.15. ext-search 1466 [ext-search] [0x0A] [5] [char-set] [parameter] [IP] [port] [inversion 1467 flag][\n] 1469 See Section 4.1 for more details on the interpretation of the 1470 commonly used message fields. 1472 [parameter] can be specified by the BNF regular expression - 1474 keyword(%lat:long%radius)? 1476 lat and long represents the US-ASCII encoding of the latitude and 1477 longitude values (represented as a floating point number) of the 1478 search epicenter and radius is the search radius from the epicenter 1479 in kilometers (km). lat, long and radius [parameter] sub-components 1480 are optional. Search scope 'global' only is assumed. Any keyword 1481 must be interpreted using the syntax rules for [keyword] already 1482 described above. 1484 [IP] is the unicast IP address of the client that sent this message. 1485 This is the IP address where the search results are to be sent by the 1486 target MSD server where the query was sent. 1488 [port] is the port value of the unicast server running at the client 1489 that requested [ext-search] operation. This forms the part of the 1490 reply-back address for sending the search results to the requesting 1491 client. 1493 [inversion flag] must be set to 'true' or 'false'. This represents 1494 whether the message routing is to be done based on actual [keyword] 1495 hash value or if using inverted bits of the hash value. 1497 4.4.16. null-space 1499 [null-space] [message direction] [1] [ID hash][\n] 1501 Refer to Table 3 for possible values of [message direction] field. 1503 [ID hash] is the 32 byte US-ASCII encoded hexadecimal string 1504 representing the unique ID of the domain for which this protocol 1505 message is intended for. 1507 4.4.17. add-space 1509 [add-space] [message direction] [4] [range start] [range end] 1510 [significant bits] [ID hash][\n] 1512 Refer to Table 3 for possible values of [message direction] field. 1514 [range start] is the start value of the allotted keyword hash space, 1515 the value is computed using only the leftmost [significant] bits of 1516 the hash range. It is US-ASCII encoded integer number value. 1518 [range end] is the end value of the allotted keyword hash space, the 1519 value is computed using only the leftmost [significant] bits of the 1520 hash range. It is US-ASCII encoded integer number value. 1522 [significant bits] is the US-ASCII encoding of the number of leftmost 1523 bits of the MD5 hash that are used for routing purposes. 1525 4.4.18. ext-search-invalid 1527 [ext-search-invalid] [0x08] [2] [char-set] [keyword][\n] 1529 See Section 4.1 for more details on the interpretation of the 1530 commonly used message fields. 1532 [keyword] represents the keyword for which the MD5 hash value does 1533 not lie within this MSD server's managed space and hence the [ext- 1534 search] request can not be processed. 1536 4.4.19. search-response 1538 MSD server can send two kinds of [search-response] protocol messages 1539 depending on the scope of the session's record being sent. These 1540 message are described next - 1542 4.4.19.1. search-response - type 1 1544 [search-response] [0x07] [11] [char-set] [global] [keyword] [domain 1545 URI] [URS Identifier] [expiration time] [Lat] [Long] [network type] 1546 [stream type] [hop count][\n] 1548 See Section 4.1 for more details on the interpretation of the 1549 commonly used message fields. 1551 [global] is the US-ASCII encoding of the string constant 'global'. 1553 [keyword] is the search keyword for which one or more of this message 1554 is sent back to the requesting client. 1556 [domain URI] is the US-ASCII encoding of the domain URL string of the 1557 URS server in the target domain where the session record being sent 1558 as part of this protocol message was originally registered. 1560 [hop count] is the US-ASCII encoded number that represents the count 1561 of domain traversed including the current MSD domain. 1563 4.4.19.2. search-response - type 2 1565 [search-response] [0x07] [17] [char-set] [local] [keyword] [channel 1566 IP] [channel port] [channel scope] [Geographical CN] [Lat] [Long] 1567 [network type] [source IP] [stream type] [preferred application] [CLI 1568 argument] [unicast IP] [unicast port] [hop count][\n] 1570 See Section 4.1 for more details on the interpretation of the 1571 commonly used message fields. 1573 [local] is the US-ASCII encoding of the string constant 'local'. 1575 [keyword] is the search keyword for which one or more of this message 1576 is sent back to the requesting client. 1578 [hop count] is the US-ASCII encoded number that represents the count 1579 of domain traversed including the current MSD domain. 1581 4.4.20. ext-search-response 1583 [ext-search-response] [0x08] [11] [char-set] [global] [keyword] 1584 [domain URI] [URS Identifier] [expiration time] [Lat] [Long] [network 1585 type] [stream type] [hop count][\n] 1587 See Section 4.1 for more details on the interpretation of the 1588 commonly used message fields. 1590 For definition of other fields see Section 4.4.19.1 as the syntax and 1591 interpretation of these protocol fields are the same. 1593 4.4.21. tx-end 1595 [tx-end] [message direction] [3] [char-set] [keyword] [tag][\n] 1597 Refer to Table 3 for possible values of [message direction] field. 1599 See Section 4.1 for more details on the interpretation of the 1600 commonly used message fields. 1602 [keyword] is the search keyword for which this [tx-end] is being sent 1603 indicating the end of sequence of transmission of zero or more 1605 [search-response] or [ext-search-response] messages for each 1606 candidate multicast record. 1608 [tag] is the US-ASCII encoded string constant 'dext' or 'dint'. 1609 'dext' is sent to signal the end of transmission sequence for 1610 globally scoped multicast session records. Similarly 'dint' is sent 1611 to signal the end of transmission sequence for administratively 1612 scoped multicast sessions. 1614 4.4.22. resync 1616 [resync] [0x02] [0][\n] 1618 4.4.23. resync-status 1620 MSD server can process two different kinds of [resync-status] 1621 protocol messages. Both kinds are described next. 1623 4.4.23.1. resync-status - type 1 1625 [resync-status] [0x09] [1] [false][\n] 1627 4.4.23.2. resync-status - type 2 1629 [resync-status] [0x09] [3] [true] [msd IP] [msd port][\n] 1631 [msd IP] is the unicast server IP running at the designated MSD 1632 server in the parent domain. 1634 [msd port] is the port value of the unicast server running at the 1635 designated MSD server in the parent domain. 1637 4.4.24. request 1639 [request] [0x02] [1] [mcast_param][\n] 1641 [mcast_param] is the US-ASCII encoding of the string constant 1642 'mcast_param'. 1644 4.4.25. request-response 1646 [request-response] [0x09] [11] [mcast_param] [cmcast IP] [cmcast 1647 port] [pmcast IP] [pmcast port] [pmcast source IP] [msd-local IP] 1648 [msd-local port] [msd IP] [msd port] [IGMP version][\n] 1650 [mcast_param] is the US-ASCII encoding of the string constant 1651 'mcast_param'. 1653 [cmcast IP] is the child multicast channel IP address. Syntax is 1654 same as [IP address] described in Section 4.1. 1656 [cmcast port] is the US-ASCII representation of the child multicast 1657 channel port value. Syntax is same as [port] described in 1658 Section 4.1. 1660 [pmcast IP] is the parent multicast channel IP address. Syntax is 1661 same as [IP address] described in Section 4.1. 1663 [pmcast port] is the US-ASCII representation of the parent multicast 1664 channel port value. Syntax is same as [port] described in 1665 Section 4.1. 1667 [pmcast source IP] is the unicast IP of the designated MSD server in 1668 the parent domain. Syntax is same as [IP address] described in 1669 Section 4.1. 1671 [msd-local IP] is the MSD-LOCAL multicast channel IP address. This 1672 field is deprecated. Syntax is same as [IP address] described in 1673 Section 4.1. 1675 [msd-local port] is the US-ASCII representation of the MSD-LOCAL 1676 channel port value. This field is deprecated. Syntax is same as 1677 [port] described in Section 4.1. 1679 [msd IP] is the unicast server IP running at the designated MSD 1680 server in this domain. 1682 [msd port] is the port value of the unicast server running at the 1683 designated MSD server in this domain. 1685 [IGMP version] tells the IGMP version supported by the network 1686 multicast routers in this domain. This value could be the US-ASCII 1687 representation of numbers 1, 2, or 3. 1689 4.4.26. get-backup-msd 1691 [get-backup-msd] [0x0A] [4] [char-set] [keyword] [IP] [port][\n] 1693 See Section 4.1 for more details on the interpretation of the 1694 commonly used message fields. 1696 [keyword] represents the search key for which the search client 1697 experienced a response timeout. 1699 [IP] is the unicast IP address of the client that sent this message. 1700 This is the IP address where the new MSD connection details are to be 1701 sent once the target MSD is located. 1703 [port] is the port value of the unicast server running at the client 1704 that requested the cache invalidation. This forms the part of the 1705 reply-back address for sending the new MSD connection details to the 1706 requesting client. 1708 4.5. End User Search Tool - Message Formats 1710 Table 4 shows the summary of all the message types processed by any 1711 end user search browser. We present the detailed syntax of each of 1712 the protocol messages next. Wherever the fields [true] or [false] 1713 appear, they stand for the US-ASCII encoding of words 'true' and 1714 'false'. 1716 +---------------------+--------------+------------+-----------------+ 1717 | Message Type | Message | Number of | Variable | 1718 | | Direction | Fields | Parameters | 1719 +---------------------+--------------+------------+-----------------+ 1720 | request | 0x01 | 1 | mcast_param / | 1721 | | | | designated | 1722 | request-response | 0x03 | 11 or 3 | see details | 1723 | query | 0x01 | 2 | see details | 1724 | query-response | 0x03 | 1 | null | 1725 | query-response | 0x03 | 17 | see details | 1726 | dsearch | 0x0A | 2 | see details | 1727 | search | 0x0A | 3 | see details | 1728 | redirect | 0x07 | 5 | see details | 1729 | ext-search | 0x0A | 5 | see details | 1730 | bye | 0x01 0x03 | 0 | none | 1731 | | 0x08 0x0A | | | 1732 | ext-search-invalid | 0x08 | 2 | see details | 1733 | invalidate | 0x0A | 6 | see details | 1734 | search-response | 0x07 | 11 or 17 | see details | 1735 | ext-search-response | 0x08 | 11 | see details | 1736 | tx-end | 0x07 0x08 | 3 | see details | 1737 | get-backup-msd | 0x0A | 4 | see details | 1738 +---------------------+--------------+------------+-----------------+ 1740 Summary of [message types] and possible [message direction] values 1741 handled by an end user session search browser tool. 1743 Table 4 1745 4.5.1. request 1747 [request] [0x01] [1] [mcast_param][\n] 1749 [request] [0x01] [1] [designated][\n] 1751 [mcast_param] is the US-ASCII encoded string constant 'mcast_param'. 1753 [designated] is the US-ASCII encoded string constant 'designated'. 1755 4.5.2. request-response 1757 The search client can process two kinds of [request-response] 1758 protocol messages. Both are described next. 1760 4.5.2.1. request-response - type 1 1762 [request-response] [0x03] [11] [mcast_param] [cmcast IP] [cmcast 1763 port] [pmcast IP] [pmcast port] [pmcast source IP] [msd-local IP] 1764 [msd-local port] [msd IP] [msd port] [IGMP version][\n] 1766 See Section 4.2.9.1 for more details on the interpretation of the 1767 protocol fields. 1769 4.5.2.2. request-response - type 2 1771 [request-response] [0x03] [3] [designated] [msd IP] [msd port][\n] 1773 See Section 4.2.9.2 for more details on the interpretation of the 1774 protocol fields. 1776 4.5.3. query 1778 [query] [0x01] [2] [char-set] [URS-Identifier][\n] 1780 See Section 4.1 for more details on the interpretation of the 1781 commonly used message fields. 1783 4.5.4. query-response 1785 The search tool can process two kinds of [query-response] protocol 1786 messages. Both are described next. 1788 4.5.4.1. query-response - type 1 1790 [query-response] [0x03] [1] [null][\n] 1792 [null] is the US-ASCII representation of the word 'null'. 1794 4.5.4.2. query-response - type 2 1796 [query-response] [0x03] [17] [char-set] [channel IP] [channel port] 1797 [Geographic CN] [Lat] [Long] [unicast IP] [unicast port] [channel 1798 scope] [URS-Identifier] [expiration time] [network type] [source IP] 1799 [stream type] [preferred application] [CLI argument] [mime-type][\n] 1801 See Section 4.1 for more details on the interpretation of the 1802 commonly used message fields. 1804 4.5.5. dsearch 1806 [dsearch] [0x0A] [2] [char-set] [parameter][\n] 1808 See Section 4.4.13 for more details on the interpretation of the 1809 protocol fields. 1811 4.5.6. search 1813 [search] [0x0A] [3] [char-set] [parameter] [client port][\n] 1815 See Section 4.4.7 for more details on the interpretation of the 1816 protocol fields. 1818 4.5.7. redirect 1820 [redirect] [0x07] [5] [char-set] [keyword] [msd IP] [msd port] [hop 1821 count][\n] 1823 See Section 4.4.8 for more details on the interpretation of the 1824 protocol fields. 1826 4.5.8. ext-search 1828 [ext-search] [0x0A] [5] [char-set] [parameter] [IP] [port] [inversion 1829 flag][\n] 1831 See Section 4.4.15 for more details on the interpretation of the 1832 protocol fields. 1834 4.5.9. bye 1836 [bye] [message direction] [0][\n] 1838 See Table 4 for values that [message direction] field can take. 1840 4.5.10. ext-search-invalid 1842 [ext-search-invalid] [0x08] [2] [char-set] [keyword][\n] 1844 See Section 4.4.18 for more details on the interpretation of the 1845 protocol fields. 1847 4.5.11. invalidate 1849 [invalidate] [0x0A] [6] [char-set] [keyword] [cached IP] [cached 1850 port] [IP] [port][\n] 1852 See Section 4.4.4 for more details on the interpretation of the 1853 protocol fields. 1855 4.5.12. search-response 1857 End user search tool can process two kinds of [search-response] 1858 protocol messages. Both are described next. 1860 4.5.12.1. search-response - type 1 1862 [search-response] [0x07] [11] [char-set] [global] [keyword] [domain 1863 URI] [URS Identifier] [expiration time] [Lat] [Long] [network type] 1864 [stream type] [hop count][\n] 1866 See Section 4.4.19.1 for more details on the interpretation of the 1867 protocol fields. 1869 4.5.12.2. search-response - type 2 1871 [search-response] [0x07] [17] [char-set] [local] [keyword] [channel 1872 IP] [channel port] [channel scope] [Geographical CN] [Lat] [Long] 1873 [network type] [source IP] [stream type] [preferred application] [CLI 1874 argument] [unicast IP] [unicast port] [hop count][\n] 1876 See Section 4.4.19.2 for more details on the interpretation of the 1877 protocol fields. 1879 4.5.13. ext-search-response 1881 [ext-search-response] [0x08] [11] [char-set] [global] [keyword] 1882 [domain URI] [URS Identifier] [expiration time] [Lat] [Long] [network 1883 type] [stream type] [hop count][\n] 1885 See Section 4.4.20 for more details on the interpretation of the 1886 protocol fields. 1888 4.5.14. tx-end 1890 [tx-end] [message direction] [3] [char-set] [keyword] [tag][\n] 1892 See Table 4 for values that [message direction] field can take. 1894 See Section 4.1 for more details on the interpretation of the 1895 commonly used message fields. 1897 [keyword] is the search keyword for which this [tx-end] is being sent 1898 indicating the end of sequence of transmission of zero or more 1899 [search-response] or [ext-search-response] messages for each 1900 candidate multicast record at the MSD server. 1902 [tag] is the US-ASCII encoded string constant 'dext' or 'dint'. 1903 'dext' is sent to signal the end of transmission sequence for 1904 globally scoped multicast session records. Similarly 'dint' is sent 1905 to signal the end of transmission sequence for administratively 1906 scoped multicast sessions. 1908 4.5.15. get-backup-msd 1910 [get-backup-msd] [0x0A] [4] [char-set] [keyword] [IP] [port][\n] 1912 See Section 4.4.26 for more details on the interpretation of the 1913 protocol fields. 1915 5. Protocol Message Semantics 1917 Here description of what happens when a particular protocol message 1918 is received or sent, and what type of background processing could be 1919 expected among the components involved, is provided. 1921 +---------------------------------+-------------------+------------+ 1922 | Variable | Effected Messages | Value | 1923 +---------------------------------+-------------------+------------+ 1924 | SELF_REPORT_TIME | [hello] | 30 seconds | 1925 | PARENT_REPORT_TIME | [rep-hello] | 30 seconds | 1926 | MAX_PARENT_REPORT_TIMEOUT_COUNT | -na- | 2 | 1927 | MAX_CHILD_REPORT_TIMEOUT_COUNT | -na- | 6 | 1928 | MSD_UNICAST_REPORT_TIME | [unicast-update] | 30 seconds | 1929 | ADDRESS_NOTIFICATION_TIME | [add-space] | 30 seconds | 1930 | MAX_TIMEOUT_COUNT | -na- | 6 | 1931 | REQUEST_TIMEOUT | -na- | 20 seconds | 1932 | SOCKET_TIMEOUT | -na- | 20 seconds | 1933 +---------------------------------+-------------------+------------+ 1935 List of all global timer variables and associated values. 1937 Table 5 1939 5.1. URS Protocol Message Semantics 1941 +----------------+------------+-------------+-----------------------+ 1942 | Rx Messages | Sender | Recipient | Tx Messages | 1943 +----------------+------------+-------------+-----------------------+ 1944 | bye | Client, | URS, | bye | 1945 | | MSD, URS | Client, MSD | | 1946 | query | Client | URS | query-response | 1947 | check | Client | URS | check-response | 1948 | register | Client | URS | register-status | 1949 | request | Client, | URS | request-response | 1950 | | MSD, URS | | | 1951 | unicast-update | MSD | URS | unicast-update-status | 1952 | resync | MSD | URS | resync-status | 1953 +----------------+------------+-------------+-----------------------+ 1955 Table 6 1957 Unless otherwise noted, the protocol exchanges happen between the 1958 domain local URS and clients, registration tools, and MSD servers. 1960 5.1.1. bye 1962 [bye] protocol message when received at the URS indicates the desire 1963 of the remote tool to close the socket connection. Remote node could 1964 be a client, MSD server or even another URS. The receiver URS node 1965 must respond back with [bye] protocol message and then close the 1966 remote socket connection. 1968 5.1.2. query 1970 A [query] protocol message is used to retrieve the multicast session 1971 record details of the [URS-Identifier] provided. The URS searches 1972 the internal database for [URS-Identifier] record. If the record is 1973 located then it responds back with [query-response] type 2 protocol 1974 message (see Section 4.2.3.2) otherwise, it responds with a [query- 1975 response] type 1 (see Section 4.2.3.1) protocol message. 1977 The client on receiving the [query-response] (either type) protocol 1978 message must send [bye] protocol message to the URS. 1980 5.1.3. check 1982 A [check] protocol message is used by the registration tool to find 1983 out whether the intended [keyword] has already been reserved as URS- 1984 Identifier by some other session or not. If the [keyword] has 1985 already been used as URS-Identifier then a [check-response] message 1986 indicating 'false' is sent back to the client, else a 'true' [check- 1987 response] is sent back. 1989 The client on receiving the [check-response] protocol message must 1990 send [bye] protocol message to the URS. 1992 5.1.4. register 1994 A [register] protocol message is generated and sent to the URS by the 1995 session registration tool. The URS creates a new session record 1996 entry corresponding to the registration data included in the 1997 [register] protocol message. It must check for duplicity of the URS- 1998 Identifier keyword in the existing database. If a new record 1999 insertion into the database succeeds, then the URS sends back 2000 [register-status] indicating 'true', else it responds back with 2001 [register-status] indicating 'false'. 2003 The client on receiving the [register-status] protocol message must 2004 send [bye] protocol message to the URS. 2006 5.1.5. request 2008 [request] protocol messages are used by the clients and the 2009 designated MSD server to find out the critical configuration values 2010 to be able to join the service hierarchy. A [request] message with 2011 'mcast_param' is sent by the MSD server to contact the URS to get the 2012 hierarchy configuration parameters that allows the designated MSD 2013 server to subscribe to PMCAST channel and find out about CMCAST 2014 group. 2016 A [request] protocol with 'designated' is used by the clients to find 2017 the unicast server details of the designated MSD server in that 2018 domain. This protocol message can also be used by the URS to contact 2019 the URS in its parent domain to find the connectivity details of MSD 2020 server in parent domain. 2022 Upon receipt of the [request] protocol message, the URS responds back 2023 with the appropriate [request-response] message. A [request- 2024 response] type 1 (see Section 4.2.9.1) message is sent back in reply 2025 to 'mcast_param' request and a [request-response] type 2 (see 2026 Section 4.2.9.2) is sent in reply to 'designated' request. 2028 The client, MSD, or URS on receiving the [request-response] protocol 2029 message must send [bye] protocol message to the URS. Figure 3 shows 2030 the different scenarios when a URS [request] and [request-response] 2031 protocol messages are exchanged. [bye] messages are not shown. 2033 +-------+ 2034 |URS | 2035 | | 2036 +-------+ 2037 request| |request-response 2038 A \|/ 2039 /|\ V 2040 | | Domain A 2041 ----------|-----|------------------------------------- 2042 | | Domain B 2043 +-------+ request +-------+ 2044 | |-<----------------| | 2045 |URS | |MSD | 2046 | | request-response | | 2047 | |------------->----| | 2048 +-------+ +-------+ 2049 request| | 2050 A \|/ 2051 /|\ V 2052 | |request-response 2053 | | 2054 O 2055 /|\ 2056 | 2057 / \ 2058 Client 2060 Figure 3 2062 5.1.6. unicast-update 2064 A [unicast-update] protocol message is used by the designated MSD 2065 server to notify the URS of any changes in the unicast server 2066 connection details. This message is sent periodically by the MSD 2067 server to the URS. Upon receipt of this message, the URS updates the 2068 internal values. If the update succeeds at the URS, it responds back 2069 with a [unicast-update-status] message indicating 'true'. If the 2070 operation somehow fails, it sends back [unicast-update-status] with 2071 'false' in it. 2073 The MSD server on receiving the [unicast-update-status] protocol 2074 message must send [bye] protocol message to the URS. 2076 5.1.7. resync 2078 A [resync] protocol message is sent by the designated MSD server to 2079 the URS to suggest to the URS to re-sync the parent domain's MSD 2080 server unicast connection details. This protocol message is sent 2081 only when the designated MSD fails to get any parent heartbeat 2082 message [rep-hello] (see Section 4.4.10) for 2083 MAX_PARENT_REPORT_TIMEOUT_COUNT. periods. 2085 Upon receiving [resync] request, the URS sends [request] protocol 2086 with 'designate' parameter to the URS in the parent domain and waits 2087 for the [request-response] message to come back. After receiving the 2088 response from the URS in the parent domain and closing that socket 2089 connection, it responds to the MSD server with a [resync-status] 2090 protocol message. If it fails to get a valid data from the URS in 2091 the parent domain, the [resync-status] indicates a 'false' value. 2092 Otherwise a value 'true' and the updated unicast connection details 2093 of the parent designated MSD server are sent back. 2095 The MSD server on receiving the [resync-status] protocol message must 2096 send [bye] protocol message to the URS. 2098 5.2. Registration (Reg.) Tool Protocol Message Semantics 2100 +-------------+-----------+-----------------+------------------+ 2101 | Tx Messages | Sender | Recipient | Rx Messages | 2102 +-------------+-----------+-----------------+------------------+ 2103 | bye | Reg. Tool | URS, MSD server | bye | 2104 | check | Reg. Tool | URS | check-response | 2105 | register | Reg. Tool | URS, MSD server | register-status | 2106 | request | Reg. Tool | URS | request-response | 2107 +-------------+-----------+-----------------+------------------+ 2109 Table 7 2111 Unless otherwise noted, the communication happens between the 2112 registration tool and the URS and designated MSD server in the same 2113 administrative domain. 2115 5.2.1. bye 2117 [bye] protocol message is sent to the remote URS or MSD server to 2118 indicate an intent to close the socket connection. It should wait 2119 for the [bye] protocol message as the response before closing the 2120 socket connection. 2122 5.2.2. check 2124 The [check] protocol message is sent to the URS to find out whether 2125 the [keyword] sent along with this message has been used already as 2126 an URS-Identifier by some other multicast session or not. It must 2127 wait for the [check-response] reply message to come back from the 2128 URS. If no response is received within SOCKET_TIMEOUT, it must not 2129 proceed and the registration sequence must fail and the user 2130 notified. 2132 The registration tool on receiving the [check-response] protocol 2133 message must send [bye] protocol message to the URS. 2135 5.2.3. register 2137 The [register] protocol message is sent to the URS and the designated 2138 MSD server. See Section 4.3.4.1 and Section 4.3.4.2 for more 2139 details. This message is sent as a registration request and contains 2140 all necessary parameters of the multicast session to be registered. 2141 The tool must wait for a [register-status] reply to come back from 2142 the URS and MSD server indicating whether the registration attempt 2143 was a success of failure. 2145 The registration tool on receiving the [register-status] protocol 2146 message must send [bye] protocol message to the URS and/or MSD 2147 server. 2149 5.2.4. request 2151 A registration tool sends [request] protocol message to the URS to 2152 find out the unicast server connection details at the designated MSD 2153 server of its domain (see Section 4.3.6). It then must wait for the 2154 [request-response] (see Section 4.2.9.2) response to come back from 2155 the URS. 2157 The registration tool on receiving the [request-response] protocol 2158 message must send [bye] protocol message to the URS. 2160 5.3. MSD Server Protocol Message Semantics 2162 MSD server protocol messages can be grouped into three categories 2163 based on the nature of the server behavior. MSD servers act as a 2164 'server' to some clients, act as 'client' requesting services from 2165 others, and sometimes handle asynchronous protocol messages. Based 2166 on these three behavioral categorization, protocol summary tables are 2167 presented below. 2169 o Table 8 - MSD in server mode 2171 o Table 9 - MSD in client mode 2173 o Table 10 - MSD in asynchronous mode 2175 Unlike the previous two subsections where the protocol communication 2176 is generally assumed to take place among components within the same 2177 domain, protocol communication handled by MSD servers frequently 2178 crosses the domain boundaries. 2180 To interpret a table, read it from left to right. If a component 2181 acts as server, the first column is 'Rx Messages', signifying the 2182 messages received at the server. The response sent back to the 2183 requesting client is given by the 'Tx Messages' column. Similarly, 2184 if the component behaves as a client, then the first column of the 2185 table is 'Tx Messages' signifying the messages the client might send 2186 to the 'server'. The last column in such a table is 'Rx Messages', 2187 the messages that are received at the client from the remote 2188 'servers' in response to the message it sent. 2190 Table 10 is organized a bit differently. It shows the asynchronous 2191 protocol messages that can be sent by the designated MSD server in 2192 any domain. Some of those messages are sent periodically. The table 2193 shows the periodicity. The columns 'Parent', 'Child', and 'Local' 2194 note whether the message could be sent on a 'PMCAST', or 'CMCAST' 2195 channel or to other MSD servers running in the same domain (maybe via 2196 'MSD-LOCAL' channel) in that order. 2198 Note: Treat Table 10 as depicting 'send' semantics only. A message 2199 sent on a 'PMCAST' channel will be received at the designated MSD in 2200 the parent domain on its 'CMCAST' channel and vice-versa. 2202 MSD in server mode 2204 +----------------+------------------+-------------------------------+ 2205 | Rx | Sender | Tx Messages | 2206 +----------------+------------------+-------------------------------+ 2207 | register | registration | register-status | 2208 | | tool | | 2209 | invalidate | search tool | redirect | 2210 | search | search tool | redirect, search-response, | 2211 | | | tx-end | 2212 | dsearch | search tool | search-response, tx-end | 2213 | bye | registration, | bye | 2214 | | search tool | | 2215 | ext-search | search tool | ext-search-response, | 2216 | | | ext-search-invalid, tx-end | 2217 | get-backup-msd | search tool | redirect | 2218 +----------------+------------------+-------------------------------+ 2220 Table 8 2222 MSD in client mode 2224 +----------------+-------------------------+-----------------------+ 2225 | Tx Messages | Periodicity | Rx Messages | 2226 +----------------+-------------------------+-----------------------+ 2227 | unicast-update | MSD_UNICAST_REPORT_TIME | unicast-update-status | 2228 | resync | -NA- | resync-status | 2229 | request | -NA- | request-response | 2230 | bye | -NA- | bye | 2231 +----------------+-------------------------+-----------------------+ 2233 Recipient of these messages is URS 2235 Table 9 2237 Asynchronous messages handled by MSD 2239 +-----------------+--------+-------+-------+----------------------+ 2240 | Message | Parent | Child | Local | Periodicity | 2241 +-----------------+--------+-------+-------+----------------------+ 2242 | msd-probe | yes | yes | x | -NA- | 2243 | msd-probe-reply | x | x | x | -NA- | 2244 | hello | yes | x | x | SELF_REPORT_TIME | 2245 | rep-hello | x | yes | x | PARENT_REPORT_TIME | 2246 | null-space | x | yes | x | -NA- | 2247 | add-space | x | yes | x | ADDRESS_NOTIFICATION | 2248 | remote-register | yes | yes | x | -NA- | 2249 +-----------------+--------+-------+-------+----------------------+ 2251 Asynchronous messages are sent between MSD servers, frequently 2252 crossing domain boundaries. 2254 Table 10 2256 Message semantics for each protocol message handled by a MSD server 2257 are provided. 2259 5.3.1. register 2261 A [register] message is sent by a session registration tool to the 2262 designated MSD server in its own domain to register a multicast 2263 session with the MSD server. The registration message may contain 2264 several keywords. The MSD server separates the keywords list into 2265 individual keywords and creates one local database record for each 2266 keyword. 2268 If the session scope is 'global', then it hashes each keyword. It 2269 also generates the inverted hash values by inverting all the bits of 2270 the original MD5 keyword hash. If any hash value lies in the self 2271 managed hash space then a session record with the corresponding 2272 keyword is stored into the global database. Similarly, if any 2273 inverted hash values lie in the self managed hash space, then a 2274 session record with corresponding keyword and with 'hash inversion' 2275 flag set is stored in the global database as well. For remaining 2276 cases, depending on the keyword hash routing table, it creates a 2277 [remote-register] protocol message, and sends the message either 2278 towards parent or children domains. 2280 If the [remote-register] message is generated for the true hash 2281 value, then the [inversion flag] is set to 'false', otherwise the 2282 [inversion flag] field is set to 'true'. 2284 Once the local records insertion into database completes, and all 2285 necessary [remote-register] messages have been sent, the designated 2286 MSD server sends [register-status] protocol message back to the 2287 session registration tool indicating whether the process succeeded, 2288 'true', or not, 'false'. 2290 5.3.2. invalidate 2292 An [invalidate] message is sent by the client to the local MSD server 2293 when a remote MSD server's response to the client indicates that it 2294 is the wrong MSD server. When received at the MSD server, it removes 2295 the [keyword] entry, if present, from the locally maintained 'remote 2296 MSD connection' cache, if [inversion flag] value is 'false' or from 2297 'inversion-cache' if [inversion flag] value is 'true'. 2299 Then it hashes the [keyword] using MD5. It converts the hash value 2300 by inverting the bits iff [inversion flag] value was 'true'. It 2301 creates a [msd-probe] message and copies the [inversion flag] value 2302 received in the [invalidate] protocol message and sends it towards 2303 the target domain depending on the local routing table entry. 2305 Upon receiving the [msd-probe-reply] response for [keyword] from the 2306 remote MSD server, it first caches the remote connection information 2307 in the appropriate local cache (or inverted cache), and sends back 2308 [redirect] to the client. 2310 5.3.3. search 2312 When a [search] request is received at the MSD server, it separates 2313 all the keywords and the search parameters contained in the protocol 2314 message. If administrative 'local' scoped search is enabled, then it 2315 queries the local session records database for these keywords one by 2316 one. Responses are sent back as a set for all matching session 2317 records for a 'keyword' before proceeding to the next 'keyword'. 2319 Matching records are sent back using [search-response] (see 2320 Section 4.4.19.2) one by one. Once all the matching records for a 2321 particular 'keyword' has been transmitted, the transmission sequence 2322 end is realized by sending [tx-end] with 'dint' parameter to the 2323 client before proceeding with the next keyword (see Figure 4). 2325 If 'global' scoped session search is enabled, the MSD server hashes 2326 the 'keyword', if the hash value lies in its managed range, it 2327 queries its 'Global Records' database for the keyword and all 2328 matching records are sent back using [search-response] to the 2329 client(see Section 4.4.19.1). The transmission sequence end is 2330 realized by sending [tx-end] with 'dext' parameter to the client 2331 before proceeding with the next keyword. 2333 If the hashed value does not lie in the self managed range, then it 2334 looks into the 'Remote MSD Connection' cache for an entry for the 2335 'keyword', if an entry is found, it sends back the remote MSD server 2336 connection details using [redirect] message. The [inversion flag] 2337 value in the [redirect] messages are set to 'false'. 2339 If no cache entry is found, it sends [msd-probe] towards the target 2340 domain, and upon receiving [msd-probe-reply] updates its local cache, 2341 and sends [redirect] information to the client. The [inversion flag] 2342 field in the [msd-probe] message and the [redirect] response is set 2343 to 'false'. 2345 | | 2346 |-----<------search-------------| 2347 |--------search-response---->---| ^ 2348 |--------search-response---->---| | 2349 | ... | | keyword 1 2350 |--------search-response---->---| | 2351 |--------- tx-end dint ----->---| v 2352 | . | . 2353 | . | . 2354 | . | . 2355 |--------search-response---->---| ^ 2356 |--------search-response---->---| | 2357 | ... | | keyword n 2358 |--------search-response---->---| | 2359 |--------- tx-end dint ----->---| v 2360 | | 2361 MSD Client 2363 protocol exchange for administratively scoped session search 2365 Figure 4 2367 Figure 5 shows the search scenario where multicast sessions with 2368 'global' scope are being searched for. The figure depicts two cases. 2369 Case I shows the scenario where every keyword hash value lies in the 2370 self-managed hash value range. Case II shows the scenario where a 2371 few keywords' hash values lie in the self-managed range at the local 2372 MSD and thus the search-responses are sent from the local MSD server, 2373 but for the remaining keywords a [redirect] is sent. Using the data 2374 contained in the [redirect] the client contacts the remote MSD 2375 servers directly for the search data. 2377 Figure 6 shows the search scenario where not all keywords' cache 2378 entries are present and further, a cache entry is stale at the local 2379 MSD server. 2381 |--<------search-------------| 2382 |-----search-response---->---| ^ 2383 |-----search-response---->---| | 2384 | ... | | keyword 1 2385 |-----search-response---->---| | 2386 |------ tx-end dext ----->---| v 2387 | . | . 2388 | . | . CASE 1: All keywords' hash 2389 | . | . lies in the self managed range 2390 |-----search-response---->---| ^ 2391 |-----search-response---->---| | 2392 | ... | | keyword n 2393 |-----search-response---->---| | 2394 |------ tx-end dext ----->---| v 2395 | | 2396 ----------------------------------------------------------------------- 2397 | | | | 2398 |--<------search-------------| | | 2399 |-----search-response---->---| ^ | | 2400 |-----search-response---->---| | | | 2401 | ... | | keyword 1 | | 2402 |-----search-response---->---| | | | 2403 |------ tx-end dext ----->---| v | | 2404 | . | . | | 2405 | . | . | | 2406 | | | | 2407 |-------- redirect ------>---| | | 2408 |-------- redirect ------>---|-------- ext-search --->---| | 2409 | . |-<-- ext-search-response --| | 2410 | . |-<-- ext-search-response --| | 2411 |-------- redirect ------>---| ... | | 2412 | |-<------ tx-end dext ------| | 2413 | | | | 2414 | |------->-- ext-search -----+-->------| 2415 | |-<--- ext-search-response -+---------| 2416 | |-<--- ext-search-response -+---------| 2417 | |-<--- ext-search-response -+---------| 2418 | | ... | | 2419 | |-<------- tx-end dext -----+---------| 2420 | | . | | 2421 | | . | | 2423 MSD-local Client MSD-x MSD-y 2425 protocol exchange for globally scoped session search - case I and II 2427 Figure 5 2429 | | | | | 2430 |--<------search----------| | | | 2431 |-----search-response-->--| ^ | | | 2432 |-----search-response-->--| | | | | 2433 | ... | | keyword 1 | | | 2434 |-----search-response-->--| | | | | 2435 |------ tx-end dext --->--| v | | | 2436 | . | . | | | 2437 | . | . | | | 2438 | | | | | 2439 |-------- msd-probe --->--+------...---->-----...-----+--->--| | 2440 |--<-- msd-probe-reply ---+-------------<-------------+------| | 2441 | . | | | | 2442 | . | | | | 2443 |-------- redirect ---->--|-------- ext-search --->---| | | 2444 | . |-<-- ext-search-response --| | | 2445 | . |-<-- ext-search-response --| | | 2446 |-------- redirect ---->--| ... | | | 2447 | |-<------ tx-end dext ------| | | 2448 | | | | | 2449 | |------->-- ext-search -----+-->---| | 2450 | |-<--- ext-search-response -+------| | 2451 | |-<--- ext-search-response -+------| | 2452 | |-<--- ext-search-response -+------| | 2453 | | ... | | | 2454 | |-<------- tx-end dext -----+------| | 2455 | | . | | | 2456 | | . | | | 2457 | | . | | | 2458 | |-------- ext-search --->---| | | 2459 | |--<- ext-search-invalid --| | | 2460 |--<--- invalidate -------| | | | 2461 |------- msd-probe ---->--+------------->-------------+---->-+---->-| 2462 |--<-- msd-probe-reply ---+-------------<-------------+----<-+----<-| 2463 |-------- redirect ---->--| | | | 2464 | |------------ ext-search ---+------+---->-| 2465 | |-<---- ext-search-response +------+----<-| 2466 | |-<---- ext-search-response +------+----<-| 2467 | | ... | | | 2468 | |-<---------- tx-end dext --+------+----<-| 2469 | | | | | 2471 MSD-local Client MSD-x MSD-y MSD-z 2473 protocol exchange for globally scoped session search - case III 2475 Figure 6 2477 In the two figures shown above, 'search-response' messages contain 2478 multicast session data for the sessions stored locally; the first 2479 msd-probe is sent to locate the server holding the multicast session 2480 data for a key for which there is no cache entry, and redirects are 2481 sent to the client for non-local keys (now held in the cache). The 2482 client searches the remote MSD servers as directed by its local MSD 2483 server. In the first two cases, the remote server is the right one 2484 and returns the session data. In the last case, the location data 2485 cached at the local MSD server is stale, so the remote MSD server 2486 indicates it does have the desired session data by responding with 2487 ext-search-invalid message. The client then informs its local MSD 2488 server to invalidate that cache entry and obtain fresh location 2489 information. When it has done this, it caches the fresh data and 2490 redirects the client as before. 2492 IMP: MSD servers must ignore duplicate keywords in the [search] 2493 protocol message, if duplicates are present then only one set of 2494 [search-response] messages followed by [tx-end] is sent to the client 2495 for that duplicate keyword. For example, if the search [parameter] 2496 is 'key1:key2:key3&key2:key4%yes:no' clearly 'key2' is repeated, so 2497 while processing the search query parameter string, if a keyword has 2498 already been processed by the MSD search handling module, a repeated 2499 keyword must be ignored. 2501 5.3.4. dsearch 2503 [dsearch] protocol message is sent if a domain-specific search 2504 operation has to be carried out at the target MSD server. Only 2505 globally scoped multicast sessions are included in the search result. 2506 Upon receiving this message, the MSD server parses all the keywords 2507 in the [dsearch] protocol message. 2509 Keywords are processed one by one, duplicates are ignored. The MSD 2510 server queries only its 'Local Session Records' database and filters 2511 out those records where session scope is set to 'global'. It sends 2512 these candidate records' data one by one to the client using zero or 2513 more [search-response] (see Section 4.4.19.1) message(s). To 2514 indicate the end of sequence a [tx-end] protocol with 'dext' 2515 parameter is sent to the client. The next keyword in the sequence is 2516 processed and the whole sequence of operation repeats until all the 2517 keywords in the [dsearch] request have been processed (duplicates are 2518 ignored). 2520 5.3.5. bye 2522 [bye] protocol message when received at the MSD indicates the desire 2523 of the remote client to close the socket connection. The MSD server 2524 must respond back with a [bye] protocol message and then close the 2525 remote socket connection. 2527 When MSD is acting as a client, it may send [bye] as its intent to 2528 close the socket connection. The MSD server must wait for [bye] 2529 protocol message to come from the remote server and then close the 2530 socket connection. 2532 The client MSD server may time out and resend the [bye] message is no 2533 reply is received within SOCKET_TIMEOUT period. If a [bye] message 2534 is received on an unconnected socket, the receiving MSD shall respond 2535 with a [bye] and close the connection. 2537 5.3.6. ext-search 2539 The [ext-search] message is sent by the client to search against a 2540 particular keyword for which the MSD server manages the hash-space 2541 range. If [inversion flag] is set to 'false' then the MD5 hash of 2542 the [keyword] is computed, otherwise its inversion is computed. If 2543 the computed hash does not lie in the self-managed hash-space, a 2544 [ext-search-invalid] message is sent back. The [inversion flag] 2545 field in [ext-search-invalid] is simply copied from the received 2546 [ext-search] protocol message. 2548 Otherwise, the MSD server queries its 'Global Session Records' 2549 database for the keyword and any candidate session records data are 2550 sent back using zero or more [ext-search-response] message(s). To 2551 indicate the end of the data sequence a [tx-end] message with 2552 parameter 'dext' is sent back to the client. 2554 5.3.7. get-backup-msd 2556 The [get-backup-msd] message is sent by the search client to the 2557 local MSD server if it can not connect to the remote MSD server as 2558 directed by the [redirect] message it received in response to the 2559 [search] query. A [get-backup-msd] may also be sent by the client if 2560 it encounters a time out waiting for search response to be received. 2562 When the MSD server receives the [get-backup-msd] message, it looks 2563 for a keyword match in its locally maintained 'inversion-cache', if 2564 found it responds with a [redirect] message back to the client. The 2565 [inversion flag] in this [redirect] is set to 'true'. In case of 2566 cache-miss, the MSD server generates a [msd-probe] message with the 2567 [inversion flag] set to 'true' and sends the message to the next MSD 2568 server in the hierarchy depending on the route got from the routing 2569 table using the bit-inverted keyword hash value. When the 2570 corresponding [msd-probe-reply] message is received with [inversion 2571 flag] set to true for the requested keyword, it first updates its 2572 local 'inversion-cache' and then sends an appropriate [redirect] 2573 message to the requesting client. 2575 5.3.8. unicast-update 2577 [unicast-update] protocol message is sent periodically by the 2578 designated MSD server to the URS in its domain to refresh the MSD's 2579 unicast connection data at the URS. The periodicity of this message 2580 is MSD_UNICAST_REPORT_TIME seconds. The URS responds with [unicast- 2581 update-status] message indicating whether the update operation was 2582 successful or not. 2584 The MSD server on receiving the [unicast-update-status] protocol 2585 message must send a [bye] protocol message to the URS. 2587 5.3.9. resync 2589 When the designated MSD server fails to receive parent's [rep-hello] 2590 message for consecutive MAX_PARENT_REPORT_TIMEOUT_COUNT timeout 2591 intervals, it sends the [resync] protocol message to the domain local 2592 URS to instruct it to contact its parent domain's URS using [request] 2593 protocol message (see Section 4.2.8.2) to query the latest MSD 2594 unicast connection details in the parent's domain so that this MSD 2595 server can contact the parent MSD in the parent domain via unicast. 2596 After the URS has re-synced its data, it responds back to the MSD 2597 server using [resync-status] protocol message. If the parent URS no 2598 longer exists, of if the parent MSD connection data after re-syncing 2599 is invalid, then [resync-status] with 'false' is sent (see 2600 Section 4.2.13.1), else the re-synced data is sent using [resync- 2601 status] with 'true' set (see Section 4.2.13.2). 2603 The MSD server on receiving the [resync-status] protocol message must 2604 send a [bye] protocol message to the URS. 2606 5.3.10. request 2608 A [request] message with 'mcast_param' is sent by the MSD server to 2609 the URS to get the hierarchy configuration parameters that allow the 2610 designated MSD server to subscribe to PMCAST channel CMCAST group and 2611 other details. Upon receipt of the [request] protocol message, the 2612 URS responds with the [request-response] type 1 message (see 2613 Section 4.2.9.1). 2615 The MSD server on receiving the [request-response] protocol message 2616 must send a [bye] protocol message to the URS. 2618 5.3.11. msd-probe 2620 [msd-probe] message can be generated by a MSD server in four 2621 scenarios. First, when a [search] request comes for globally scoped 2622 sessions search and a keyword hash value lies outside the self 2623 managed range and the target MSD connection details are not found in 2624 the local 'MSD connections' cache, then a [msd-probe] message is 2625 generated with [inversion flag] field set to 'false' and propagated 2626 in the direction of the target domain using the hash routing table. 2628 Second, when the MSD receives an [invalidate] message from a client 2629 with [inversion flag] set to 'false'; it removes the cache entry for 2630 the keyword in question from the usual 'MSD connections' cache and 2631 sends [msd-probe] message with [inversion flag] field set to 'false' 2632 for that keyword that was the argument of the [invalidate] message. 2634 Third, when the MSD receives [get-backup-msd] message from the 2635 client, it looks up its locally maintained 'inversion-cache' for the 2636 requested keyword entry. If the target MSD server connection details 2637 are not found, it generates an [msd-probe] message with [inversion 2638 flag] field set to 'true' and routes it according to the routing 2639 algorithm using bit-inverted keyword hash value. 2641 Fourth, when the MSD receives an [invalidate] message from a client 2642 with [inversion flag] set to 'true'; it removes the cache entry for 2643 the keyword in question from the 'inversion-cache' cache and sends 2644 [msd-probe] message with [inversion flag] field set to 'true' for 2645 that keyword that was the argument of the [invalidate] message 2646 according to the routing algorithm using bit-inverted keyword hash 2647 value. 2649 When an MSD server receives the [msd-probe] message on either PMCAST 2650 or from any of its children nodes, it computes the MD5 hash of the 2651 associated keyword. If the [inversion flag] is true, the hash value 2652 is bit-inverted.This value is used to see if this value falls in its 2653 self managed hash value range or not; if it falls in the range, it 2654 sends [msd-probe-reply] containing the connection details of its 2655 unicast server directly back to the original MSD server. The 2656 [inversion flag] in the reply message is made equal to the [inversion 2657 flag] that was received in the [msd-probe] message. If not then it 2658 simply routes the [msd-probe] in accordance with the hash routing 2659 table towards the next domain using the original keyword hash value 2660 or its bit-inverted form depending on whether the [inversion flag] in 2661 the received [msd-probe] was 'false' or 'true'. 2663 5.3.12. hello 2665 A [hello] message is generated periodically by the MSD server to send 2666 to its parent domain. The MSD server includes the domain count 2667 report and its unicast connection details in the message. The 2668 periodicity of this message is SELF_REPORT_TIME seconds. 2670 When an MSD server receives a [hello] message from any of its 2671 children domain, it updates/stores the child domain unicast 2672 connection details and the unique ID in its child list and updates 2673 the last seen time for this child. Any entry in the child-list that 2674 has not be updated since MAX_CHILD_REPORT_TIMEOUT_COUNT timeout 2675 periods should be purged. If a child entry is purged, the MSD server 2676 must check the routing table to see if any route was created for this 2677 purged child node; if so, then that hash-range and the route must be 2678 merged with some other child entry or temporarily assigned to itself 2679 (see Section 6.1). The receiving MSD server checks the [pmcast 2680 status] parameter to see if the reporting child domain is getting 2681 communication from this domain on its PMCAST channel or not. If not, 2682 the MSD server sends communication to this child node using unicast 2683 in addition to sending messages to rest of the children via the 2684 CMCAST multicast channel. If there are no children subscribing to 2685 the CMCAST channel, then it need not be used at all. 2687 5.3.13. rep-hello 2689 A [rep-hello] protocol message is sent periodically on the CMCAST 2690 channel to all the children nodes. Occasionally it could also be 2691 sent via unicast to a child node that is unable to receive 2692 communication sent using multicast channel CMCAST. The periodicity 2693 of this message is set to PARENT_REPORT_TIME seconds. 2695 A MSD receives this message on its PMCAST channel. Upon receiving 2696 the message, the MSD server stores the hash-range assigned to the 2697 parent for a possible node failure recovery in future. If this 2698 protocol message is not received for consecutive 2699 MAX_PARENT_REPORT_TIMEOUT_COUNT periods, the node sends [resync] to 2700 the URS to find the updated parent's connection details in case it 2701 changed. If after consecutive MAX_TIMEOUT_COUNT periods, no [rep- 2702 hello] messages are received, the MSD assumes the parent to be dead, 2703 and assumes the root responsibilities (see Section 6.1). In the 2704 meantime (when the parent is assumed dead) it continues to send 2705 [resync] to its URS every MAX_PARENT_REPORT_TIMEOUT_COUNT intervals. 2706 Upon receipt of [rep-hello] the timeout counter is reset. 2708 5.3.14. null-space 2710 [null-space] message is sent on the CMCAST channel (or unicast for 2711 children unable to receive communication over their PMCAST channel) 2712 to indicate that a particular child domain identified by the unique 2713 ID included in the protocol message has been assigned a 'null' 2714 keyword hash range. 2716 When a MSD identified by the unique ID receives the [null-space] 2717 message destined to it, it updates its hash routing table to reflect 2718 the change, assigns any of its children (that were assigned a hash 2719 space by this MSD) 'null' too and notifies them by sending [null- 2720 space] to them over CMCAST or unicast. The routing table now must 2721 route any hash value through the parent node. This MSD server then 2722 migrates every multicast record stored in the 'Global Session 2723 Records' database using [remote-register] via the parent node. 2725 5.3.15. add-space 2727 [add-space] protocol message is periodically sent to every children 2728 domain to refresh or reassign/assign keyword hash ranges to them for 2729 management. This protocol message is normally sent via CMCAST but 2730 for child nodes unable to receive communication on their PMCAST 2731 channel, it must send using unicast. The periodicity of this 2732 protocol message is ADDRESS_NOTIFICATION_TIME seconds. Any child 2733 node in the current child-list that has not been assigned any hash 2734 range value must be sent a [null-space] protocol message. 2736 When a MSD server identified by the unique ID receives the [add- 2737 space] message destined to it, it checks if the hash range contained 2738 in it is same as the range already assigned to it or not. If it is 2739 the same, then no further action is taken. If it is not, then its 2740 hash range has been updated by its parent domain. It must 2741 redistribute the hash range among itself and any children in 2742 accordance to the distribution algorithm it implements, and notify 2743 the children nodes using [add-space]. It updates the routing table 2744 to reflect the change. Finally it must migrate any multicast session 2745 records stored in the 'Global Multicast Records' database whose 2746 keyword MD5 hash does not lie in its hash range using the [remote- 2747 register] protocol message and routing it according to the new 2748 routing table. 2750 5.3.16. remote-register 2752 A [remote-register] protocol message can be generated and sent by an 2753 MSD server in two scenarios. First, when a [register] request comes 2754 and the multicast session is marked as 'globally scoped', and one or 2755 more keywords' MD5 hash lies outside the self-managed hash range, 2756 then two [remote-register] messages are created; one with [inversion 2757 flag] set to 'false' and another with [inversion flag] field set to 2758 'true'. These [remote-register] messages are routed according to the 2759 routing table to the destination domain. The routing is based on the 2760 MD5 hash value of the keyword in the case where [inversion flag] was 2761 set to 'false' and routing is based on the bit-inverted hash value of 2762 the keyword in the case where [inversion flag] was set to 'true'. 2764 Secondly, if the assigned hash range of this MSD server has been 2765 reassigned by the parent node or made 'null', then all the candidate 2766 global records stored in the 'Global Session Records' database whose 2767 keyword's MD5 hash no longer lie in the new hash space range 2768 reassigned to itself must be checked for migration readiness to the 2769 correct destination domains. For those candidate session records 2770 whose 'inversion flag' is set to 'false', a [remote-register] message 2771 for such records are generated with [inversion flag] set to 'false' 2772 and these protocol messages are routed based on the updated routing 2773 table using the keywords' true MD5 hash values. For all session 2774 records where the 'inversion flag' is set to 'true', a [remote- 2775 register] message for such records are generated with [inversion 2776 flag] set to 'true' and these protocol messages are routed based on 2777 the updated routing table using the keywords' bit-inverted MD5 hash 2778 values. 2780 When a [remote-register] message is received from the parent node or 2781 one of the children domains, the [inversion flag] field is checked. 2782 It it is 'false' then the MD5 hash of the keyword contained in the 2783 message is computed. Otherwise the bit-inverted MD5 hash value is 2784 computed instead. If the value lies in the self-managed hash range, 2785 a new record is created and inserted into the 'Global Session 2786 Records' database. The record's 'inversion flag' field is set to 2787 [inversion flag] value contained in the protocol message. If not 2788 then the message is forwarded to the next hop towards the target 2789 domain based on the hash routing table, using either the true MD5 2790 hash value or the bit-inverted hash value of the keyword depending on 2791 whether the received [remote-register] message had [inversion flag] 2792 field set to 'false' or 'true'. 2794 5.4. End User Search Tool Protocol Message Semantics 2796 +----------------+-----------+--------------------------------------+ 2797 | Tx | Recipient | Rx Messages | 2798 +----------------+-----------+--------------------------------------+ 2799 | request | URS | request-response | 2800 | query | URS | query-response | 2801 | dsearch | MSD | search-response, tx-end | 2802 | search | MSD | search-response, redirect, tx-end | 2803 | ext-search | MSD | ext-search-response, | 2804 | | | ext-search-invalid, tx-end | 2805 | invalidate | MSD | redirect | 2806 | bye | URS, MSD | bye | 2807 | get-backup-msd | MSD | redirect | 2808 +----------------+-----------+--------------------------------------+ 2810 Table 11 2812 Table 11 gives a summary of the protocol messages handled by the end- 2813 user search tool. Detailed semantics for each 'Tx Message' is given 2814 next. Unless explicitly mentioned the communication happens between 2815 the search tool and the URS or designated MSD server in the same 2816 administrative domain. 2818 5.4.1. request 2820 The [request] protocol message is sent by the search client to the 2821 URS to get the unicast server connection details of the designated 2822 MSD server of that domain. It waits for the URS to respond with a 2823 [request-response] message (see Section 4.2.9.2). This [request] 2824 message is sent to the client's domain local URS. 2826 Upon receiving the [request-response] message from the URS, the 2827 search client sends a [bye] protocol message to the URS and waits for 2828 the [bye] message from the URS before closing the socket connection. 2830 5.4.2. query 2832 The [query] protocol message is used to find the multicast session 2833 record details by querying the URS with the [URS-Identifier] 2834 parameter. If a record for the provided [URS-Identifier] is located 2835 in the internal database at the URS, it responds with a [query- 2836 response] message containing all the record details (see 2837 Section 4.2.3.2). If no record is located, the URS responds with a 2838 [query-response] message containing 'null' in it (see 2839 Section 4.2.3.1). 2841 Upon receiving the [query-response] message, the search client sends 2842 a [bye] protocol message to the URS and waits for the [bye] message 2843 from the URS before closing the socket connection. 2845 5.4.3. dsearch 2847 A search client uses [dsearch] protocol message to perform a domain 2848 specific multicast session search at the remote domain directly. 2849 Before sending the search parameters to the desired domain, the 2850 search client must locate the designated MSD server unicast 2851 connection details at that domain. This it achieves using URL 2852 resolution to locate the remote URS and then contacting it to find 2853 the connection details using a [request] protocol message with the 2854 'designated' parameter in it. 2856 The remote MSD server responds by sending all the candidate multicast 2857 sessions one by one using zero or more [search-response] protocol 2858 message for each search keyword one by one. Once all the session 2859 record data for candidate sessions for a keyword have been sent, the 2860 remote MSD sends [tx-end] with 'dext' indicating the end of sequence 2861 for a keyword. It then proceeds with the next keyword and so on. At 2862 the target MSD server, a 'global' scoped session search is assumed. 2864 If no response is received from the remote MSD server for 2865 SOCKET_TIMEOUT period, the search client must generate an error to 2866 notify the end-user. 2868 5.4.4. search 2870 [search] is used by the search tool to send the search query along 2871 with all associated parameters to the MSD server in the local domain. 2872 The MSD server shall respond by bunch of [search-response] messages, 2873 [tx-end], or [redirect] protocol messages. The interpretation of 2874 [search-response] and [tx-end] is same as described in subsection 2875 Section 5.4.3. If a [redirect] is received, the search tool sends 2876 the [ext-search] along with the corresponding [keyword] to the target 2877 MSD whose connection details are in the [redirect] message. The 2878 [inversion flag] value in the [redirect] message received is copied 2879 over in the [inversion flag] field of the [ext-search] message. 2881 5.4.5. ext-search 2883 An [ext-search] message is sent by the search client to the remote 2884 MSD server as a result of receiving a [redirect] message from the 2885 local-MSD server. The [inversion flag] field value for this protocol 2886 message is simply copied over from the [inversion flag] field in the 2887 [redirect] message that was received. [ext-search] protocol message 2888 contains a single search [keyword] in it. The response from the 2889 remote MSD server shall be either an [ext-search-invalid] protocol 2890 message indicating that the remote server does not handle the 2891 keyword's MD5 hash value and that the [ext-search] should be resent 2892 to some other domain, or sequence of zero or more [ext-search- 2893 response] messages, each containing data record for a candidate 2894 multicast session in it, followed by a [tx-end] message indicating 2895 the end of the sequence. 2897 If an [ext-search-invalid] message is received at the search client, 2898 then it generates an [invalidate] protocol message with the 2899 corresponding [keyword] in it and sends it to the MSD server in its 2900 local domain. 2902 If the [ext-search] connection to remote MSD server fails, or if no 2903 response is received within SOCKET_TIMEOUT interval of sending [ext- 2904 search] message, it must send [invalidate] to the domain local MSD 2905 server after copying the [inversion flag] value from the [ext-search] 2906 message over to the [invalidate] message's [inversion flag] field. 2908 5.4.6. invalidate 2910 An [invalidate] protocol message is sent to the domain local MSD 2911 server by the search client indicating that the 'Remote MSD 2912 Connection' cache entry at the MSD server for the contained [keyword] 2913 parameter sent as part of [invalidate] message is incorrect. The 2914 search client waits for the MSD server to respond with an updated 2915 [redirect] message. The [inversion flag] field value in the 2916 [invalidate] message is set equal to the value that was contained in 2917 the original [redirect] message's [inversion flag] field. 2919 After the new [redirect] message is received, the search client sends 2920 the [ext-search] request to the new remote MSD server and waits for 2921 its response message(s). 2923 If no response is received at the client to the [invalidate] request 2924 after SOCKET_TIMEOUT period, it must send [get-backup-msd] request to 2925 the domain local MSD server, iff the [invalidate] message's 2926 [inversion flag] field value was set to 'false'. Else it may 2927 generate an error message to notify the end-user. 2929 5.4.7. bye 2931 [bye] protocol message is sent to a URS or MSD server to indicate the 2932 intent to close the socket connection. The client shall wait for the 2933 [bye] protocol message to be received as the response to its [bye] 2934 before closing the socket connection. It may retry sending a [bye] 2935 protocol message if no response is received after SOCKET_TIMEOUT 2936 period. Alternatively the client may ignore the non-receipt of the 2937 [bye] response message and go ahead and close the socket connection 2938 and proceed. 2940 5.4.8. get-backup-msd 2942 A search client generates a [get-backup-msd] message in two 2943 situations. First, when the MSD server fails to respond to the 2944 [invalidate] request sent by this client earlier and iff the 2945 [invalidate] message's [inversion flag] field value was set to 2946 'false'. Second, when client's connection to the remote MSD server 2947 based on the connection data received via [redirect] message fails or 2948 time-out occurs on doing [ext-search] query and iff the [inversion 2949 flag] field value in the [ext-search] message was set to 'false'. 2951 The client must wait for a [redirect] response to come from the local 2952 MSD server. If no response is received after SOCKET_TIMEOUT period, 2953 the client may generate error report to notify the end-user. If a 2954 [redirect] is received, the client must send [ext-search] to the 2955 target MSD server copying the [inversion-flag] value from the 2956 [redirect] message to the [ext-search] message. 2958 6. Discussion 2960 6.1. Routing Table Management 2962 Every designated MSD server in this proposed service maintains a 2963 keyword routing table that enables correct keyword routing from any 2964 participating domain to the destination domain that manages the key- 2965 space within which that keyword's MD5 hash value lies. 2967 Associated with each routing table are some common parameters that 2968 are maintained not as part of any particular table entry but as a 2969 global variable associated with the whole routing table itself. 2970 These are specified next along with the general route entry 2971 structure. 2973 +------------------------------------------------+ 2974 | Parameters | 2975 +------------------------------------------------+ 2976 | Significant Bits | 2977 | Parent's Overall Keyword Hash Range | 2978 | Overall Keyword Hash Range for this MSD server | 2979 | Parent's Unicast Connection Details | 2980 | CMCAST Channel Details | 2981 +------------------------------------------------+ 2983 Keyword routing table global parameters list 2985 Table 12 2987 Table 13 gives the routing table row entry format. Ideally there are 2988 as many entries as the number of children domains + 1 to include self 2989 node entry. But there could be more entries present to deal with 2990 intermittent node failures in the future. Node failure strategy is 2991 given later (see Section 6.3). 2993 +-------+-----+-----------+--------+---------+------------+---------+ 2994 | Start | End | Assigned | Next | Unicast | Multicast? | Is | 2995 | | | To | Route | | | Temp? | 2996 +-------+-----+-----------+--------+---------+------------+---------+ 2998 General keyword routing table organization 3000 Table 13 3002 {Significant Bits} represent the number of leftmost bits of the MD5 3003 keyword hash value that is utilized in making the routing decision. 3005 {Parent's Overall Keyword Hash Range} is the overall keyword hash 3006 range originally assigned to the parent domain by its parent. It 3007 does not represent the actual range handled and managed by the parent 3008 node. 3010 {Overall Keyword Hash Range for this MSD server} is the keyword hash 3011 range assigned to this MSD server by its parent node. It does not 3012 represent the actual range of keyword values handled and managed by 3013 this node. 3015 {Parent Unicast Connection Details} is the connection details of the 3016 unicast server running at the designated MSD server at the parent 3017 domain. This allows communication to be sent to the parent node. 3019 {CMCAST Channel Details} is the multicast channel details enabling 3020 communication to be sent to children nodes on CMCAST channel. 3022 A brief description of each component that makes a route entry in the 3023 routing table is given next. 3025 {Start} is the start value of that keyword hash range associated with 3026 this routing table entry. It is interpreted over only the leftmost 3027 significant number of bits of the MD5 128 bits hash range. 3029 {End} is the end value of the keyword hash range associated with this 3030 routing table entry, It is interpreted over only the leftmost 3031 significant number of bits of the MD5 128 bits hash range. 3033 {Assigned To} is the unique ID of the domain to which this route 3034 points to. 3036 {Next Route} is the mnemonic of the outgoing link where the protocol 3037 message should be forwarded next. It could be 'PMCAST' for sending 3038 to parent node, 'CMCAST' for sending to the children over CMCAST 3039 multicast channel or 'SELF' indicating that the message should be 3040 processed locally. 3042 {Unicast} contains the unicast connection details of the designated 3043 MSD server of the domain represented by the {Assigned To} field. 3045 {Multicast?} denotes whether the domain's designated MSD server 3046 identified by {Assigned To} is getting multicast communication 3047 messages from this MSD server or not? If not, then any forwarding to 3048 this domain identified in {Assigned To} must done via unicast. 3050 {Is Temp?} denotes whether this route entry is a temporary one or 3051 not. It is used in dealing with intermittent node failures as 3052 discussed in Section 6.3. 3054 Next, the general routing table maintenance strategy is discussed. 3055 Features that should be included in MSD servers to improve the global 3056 routing infrastructure stability is also discussed in detail. 3058 It is suggested that every MSD server set and use internal parameters 3059 'alpha' and 'beta' for managing the domain count reporting behavior. 3060 Our simulations suggest using {alpha} between 0.4 - 1.0 and setting 3061 {beta} between 1.2 - 2.0 for better performance [SAC10]. One is free 3062 to choose any range of values for {alpha} and {beta} as long as 3063 {alpha} & {beta} > 0.0 and {alpha} < {beta}. The use of {alpha} and 3064 {beta} will become clear in a moment. In order to improve routing 3065 table stability, it is desired that minor changes in service 3066 topography should not lead to major routing overhaul. 3068 Each MSD server maintains three additional parameters {count- 3069 reported}, {count-actual}, and {count-last-modified}. {count- 3070 reported} is the domain count that is being reported periodically to 3071 the parent node through [hello] protocol message. {count-actual} is 3072 the actual number of domain(s) in the service hierarchy rooted at 3073 this domain. Initially the designated MSD server in any domain sets 3074 {count-reported} and {count-actual} to 1. As and when children nodes 3075 are discovered at a particular domain, the {count-actual} value is 3076 updated to reflect the actual count of domains (including self). 3078 If at some point, |{count-actual} - {count-reported}| / {count- 3079 reported} ratio becomes greater than {alpha} but remains less than 3080 {beta}, the MSD server does hash address space reassignment amongst 3081 itself and its children domains in the proportion of the count value 3082 reported by each child node. It updates its routing table to reflect 3083 the address reassignments. But the {count-reported} value remains 3084 unchanged. Also {count-last-modified} is set to {count-actual} value 3085 when the space reassignment is done. An internal reassignment may 3086 again take place when |{count-actual} - {count-last-modified}| / 3087 {count-reported} is more than {alpha} and less than {beta} and 3088 |{count-actual} - {count-reported}| / {count-reported} is still less 3089 than {beta}. These reassignment processes take place only when the 3090 {count-actual} parameter value changes. The internal reassignment 3091 only changes the routing tables in the subtree rooted at the domain 3092 where this reassignment took place. As a result, the routing tables 3093 in the rest of the infrastructure remain unchanged. 3095 If |{count-actual} - {count-reported}| / {count-reported} value 3096 becomes greater than {beta} then set {count-reported} equal to 3097 {count-actual}. This may have routing reconfiguration effects in the 3098 global hierarchy so it is desirable to minimize it by setting a high 3099 value of {beta}. This is a judgment call because setting a higher 3100 value of {beta} may lead to unequal keyword hash-space assignments 3101 among participating domains. The values of {alpha} and {beta} may 3102 not be globally uniform. These values could be independently set 3103 locally irrespective of the values set in other domains. 3105 6.1.1. Protocol Messages and Routing Table 3107 These are the protocol messages that have routing table implications, 3108 namely, [hello], [rep-hello], [null-space], and [add-space]. Let us 3109 see how each of these messages impact the local routing table 3110 management. 3112 [hello] messages allow the child domains to notify the parent node 3113 about their existence and also the domain count value as well. An 3114 MSD server on receiving [hello] messages updates its child list, 3115 every child sends [hello] message periodically every SELF_REPORT_TIME 3116 seconds. If a domain's MSD does not receive a child's [hello] 3117 message for 2 consecutive timeout intervals, it changes that child 3118 status to 'dormant', reassigns the hash-range assigned against that 3119 child domain (if any was assigned in the first place) to either 3120 itself temporarily or to some other active child domain if it could 3121 merge the two hash-spaces (coalesce) into one larger chunk. If still 3122 after MAX_CHILD_REPORT_TIMEOUT_COUNT timeouts, there is no [hello] 3123 received from that particular child node, it should be assumed 'dead' 3124 and any hash-reassignment done temporarily could be made permanent. 3125 The routing table should reflect these changes. 3127 Changes in the number of child domains (known by [hello] messages 3128 receipt or non-receipt) may change the {count-actual} parameter's 3129 value. Any change in this parameter's value shall trigger the 3130 address reassignment algorithm based on the strategy mentioned above. 3131 Other scenarios that could result in hash space reassignments are 3132 receipt of a different hash-space-range from the parent domain than 3133 what was the current overall assignment for this domain, and the 3134 change in domain's status from 'root' to 'non-root' or vice-versa. 3135 These remaining scenarios are discussed next. 3137 [rep-hello] message is sent by the parent domain notifying any child 3138 domain about its existence. If a [rep-hello] message is not received 3139 for MAX_PARENT_REPORT_TIMEOUT_COUNT consecutive PARENT_REPORT_TIME 3140 intervals , the node must try to resync the parent connectivity 3141 details with its local URS using [resync], and then the node may 3142 contact the parent node to notify that it is unable to receive 3143 messages on PMCAST channel. If it still does not receive [rep-hello] 3144 for MAX_TIMEOUT_COUNT timeouts, it must assume root status and assume 3145 ownership of total keyword-hash space. If any child domain exists, 3146 this may cause hash-space reassignment among all its children and 3147 itself proportionately to the individual domain counts reported by 3148 all of them. 3150 [add-space] protocol messages are used to notify periodically to 3151 child domains their hash-space allotment by the parent node. These 3152 messages are sent every ADDRESS_NOTIFICATION_TIME seconds. If a 3153 [add-space] message is received from the parent node that contains 3154 hash-space range values different than what was contained in the last 3155 [add-space] message, it must trigger the hash space reassignment 3156 algorithm at the recipient domain. The node does hash space 3157 reassignments among itself and the children domains proportionately 3158 to the domain counts reported by the children nodes. Routing table 3159 must reflect the changes. 3161 Since the hash-space elements are discrete and not continuous, there 3162 may be cases where few child domains could not be assigned any hash- 3163 space range. In such cases, a [null-space] message is sent to those 3164 domains. 3166 If a [null-space] is received at any domain from its parent domain, 3167 it must reset all routing entries to 'null' and all 'keyword' routing 3168 must be done through the parent domain. The domain must recursively 3169 send [null-space] protocol messages to all its children (if any). 3171 As a final note on routing, every MSD server must run periodically a 3172 database records migration thread. The task of this thread is in 3173 fact very simple, it just cycles through all stored session records, 3174 and if their corresponding 'keyword' hash value now lies outside the 3175 self-maintained/managed hash value range, it must redirect the record 3176 data to appropriate to domain by creating a [ext-register] message 3177 and routing it based on latest routing table. Once such records are 3178 migrated, they should be purged from the database. Note: This 3179 migration thread operates over 'Global Sessions' database only. The 3180 'Domain Local Sessions Record' database is untouched. 3182 6.2. Leader Election Algorithm 3184 If there are multiple MSD servers running in an administrative 3185 domain, then they must be capable of electing one MSD server from 3186 among themselves as the designated MSD server for that domain. In 3187 order to reduce the configuration load on system administrators, it 3188 is recommended to incorporate a leader election module in the MSD 3189 server implementation. Any standard leader election algorithm may be 3190 used. Details of such an algorithm and corresponding protocol 3191 specification is outside the scope of this RFC. 3193 6.3. Node Failures 3195 A node failure in this scheme can create disconnected islands of 3196 multicast sessions search capable networks. A node failure could 3197 result when the designated MSD server fails are there are no backup 3198 MSD servers to take up the responsibility of the failed server. In 3199 some situations, a simultaneous failure of a URS and the designated 3200 MSD server could also cause hierarchy disruptions even when there 3201 might exist backup MSD servers. 3203 If the service hierarchy is disrupted, it can severely impact session 3204 discovery. We present a scheme to prevent hierarchy disruptions in 3205 the face of node failures. 3207 A designated MSD server periodically receives [rep-hello] message 3208 from its parent domain. If it does not receive any heartbeat message 3209 from its parent for MAX_PARENT_REPORT_TIMEOUT_COUNT consecutive 3210 PARENT_REPORT_TIME intervals, it sends a [resync] message to URS to 3211 find the most recent unicast connection details of the parent in case 3212 it has changed, and once it receives the parameters tries to contact 3213 the parent via unicast to notify that it no longer is able to receive 3214 the parent heartbeats on PMCAST or unicast channels. 3216 Currently, when still if no heartbeat message [rep-hello] is received 3217 for total of MAX_TIMEOUT_COUNT consecutive PARENT_REPORT_TIME 3218 intervals, the node assumes root responsibility. This causes 3219 hierarchy disruptions. It would be preferable for this domain to 3220 bypass its parent temporarily and link up to any connected and live 3221 ancestor domain higher up in the hierarchy. 3223 Instead of assuming root capability, the domain whose parent becomes 3224 unresponsive may send via unicast a [tracer] message including a hash 3225 value lying in the parent's overall assigned hash-range and its own 3226 unicast connection details to the overall root node of the original 3227 hierarchy. The purpose of the [tracer] communication is to route the 3228 message depending on the included hash parameter towards the failed 3229 node and find the nearest connected domain from the failed node still 3230 connected in the hierarchy. This [tracer] message downward 3231 propagation is done using unicast only and not using CMCAST channels. 3232 This allows the system to locate the ancestor of the failed node 3233 still connected to the hierarchy. 3235 Once such a domain is located, it uses the unicast details in the 3236 [tracer] message to send a notification to the domain that initiated 3237 the [tracer] providing its own unicast details so that the initiator 3238 can link up to the ancestor node. 3240 The node whose parent failed, may now link up to the ancestor domain 3241 using unicast providing the hash-range assigned to it so that correct 3242 routing may again be established bypassing the failed node. The 3243 ancestor node may report domain count intelligently to its parent 3244 node in order to minimize the hash-range assignment changes until a 3245 significant longer period to allow the failed node to recover and 3246 take back its assigned responsibilities. This would prevent mass 3247 records migration in the network in the face of intermittent but 3248 short duration node failures. 3250 In the meantime the original node must keep on sending [resync] 3251 periodically to URS and if the original parent domain comes online 3252 later, it must link up to it and send 'detach' notification to the 3253 ancestor node. The ancestor must then modify the routing table to 3254 its original state before the node failed. If even after an extended 3255 wait period, the failed node does not come online, the routing 3256 changes may be made permanent at the ancestor domain. 3258 6.4. Data Syncing Among Local MSD servers 3260 A designated-MSD server may choose to sync its internal records 3261 databases with other standby MSD servers in its domain. The syncing 3262 capability and implementation is left up to the software implementers 3263 but is highly recommended to minimize any service disruption in case 3264 the designated MSD server fails and a backup MSD server takes over 3265 its responsibilities. The data sync protocol specification is 3266 outside the scope of this document. 3268 7. Security Considerations 3270 The service proposal represented by this draft uses unicast as well 3271 as multicast to send/receive control protocol messages as well as 3272 data. Multicast and IP unicast (UDP) are used to improve MSD server 3273 efficiency as these use connection-less transmission thereby 3274 resulting is faster turn-around time for each request served. IP 3275 unicast (TCP) is used wherever a strict client-server relationship 3276 exists and where it makes more sense to use TCP based communication 3277 because either some critical data is being transported such as URS 3278 registration or session registration with local MSD server or if a 3279 child node can not receive control packets from parent on PMCAST 3280 channel. 3282 Because of use of multicast, some security issues inherent in 3283 multicast are inherited by this scheme as well. The security 3284 concerns become more pertinent if ASM multicast mode is deployed. 3285 Since the service proposal can coexist in both ASM as well as SSM 3286 multicast deployments, some of the more flagrant security shortfalls 3287 of multicast can be reduced if SSM multicast delivery is used. But 3288 such deployments are beyond our control and system administrators in 3289 participating domains must make their own decisions. 3291 IP unicast as well as multicast data packets can be secured by using 3292 security principles adopted in group membership control and 3293 communication dynamics. During system join-in phase, group key 3294 exchange using appropriate PKCS mechanism could be used, but its 3295 discussion is out of scope of current draft. 3297 In this internet-draft, any node that wishes to be a part of the 3298 service hierarchy just needs to start periodically sending a [hello] 3299 to announce its presence to the parent node and subscribe to PMCAST 3300 to get vital control messages from the parent domain. If a malicious 3301 node wants to disrupt the service hierarchy and try to hog the 3302 keyword space by falsely reporting huge domain counts to the parent 3303 domain, without proper security measures it can do so. A solution 3304 that offers some protection from such a scenario is to allows only 3305 pre-approved nodes to join-in. This can be achieved if the system 3306 administrator of a domain explicitly allows and approves children 3307 domains before they join in and configures its firewall to 3308 selectively allow communication to and from those pre-approved 3309 children domains on pre determined ports from predetermined IPs. 3311 As with any network there is always possibility of DoS attacks. 3312 Registration requests that allows a maximum of 10 keywords could 3313 result in 10 separate [ext-register] protocol messages being 3314 generated. As this scheme tries to use connectionless transmissions 3315 wherever possible/feasible, the architecture can handle DoS a little 3316 better than connection-oriented services. 3318 Can a malicious person do a selective denial of service attack by 3319 removing a registered session record from the MSD databases? 3320 Hopefully not! There is no mechanism to remove a session record once 3321 it is registered and stored. A record is expunged automatically once 3322 its expiration time is reached. The databases are write-in 3323 generally. A limit on expiration times can be set to prevent 3324 situations where a MSD server internal database grows without bounds 3325 due to session records not getting expunged due to unreasonably huge 3326 expiration times set during session registration phase. 3328 A malicious attacker can possibly swamp a legitimate client by 3329 sending [search] requests by spoofing its IP address. Prevention of 3330 such type of attacks again is beyond the scope of current draft. 3331 Further, this draft does not deal with any confidentiality issues. 3333 8. IANA Considerations 3335 This document has no actions for IANA. 3337 9. References 3339 9.1. Normative References 3341 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 3342 April 1992. 3344 [RFC1345] Simonsen, K., "Character Mnemonics and Character Sets", 3345 RFC 1345, June 1992. 3347 [RFC3808] McDonald, I., "IANA Charset MIB", RFC 3808, June 2004. 3349 9.2. Informative References 3351 [ICOMP08] Harsh, P. and R. Newman, "mDNS - A Proposal for 3352 Hierarchical Multicast Session Directory Architecture", 3353 ICOMP 2008, July 2008. 3355 [ICOMP09] Harsh, P. and R. Newman, "Efficient Distributed Search for 3356 Multicast Session Keywords", ICOMP 2009, July 2009. 3358 [SAC09] Harsh, P. and R. Newman, "Using GeoSpatial session tagging 3359 for smart Multicast session discovery", ACM SIGAPP 3360 SAC 2009, March 2009. 3362 [SAC10] Harsh, P. and R. Newman, "Mode Independent Session 3363 Directory Service Architecture", ACM SIGAPP SAC 2010, 3364 March 2010. 3366 [RFC1112] Deering, S., "Host Extensions for IP Multicasting", 3367 RFC 1112, August 1989. 3369 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 3370 Protocol (MSDP)", RFC 3618, October 2003. 3372 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 3373 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 3374 Protocol Specification (Revised)", RFC 4601, August 2006. 3376 [RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance 3377 Vector Multicast Routing Protocol", RFC 1075, 3378 November 1988. 3380 [RFC2201] Ballardie, T., "Core Based Trees (CBT) Multicast Routing 3381 Architecture", RFC 2201, September 1997. 3383 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 3384 2", RFC 2236, November 1997. 3386 [RFC3810] Vida, R., Costa, L., Fdida, S., Deering, S., Fenner, B., 3387 Kouvelas, I., and B. Haberman, "Multicast Listener 3388 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 3389 June 2004. 3391 [RFC3376] Cain, B., Deering, S., Fenner, B., Kouvelas, I., and A. 3392 Thyagarajan, "Multicast Listener Discovery Version 2 3393 (MLDv2) for IPv6", RFC 3376, October 2002. 3395 [RFC4607] Cain, B. and H. Holbrook, "Source-Specific Multicast for 3396 IP", RFC 4607, August 2006. 3398 [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", 3399 RFC 3180, September 2001. 3401 URIs 3403 [1] 3405 [2] 3407 [3] 3409 [4] 3411 Authors' Addresses 3413 Piyush Harsh 3414 UFL/Computer and Information Science and Engineering 3415 289 Corry Village 3416 APT 11 3417 Gainesville, FL 32603 3418 US 3420 Phone: +1 352 327 8786 3421 Email: pharsh@cise.ufl.edu 3422 URI: http://www.cise.ufl.edu/~pharsh/ 3424 Richard Newman 3425 UFL/Computer and Information Science and Engineering 3426 CSE E346 3427 PO Box 116120 3428 Gainesville, FL 32611-6120 3429 US 3431 Phone: +1 352 283 1083 3432 Email: nemo@cise.ufl.edu 3433 URI: http://www.cise.ufl.edu/~nemo/ 3435 Full Copyright Statement 3437 Copyright (c) 2009 IETF Trust and the persons identified as the 3438 document authors. All rights reserved. 3440 This document is subject to BCP 78 and the IETF Trust's Legal 3441 Provisions Relating to IETF Documents in effect on the date of 3442 publication of this document (http://trustee.ietf.org/license-info). 3443 Please review these documents carefully, as they describe your rights 3444 and restrictions with respect to this document.