idnits 2.17.00 (12 Aug 2021) /tmp/idnits54065/draft-bormann-mtp-so-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 22 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 23 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 14 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 406 has weird spacing: '... * This was ...' == Line 408 has weird spacing: '...as an altern...' == Line 512 has weird spacing: '...lticast group...' == Line 616 has weird spacing: '... * In period...' == Line 617 has weird spacing: '...o allow unrel...' == (2 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 1999) is 8369 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0' is mentioned on line 1017, but not defined == Missing Reference: '8' is mentioned on line 1022, but not defined == Missing Reference: '9' is mentioned on line 1023, but not defined ** Downref: Normative reference to an Informational RFC: RFC 1301 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- No information found for draft-kermode-sadp - is the name correct? -- Possible downref: Normative reference to a draft: ref. '7' Summary: 9 errors (**), 0 flaws (~~), 12 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Carsten Bormann, Joerg Ott 2 Expires: December 1999 Universitaet Bremen 3 Nils Seifert 4 Tellique 5 June 1999 7 MTP/SO: Self-Organizing Multicast 8 draft-bormann-mtp-so-02.txt 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Abstract 33 MTP/SO is a reliable multicast protocol based on the earlier 34 protocols MTP (RFC1301) and MTP-2, simplifying the protocol 35 considerably while adding self-organization of the members of the 36 group into a hierarchy of local regions, local retransmissions, local 37 NAK damping, and both global and local forward error correction. 38 MTP/SO retains the coordinated many-to-many multicast model of MTP-2 39 while improving scalability. 41 1. Introduction 43 Multiparty cooperative applications have received much attention over 44 the past years, as has the multicasting of datagrams in the Internet. 45 The Internet datagram multicasting mechanism is not reliable, often 46 requiring a higher level protocol to achieve the level of reliability 47 required for an application. 49 Much of the early work on reliable multicast protocols has assumed 50 relatively stable groups that need to ensure that all messages are 51 eventually received by all members of this well-defined group. 52 Recently, work on loosely coupled teleconferencing has directed 53 attention to a class of multicast applications that scale up to an 54 extent where this assumption is no longer practical. Many other 55 applications in the area of synchronous groupware also do not need 56 the strong property of reliability, but can nonetheless benefit from 57 a multicast protocol providing some weaker form of reliable 58 transport. 60 An interesting multicast transport protocol with a somewhat relaxed 61 view of reliability is defined in RFC 1301 [1]. MTP can be used with 62 unreliable and not necessarily sequence preserving underlying 63 multicast (or broadcast) network protocols such as IP multicast. MTP 64 provides globally ordered, receiver reliable, rate controlled and 65 atomic transfer of messages to multiple recipients. 67 A revised version of MTP, the Multicast Transport Protocol MTP-2, has 68 been used for a number of applications for some time [2]. MTP-2 has 69 been designed to avoid some of the practical problems experienced in 70 using MTP and introduces a number of additional facilities that 71 increase its utility. In particular, MTP-2 no longer has a single 72 point of failure. 74 This document defines Self-Organizing Multicast, MTP/SO. MTP/SO uses 75 MTP-2 as a basis and adds spontaneous self-organization of the 76 members of the group into a hierarchy of local regions. Scalability 77 is increased by providing passive group joining and local 78 retransmission of lost packets, as well as forward error correction 79 (FEC). 81 2. Requirements 83 Even more so than for unicast protocols, there are difficult trade- 84 offs in designing a multicast protocol. It is unlikely that a single 85 reliable multicast protocol can be applicable to all kinds of 86 multicast applications, from a small set of replicated database 87 systems synchronizing their updates, to distributed interactive 88 simulation systems with hundreds of thousands of processes joining 89 and leaving large numbers of groups with high frequency. 91 Any design of a protocol that aims to cover a part of the ground must 92 therefore be explicit about the specific requirements the designers 93 had in mind. Concentrating on any single objective is unlikely to 94 yield a generally applicable protocol. In this section, we list what 95 we perceive to be the main requirements that went into the design of 96 MTP/SO, in order of importance. 98 o Scalability 100 While the actual usage pattern of synchronous group communication 101 software is not yet known, it is clear that groups of wildly 102 different sizes will need to be accommodated. A protocol that is not 103 scalable to large groups with a significant rate of membership change 104 will not be a viable multicast platform. 106 Many existing protocols that focus on reliability require a positive 107 acknowledgment from each recipient to the sender of each message. 108 This does not scale to large groups without elaborate aggregation 109 schemes. Also, group management algorithms that require an 110 acknowledgment from each member to accept a new member are not 111 acceptable in large groups (in particular, building a group creates 112 an n-square problem). 114 As a first level of attack, this scaling problem can be circumvented 115 by using negative acknowledgements (NAKs). Unfortunately, this also 116 conflicts with a strict reliability requirement: Not every failure 117 will be immediately detected, since the normal behavior of a 118 recipient, i.e. being silent, cannot be distinguished from a silent 119 failure. There is a trade-off between scalability and the kind of 120 reliability that can be realized. 122 o Efficiency 124 A reliable multicast protocol should be comparable in performance to 125 special protocols specifically designed for an application. Just as 126 TCP generally is slightly less efficient than a specially designed 127 protocol would be, some more packets and additional per-packet 128 overhead as well as some additional processing time will be 129 tolerable. However, the protocol needs to be in the same class of 130 overhead to be applicable to an application. 132 o Robustness and Reliability 134 A reliable multicast protocol should obviously be ``reliable'' in 135 some sense. Given the conflict with scalability, we define 136 reliability to mean: A recipient can (within bounded time) find out 137 when it is failing or being partitioned from active senders. A 138 sender is assured (with sufficient probability) that all its messages 139 reach within bounded time all recipients that are not failing or 140 being partitioned. 142 Obviously, this strict definition of reliability needs to be 143 complemented by some measure of robustness: A protocol that declares 144 failure or creates significant delays in the face of trivial errors 145 may meet this definition but is not useful. In a teleconferencing 146 environment, a desirable robustness property is the ability to 147 continue operating within partitions should the group become 148 partitioned. Ultimately, the applications that use the multicast 149 transport platform should be the ones to decide when the situation 150 has deteriorated to a point where continuing is meaningless. 152 o Ordering 154 Many applications are simplified considerably when (at least a 155 certain subset of all) messages exchanged in the group arrive in the 156 same order at all recipients, even if originated at different 157 senders. This requirement distinguishes MTP/SO from other multiple 158 sender multicast protocols such as SRM [5] that work best when the 159 shared state of the multicast group is the (commutative and 160 associative) sum of the independent contributions of all 161 participants. 163 3. Overview 165 This section gives an overview over the protocol functions of MTP/SO. 166 (Note to readers that have seen MTP or MTP-2: This overview is given 167 in terms that are more generic than those used in older protocol 168 definitions. In particular, the terms group, coordinator, sender, 169 and receiver have been substituted for the traditional terms web, 170 master, producer, and consumer.) 172 In MTP/SO there are three different roles of members in a group: 173 coordinator, sender and receiver. The coordinator provides the 174 message ordering for all members in a group and oversees the global 175 rate management. Senders send data in messages (each sent as a 176 sequence of one or more data packets) after obtaining a token from 177 the designated coordinator. Receivers receive these messages and 178 request the retransmission of packets that did not arrive. 180 In MTP/SO, many actions such as retransmitting control packets or 181 requesting retransmissions depend on a time interval that is a 182 parameter to the whole group. This interval is called heartbeat and 183 is measured in microseconds. 185 3.1. Global ordering 187 The coordinator assigns a global sequence number to each message. In 188 the simplest mode of transmission, before a sender is allowed to 189 start sending a new message, it has to obtain a token from the 190 coordinator. This can be done by transmitting a special request 191 packet to the coordinator or by sending the request along with data 192 packets belonging to other messages. The coordinator answers with a 193 confirm packet, which contains the sequence number for the new 194 message. Senders will then send this sequence number in every data 195 packet belonging to the message. It is the responsibility of the 196 receivers to deliver messages in the correct order to the 197 applications, if sequenced delivery has been specified for a message. 199 This results in an ordering class called ``global ordering'', which 200 means that even when there are many senders simultaneously sending 201 messages, every receiver will receive the messages in the same order 202 (which comes close to the order in which the tokens were requested). 204 As the sequencing will quite often result in an additional delay (for 205 example when a short message is preceded by a very long one), 206 applications can assign messages to different streams. A message is 207 delivered irrespective of messages belonging to other streams, even 208 if these carry lower sequence numbers. By using streams, 209 applications can avoid unnecessary delays, simply by assigning 210 independent messages to different streams. 212 A message that can be processed independent of the ones preceding it 213 can be marked with a sequencing_off bit. Messages so marked can be 214 immediately delivered to the application by receivers, even if the 215 stream numbers of preceding messages are still unknown. 217 Normally the coordinator grants the tokens in the same order the 218 token request packets are received. If there is a need to transmit 219 some messages with a higher priority, applications can assign a 220 priority to every message. This priority is only considered while 221 granting a token (hence only when there are many tokens requested at 222 the same time) and has no effect on the transmission rate of the 223 message once a token has been assigned. As a result, when a sender 224 sends messages with different priorities, it is no longer guaranteed 225 that these are received in the same order they were queued for 226 sending -- if they are in the same stream, they are, however, 227 received in the same order by all receivers (including the sender). 229 3.2. Rate and Load management 231 Rate management is overseen by the coordinator. A parameter global 232 to the group defines the maximum bandwidth to be used by the group. 233 The coordinator dynamically adjusts a per-message parameter called 234 window to divide up the total rate into the number of tokens 235 currently granted, controlling the inter-packet-interval at which 236 senders pace data packets belonging to one message. So the 237 coordinator can ensure that the maximum throughput defined for the 238 group is not exceeded. 240 An argument often heard against using a central coordinator is that 241 it might limit scalability by becoming a bottleneck. First, it needs 242 to be noted that in the worst case (all messages are one packet long) 243 the coordinator handles three times as many packets as each other 244 group member that does not send: one (small) token request, one 245 (small) token confirm, and the actual reception of the data packet. 246 There is no scalability problem involved, except the general problem 247 that many active senders will generate many packets (independent of 248 whether coordinated or not). 250 There remains one problem, however. If more members desire to send 251 than can be granted a token at any one time, a distributed queue 252 needs to be formed. To be able to sustain large queues of senders, 253 the coordinator maintains a global damping factor d for token 254 requests. A new value for d is distributed every heartbeat by the 255 coordinator (as a rounded-down base 2 logarithm). In normal 256 operation, d is 1. When requesting a token or retransmitting this 257 request, senders use the current value of 1/d in each heartbeat as 258 the probability for actually sending the request in this heartbeat. 259 Senders echo the damping factor used in each token request actually 260 sent. The coordinator weighs the token requests by their damping 261 factor to allocate tokens. Piggy-backed token requests are 262 considered to have a damping factor of one (no damping is applied to 263 piggy-backed token requests). 265 The coordinator computes d as: 267 max(1, w / (max(12,k)*2) - 1) 269 where w is the sum of the echoed damping factors received in token 270 requests during the last heartbeat and k is an exponentially weighted 271 moving average of the number of token requests granted in recent 272 heartbearts. 274 3.3. Atomicity 276 Atomicity (arrival of a message at all members or at none of the 277 members) is a desirable property of a group communication protocol. 278 Unfortunately, full atomicity requires collecting positive 279 acknowledgements from all group members until a message can be acted 280 upon, too heavy-weight for the goals of MTP/SO. Instead, MTP/SO 281 defines a lighter-weight form of atomicity that is still useful for 282 many applications. 284 At any point in time, each message is assigned a state by the 285 coordinator: pending, accepted, or rejected. 287 The state of a message is set to accepted when the coordinator did 288 receive the complete message. As soon as a sender notices one of its 289 messages to be accepted, it sends an acknowledgement of successful 290 transmission to its application. Such an acknowledgement does not 291 mean that every receiver received the message. It only guarantees 292 that at least the coordinator was able to receive it correctly. (It 293 also provides the sequence number assigned to the message so that the 294 application can order its own messages with respect to other messages 295 it may have received). 297 A message marked as rejected was not completely received (even after 298 requesting retransmissions) by the coordinator. Normally, every 299 receiver will drop such a message and the sender of the message will 300 indicate an unsuccessful-transmission error to its application. 302 Receivers do not deliver pending or rejected messages to the 303 application. If a specific receiver does not completely receive a 304 message (even after requesting retransmissions) that is finally 305 marked by the coordinator as accepted, it will signal this as an 306 unsuccessful-reception error to its application. 308 In summary, it is guaranteed that a message was either delivered 309 correctly to every receiver, that it was delivered to no receiver and 310 the sender is signalled an error, or that any receiver that did not 311 receive the message is signalled an error. (Of course, the protocol 312 works hard to minimize the number of such errors, but the above 313 statements are guarantees of the protocol.) 315 Atomicity increases the message latency: applications need to wait 316 for the accepted state propagating from the coordinator before they 317 can act on a message. In order to allow every member to quickly 318 learn about the state of messages, every packet contains a copy of 319 the most recent information available about the state of the most 320 recent messages. If application semantics do not require atomicity, 321 unnecessary delay can be avoided by marking a message such that it is 322 delivered to applications even before accepted by the coordinator 323 (atomicity_off). 325 3.4. Retransmission 327 Receivers request retransmissions of data packets when there is a gap 328 in the sequence numbers of data packets received for a message or if 329 no further data packet has arrived for more than one heartbeat while 330 the message is still incomplete. In case all data packets for a 331 message have been lost, this will be recognized from the message 332 state of packets from following messages or when the coordinator 333 propagates the state of the most recent messages. In any case, the 334 request for retransmission can be generated at the latest after two 335 full heartbeats. 337 Retransmission requests, or NAKs (negative acknowledgements) for 338 short, are multicast to the group to reduce the implosion problem. 339 Receivers dither the time at which they send NAKs and postpone 340 sending a NAK when they have recently received one or more NAKs that 341 together cover the same set of packets. 343 In order to answer NAKs, senders keep a copy of every data packet 344 they sent. To limit the number of packets stored, senders are 345 allowed to discard these copies after a defined period of time which 346 is measured in heartbeats and depending on a special factor called 347 retention. After retention+4 heartbeats the copies are no longer 348 available and requests for retransmissions received after that period 349 are ignored. This makes sure packets are available for at least 350 retention retransmissions. 352 Nonetheless there is a nonzero probability that all retransmissions 353 (or retransmission requests) related to a packet are lost and some 354 receivers do not receive the message correctly. For example a 355 network partitioning that lasts longer than heartbeat*retention will 356 result in lost messages. 358 This sounds undesirable, but it is similar to the retry limit used in 359 positively acknowledged protocols, only that the normally relatively 360 small value of heartbeat*retention puts a limit to the length of an 361 outage that can be tolerated. We assume that the application 362 protocol will have a way to handle receivers that experience such a 363 long gap in reception, because it already needs a way to treat new 364 members that appear late in the group. Note that for applications 365 where this is undesirable, MTP/SO could be augmented by the 366 equivalent of log servers [3]. In any case, MTP/SO guarantees that 367 when a message was not completely received by every receiver, either 368 the affected receivers or the responsible sender will indicate the 369 error to the application. 371 3.5. Self-organization and Repetitors 373 Once MTP/SO groups get large, even the handling of NAK-based 374 retransmission traffic becomes a scalability problem. As with many 375 scaling problems, the obvious solution is to introduce some form of 376 hierarchy into the group. This allows at least some of the NAKs and 377 resulting retransmissions to be handled locally within trunks and 378 branches of that hierarchy. As MTP/SO is a many-to-many protocol, it 379 does not make much sense to base the hierarchy on the multicast tree 380 from any specific sender (including the coordinator, which generally 381 is not the sole sender and which may transfer its role to another 382 member during the activity of the group). 384 Instead, MTP/SO introduces the concept of a regional repetitor*. 385 Receivers multicast NAKs locally before multicasting them to the 386 entire group. Repetitors that have previously received the requested 387 data, retransmit locally after receiving a local NAK. Repetitors 388 that don't have the data simply send a NAK to the next higher level 389 of hierarchy, up to the whole group (where, finally, the sender 390 replies with another copy of the data). 392 A prerequisite to this mechanism is a way to do a local multicast (of 393 a NAK as well as of a retransmission). In current IP multicast 394 implementations, one way to define such regions is with TTL threshold 395 scoping; together with an appropriate protocol; administrative 396 scoping provides a similar method [7]. The algorithms described in 397 the rest of this section work best when such a scoping mechanism is 398 in effect; leaks or other imperfections in the scoping boundaries do 399 not cause catastrophic failures, though. The following discussion 400 assumes three levels of local scopes, e.g., site, country, and 401 continent; the exact choice of number and extent of scopes is a 402 global parameter of the group. 404 With three local scopes and one global scope, each group member is by 405 _________________________ 406 * This was called ``repeater'' in earlier presentations of 407 MTP/SO [6]. We are now avoiding this term as it is sometimes used 408 as an alternative term for a transport layer ``bridge'' between 409 disconnected multicast domains. 411 definition in four scopes, where each local scope is contained by the 412 next higher scope in the hierarchy. Any member that takes on a 413 receiver role can also decide to be a potential repetitor for any of 414 the local scopes (e.g. depending on the cost structure of the 415 Internet service or on the availability of local memory space). 417 For scopes that contain only one member, it does not matter whether a 418 member considers itself to be a repetitor for that scope or not. For 419 scopes that contain more than one member, a protocol is needed that 420 makes this fact known and selects one scope member as the repetitor. 421 This protocol needs not necessarily ensure that there is exactly one 422 repetitor for each scope at any time, as the retransmission protocol 423 still works without a repetitor or with more than one repetitor per 424 scope, albeit less efficient. 426 Repetitor selection should favor the ``best'' member in the scope, 427 i.e. a member that has particularly good reception from the senders, 428 as it is most likely that this member will have received the data to 429 be able to perform a local retransmission. Each potential repetitor 430 therefore maintains a reception quality parameter that, on a first 431 level of approximation, tallies the quotient of the number of 432 recently correctly received packets to the number of packets that 433 should have been received. 435 Members that consider themselves repetitor for a scope periodically 436 multicast a repetitor announcement message within the scope, 437 containing the current value of the reception quality parameter. 438 Potential repetitors observe these messages. If, within the most 439 local scope, a potential repetitor has a considerably better 440 reception quality parameter than the current repetitor, it sends a 441 repetitor announcement at the start of its next heartbeat interval 442 and assumes the role of the repetitor. Only the repetitors of the 443 most local scope compete for the repetitor role of the next higher 444 scope, and so on. (A new repetitor that displaces a member that was 445 repetitor at higher level scopes also announces itself as repetitor 446 at these higher level scopes.) 448 To better cope with repetitor failure, receivers that are not 449 repetitors send NAKs at the most local scope first and escalate them 450 up the hierarchy if neither a retransmission nor a more global NAK 451 follows within one heartbeat. Repetitors for a set of scopes begin 452 sending NAKs within the next higher scope and then escalate them the 453 same way. Retransmissions always occur at the highest level of scope 454 that the NAKs leading to that retransmission carried (NAKs have a 455 scope field for this purpose). 457 A repetitor that leaves a group simply sends a repetitor announcement 458 with reception quality zero. A repetitor that crashes stops sending 459 repetitor announcements, causing potential repetitors to start 460 sending repetitor announcements after a time interval that is 461 inversely related to their reception quality parameter. 463 3.6. Coordinator function 465 As it is responsible for assigning tokens and updating the message 466 state, the coordinator plays a central role in MTP/SO. If the member 467 carrying the coordinator function leaves the group, the coordinator 468 function will be passed to one of the remaining members 469 automatically. 471 To avoid the coordinator being a single point of failure, MTP/SO 472 provides a coordinator recovery function. This allows the group to 473 elect a new coordinator when the old one crashes or becomes 474 unreachable. The new coordinator will then collect all information 475 needed from the group members so that no information is lost. (This 476 protocol should be, but is not yet, integrated with the repetitor 477 function.) 479 In order to enhance the performance of MTP/SO it may be useful to 480 actively influence which member performs the coordinator function. 481 For example if only one member will send messages for a longer period 482 of time, the group can migrate the coordinator function to that 483 member, thereby avoiding the overhead caused by requesting and 484 obtaining tokens (between one and two packets for every message). 485 MTP/SO allows either to request the coordinator function for oneself 486 or the coordinator to pass the coordinator function to another 487 member. 489 3.7. Membership classes 491 Not all members of the group will be in a position to take over the 492 functions of a coordinator or of a repetitor. We therefore 493 distinguish several ``classes'' of members: 494 | 495 class | description 496 ------+----------------------------------------------------- 497 1 | normal member, potential coordinator and repetitor 498 2 | normal member, potential repetitor 499 3 | normal member 500 4 | unreliable receiver, normal sender 501 5 | unreliable member 503 Most members of an MTP/SO group will be class 1 members, i.e. they 504 are prepared to take over the coordinator role if this is required in 505 a coordinator recovery*. Class 2 members do not want to take on this 506 role (for application reasons or for reasons of limited resources), 507 but compete for the repetitor function. Class 3 members take over 508 neither special function, but take part as normal members in the 509 group; in particular, they are allowed to send NAKs. 510 _________________________ 511 * Instead, a single member can be designated fixed coordinator 512 by assuming class 0. This means that the multicast group shares 513 its fate with the class 0 coordinator. 515 Class 4 members never send NAKs. Their reception of messages in the 516 group is therefore unreliable. Nonetheless, they can originate 517 messages that are reliably received by the class 3 or higher members 518 of the group. 520 Class 5 members listen only; the only packet type they can send to 521 the group is unreliable multicast datagrams (not yet described in 522 this version of the draft). When a minimum quality of 523 transmission/reception is defined for the group (see group[info] 524 packets below), members may have to downgrade themselves to class 5 525 when they find out their own quality has dropped below the acceptable 526 level. 528 To aid class 4 and class 5 members, and as a general optimization, 529 the multicast group can be configured to immediately add a percentage 530 of redundancy packets to the data packets sent. This allows the 531 receivers to reconstruct missing data packets by interpreting these 532 redundancy packets. Redundancy packets also can be independently 533 added by repetitors based on the local NAK rate. 535 4. Protocol Definition 537 4.1. Notational Conventions 539 For convenience, the datagrams transmitted by MTP/SO group members 540 are called packets in this document. 542 MTP/SO packet types are written major[minor], where major is the 543 major type of the packet and minor is the subtype within the major 544 type. E.g., there are data[data] packets as well as data[eom] 545 packets. 547 4.2. Protocol Functions and Packet Types 549 o Heartbeat 551 All members operate on a time line that is divided into heartbeats. 552 The nominal length of a heartbeat is a global parameter of the group. 553 The actual heartbeat boundaries (or heartbeats for short) are 554 dithered around the nominal value. Most protocol actions are 555 performed at the start of a new heartbeat interval. An exception is 556 the actual transmission of data packets, which is evenly distributed 557 over the heartbeat interval to which the data packets are allocated. 558 Also, token requests (and token request cancellations) can be unicast 559 to the coordinator and be responded to by the coordinator at any 560 time. 562 o Global Ordering 564 A sender that wants to send a message applies for a token by 565 unicasting a token[request] packet to the coordinator. 567 Alternatively, the sender can include a token request field in a data 568 packet that is sent under a previously obtained token. 570 As soon as a token becomes available, the coordinator replies with a 571 token[confirm] containing a new global sequence number, under 572 consideration of the queue of token requests and the priority of the 573 token request. The sender uses this global sequence number as the 574 message number in every data packet pertaining to this message. 576 o Message Acceptance 578 The coordinator maintains the message acceptance state for recent 579 messages. For the 12 most recent messages, the message acceptance 580 state is disseminated in every packet. Packets sent by the 581 coordinator contain the current message acceptance state; packets 582 sent by other members contain a copy of the most recent message 583 acceptance state available to that sender (for data packets, this is 584 often the state obtained via the token[confirm] packet). As the 585 field that is used to disseminate that state only has 12 entries, the 586 number of messages that can be pending at any point in time is 587 limited. 589 To ensure that the most recent message acceptance state is always 590 disseminated, the coordinator sends a group[info] packet at least* in 591 every heartbeat in which no other member is scheduled to send packets 592 based on tokens sent out. 594 o Retransmissions 596 At each heartbeat, receivers that are missing packets of a message 597 multicast nak[request] packets (see also the discussion of self- 598 organization and repetitors above). A nak[request] contains a list 599 of ranges of sequence numbers for one or more messages. Ranges can 600 be open, i.e. implicitly include all further packets when the ending 601 packet number is not known. A nak[request] that is received by a 602 receiver postpones sending a nak[request] for the set of packets 603 listed in the nak[request]. Empty nak[request] packets are never 604 sent. 606 4.3. Addresses 608 A MTP/SO group has one group address and as many member addresses as 609 there are members. 611 The member address is the combination of a 128-bit IPv6 host address 612 (possibly in IPv4 compatibility format, i.e. with 96 bits of leading 613 zeroes) and a 16-bit UDP port number. 615 _________________________ 616 * In periods of continuous activity, additional group[info] 617 packets are sent at a reduced rate to allow unreliable receivers 618 to join. 620 The group address is the pair of a 128-bit IPv6 multicast address 621 (again, possibly IPv4 compatible) and a group-ID. The group-ID 622 simply is the member address of the current coordinator. 624 MTP/SO multicasts always use the UDP destination port number 47112 625 (to be assigned) and the UDP source port number from the member 626 address. MTP/SO unicasts use UDP source and destination port numbers 627 in the range 47112+1 to 49152-1 (note that the number 49152 marks the 628 end of the medium priority port number space in some current IP 629 multicast router implementations). 631 4.4. Packet Formats 633 Figure 1: Standard packet header 634 0 1 2 3 635 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Version | Type | Mod | (Port part) | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+-+ 639 | (Address part) | 640 +- -+ 641 | | 642 +- For multicast packets: Group ID -+ 643 | | 644 +- -+ 645 | | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Heartbeat | Coordinator State Sequence Number | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Retention | Message Acceptance Sequence Number | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 |T| Number|Prio | |Mes|sag|e A|cce|pta|nce| St|ate| Ar|ray| | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | Window | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 The standard packet header contains the following fields: 658 o Version 660 For the current version of MTP/SO, version is always 3. 662 o Type, Mod 664 Packet type and type modifier (subtype). 666 o Group ID 668 For multicast packets, this field gives the member address of the 669 current coordinator. For unicast packets, this field is not used. 671 o Coordinator State Sequence Number 673 A sequence number for the version of the coordinator state that is 674 disseminated with this message. 676 o Message Acceptance Sequence Number, Message Acceptance State Array 678 Let n be the message acceptance sequence number, then message 679 acceptance state array contains the most recent message acceptance 680 states known for messages n-1 to n-12: 682 0 pending 683 1 accepted 684 2 rejected 685 3 (reserved) 687 o T, Number, Prio 689 If the T bit is set, Number gives the serial number and Prio the 690 priority of a token request piggybacked in this packet. 692 o Heartbeat, Retention, Window 694 Current values for these three global parameters of the group. These 695 parameters are given as pseudo-floating-point numbers: 697 parameter bits mantissa (msb) exponent (lsb) unit 698 ----------------------------------------------------------------------------------- 699 heartbeat 8 3 5 microseconds (0 to 7*2^31) 700 retention 8 4 4 1 (0 to 15*2^15) 701 window 16 11 5 microseconds (0 to 2047*2^31) 703 Figure 2: token[request] 704 0 1 2 3 705 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 |1| Number|Prio |1| Number|Prio | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 |1| Number|Prio | . . . . . . . . . . . . . . . |0 0 0| dlb | 710 +-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+ 712 A token[request] packet is unicast from a member to the coordinator 713 to apply for one or more tokens. Each of these requests for a token 714 contains a serial number of that request plus a request priority. 715 The first token request is carried in the token request part of the 716 standard header; additional token requests can be sent in the packet 717 type specific part following the standard header. This part ends 718 with a byte echoing the base 2 logarithm of the damping factor used; 719 this byte can be left off if dlb is zero. 721 Figure 3: token[confirm], token[cancel] 722 0 1 2 3 723 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | New Message Sequence | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | Number | 728 +-+-+-+-+-+-+-+-+ 730 A token[confirm] is unicast from the coordinator to the member that 731 requested the token. A token[cancel] can be used by the token 732 holding member to return the token to the coordinator. 734 Figure 4: data packets (except data[eom]) 735 0 1 2 3 736 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | stream number | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 |S|A|R|0 0|O| L | Message Sequence Number | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Packet Sequence Number | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | Data | 745 : : 747 The S bit, if set, indicates that ordered delivery is not required 748 for this message (``sequencing_off''). The A bit, if set, indicates 749 that atomic delivery is not required for this message 750 (``atomicity_off''). The R bit, if set, indicates that this message 751 is not transmitted reliably, i.e., the producer is not going to 752 answer any nak[request]s. Consumers are expected to wait for any 753 missing packet of this message for one heartbeat and then mark the 754 message as not received. The O bit (``original'') is set only for 755 the first transmission of the data packet by the original sender. It 756 is reset for any kind of retransmission (regardless whether performed 757 by the original sender or not). L (``level'') is a binary number 758 ranging from 0 to 3. Level 0 indicates a global transmission; levels 759 1 to 3 indicate transmission of the packets at the second most global 760 to most local level scope, resp. (For a retransmission, the 761 transmission level indicates the scope in which this data packet was 762 sent; lower level repetitors can use this information to decide 763 whether they can defer their own retransmissions.) 764 Figure 4a: data[eom] 765 0 1 2 3 766 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | stream number | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 |S|A|R|0 0|O| L | Message Sequence Number | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Packet Sequence Number | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | 0 (AL) | | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+ 776 | | 777 +- -+ 778 | | 779 +- original sender's member address -+ 780 | | 781 +- -+ 782 | | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 : authentication information (optional) : 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | Data | 787 : : 789 To ensure that the original sender of a message becomes known even if 790 the only packets a receiver has received from this message were 791 repetitor retransmissions, the data[eom] packet differs from the 792 other data packets in that it contains a copy of the original 793 sender's member address. (Note that this information is redundant 794 for packets that have the O-bit set; it is retained in favor of a 795 common packet format for all cases.) With an optional authentication 796 protocol (not specified in this version of the document), 797 authentication information can be given with this last packet of the 798 message; the length in 32-bit words is in AL. 800 Figure 4b: data[fec] 801 0 1 2 3 802 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | 0 | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | FEC Type | FEC Parameter | FEC Data Size | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | | 809 + FEC Data (including modified header) + 810 : : 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | 0 | Message Sequence Number | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | Packet Sequence Number | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | 0 | Message Sequence Number | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | Packet Sequence Number | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 : : 822 Senders and repetitors can send FEC packets in addition to (or 823 instead of) data packets. A data[fec] packet contains forward error 824 correction information computed out of one or more original data 825 packets, including their headers, where the port part of the group 826 address is replaced by a two-byte original packet length field and 827 the rest of the group address is left out; these data packets are 828 each identified by their message sequence number and packet sequence 829 number. FEC data size is the total size of this information. The 830 resulting information (starting at a two-byte boundary) is padded to 831 a four-byte boundary. Only data packets with the same group address 832 can be combined; they are sent with a copy of this group address in 833 the header of the data[fec] packet. FEC type and parameter define 834 the exact FEC code used; FEC type 1 is defined as XOR. 836 Figure 5: nak[request] 837 0 1 2 3 838 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | 0 | L | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 |F| 0 | Message Sequence Number | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Packet Sequence Number (Low) | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Packet Sequence Number (High) | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 |F| 0 | Message Sequence Number | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | Packet Sequence Number (Low) | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Packet Sequence Number (High) | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 : : 856 The F bit, if set, indicates that, starting at the packet sequence 857 number (low), all packets from the given message are missing. As 858 with data packets, L gives the scope level at which this NAK is being 859 multicast. NAK request packets inhibit the transmission of further 860 such packets from other potential transmitters (for one heartbeat) 861 only at the level of scope given. A retransmission that is a 862 response to a NAK request should be sent at the level of scope given. 864 Figure 6: status[request], status[deny] 865 0 1 2 3 866 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | 0 | L | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | 0 | Message Sequence Number | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | 0 | Message Sequence Number | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 : : 876 A status request packet can be multicast by a member to request 877 status for messages that already have scrolled off the message 878 acceptance state array in the standard header. A status deny 879 response indicates that the retention time for keeping information 880 about the status of the messages has passed. 882 Figure 7: status[info] 883 0 1 2 3 884 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | 0 | 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 |U| S | 0 | Message Sequence Number | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 |U| S | 0 | Message Sequence Number | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 : : 894 Responding to status requests, a repetitor (for local scopes) or the 895 coordinator can multicast status info. The U bit, if set, indicates 896 that the status of the given message is unknown. The S field gives 897 the message acceptance state as in the message acceptance state 898 array. 900 Figure 8: group[seek] 901 0 1 2 3 902 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | Scope | 0 |C|K| 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | Group Name . . . 907 +-+-+-+-+-+-+-+-+- 909 The K-bit, if set, indicates that reliable receiver status 910 (membership class 1 to 3) is intended, i.e., that an explicit 911 acknowledgement for this member has to be given within a group[info]. 912 The C-bit, if set, indicates that the transmitter is a potential 913 coordinator (membership class 1); it causes other potential 914 coordinators with a higher member address to back off. The scope 915 field gives the actual scope in which this packet was transmitted 916 (this cannot just be given as a scope level number as the actual 917 scope levels used in this group may not yet be known to the 918 transmitter). 920 Figure 9: group[info] 921 0 1 2 3 922 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | Quality | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | Activity | 0 | dlb |E| L | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | TTL Scope 0 | TTL Scope 1 | TTL Scope 2 | TTL Scope 3 | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | Network Packet Size | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | min. Receive Quality | min. Send Quality | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | Group Name Length | Group Name ... : 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 936 : (zero-padded to 4 byte alignment) | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 : type | length | extension : 939 :-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 940 : : 941 :-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-: 942 : type | length | extension : 943 :-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 944 : : 946 The group[info] packet is periodically transmitted by the coordinator 947 and by each repetitor to ensure that all group members are aware of 948 the global parameters of the group and of the quality of the current 949 repetitor. 951 Three parameters give dynamic information about the transmitter and 952 about the group: Quality is the (0,16 bit fixed point) product of 953 reception and transmission quality of the transmitter. Activity is a 954 measure for the recent activity of this group (useful for merging 955 decisions by applications). The dlb field gives the base-2 logarithm 956 of the current token request damping factor d (i.e., dlb is normally 957 zero unless damping is required). 959 The other fields of the packet give global group parameters that 960 usually are constant: The E-Bit (``elect'') is set for group[info] 961 packets originated by the coordinator in case it is willing to 962 transfer the coordinator function to a higher quality member; it 963 requests other potential coordinators to announce their quality (if 964 better) via group[info]. L gives the scope level, and, indirectly, 965 the source of the group[info]: level 0 packets are originated by the 966 coordinator or by other potential coordinators (the latter if the 967 source address is not equal to the coordinator part of the group 968 address), level 1 to 3 packets are originated by repetitors of the 969 respective level. Analogously, the TTL fields provide the TTL scopes 970 of the levels: TTL 0 is the scope of the entire group, TTL 1 to TTL 3 971 give the scopes of the most global to most local repetitor levels. 972 Setting the scope for a level to zero indicates that this level is 973 not in use. The fields minimal send quality and minimal receive 974 quality give minimum levels of quality for a member that wants to 975 send reliable messages or that wants to request retransmissions 976 (reliable reception); if not met, they cause the member to assume a 977 lower membership class. 979 At the end of the fixed part of group[info] packets, extensions can 980 be added. Their type is identified by a one-byte type code their 981 length given by a one-byte length field, giving the number of 32-bit 982 words beyond the initial one in this extension. 984 Figure 9a: group[info] extension for member acks 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 : 1 | 4 | (Port part) : 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+-+ 988 : (Address part) : 989 +- -+ 990 : Acknowledged : 991 +- Member-Address -+ 992 : : 993 +- -+ 994 : : 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 Type 1 group[info] extensions are used to carry an acknowledgement 998 for a group[seek] requests by a member that needs to achieve reliable 999 reception status quickly (K-bit in group[seek] set). 1001 4.5. Summary of packet types 1003 packet type type[code] multi/uni sent by see Figure 1004 -------------------------------------------------------------------------- 1005 data[data] 0[0] m C,R,s 4 1006 data[eom] 0[1] m C,R,s 4a 1007 data[ceom] 0[3] m C,R,s 4*) 1008 data[fec] 0[4] m C,R,s 4b 1009 nak[request] 1[0] mu r 5 1010 group[info] 2[0] m C,R 9 1011 group[seek] 2[1] m C,R,s,r 8 1012 token[request] 4[0] u s 2 1013 token[confirm] 4[1] u C 3 1014 token[cancel] 4[2] u s 3 1015 status[request] 5[0] m C,R,s,r 6 1016 status[info] 5[1] m C,R 7 1017 coord[suspected] 6[0] m R,s,r *) 1018 coord[inforeq] 6[4] u p *) 1019 coord[info] 6[5] u C *) 1020 coord[statusreq] 6[6] m p *) 1021 coord[status] 6[7] m R,s,r *) 1022 coord[give] 6[8] u C *) 1023 coord[accept] 6[9] u p *) 1025 multi/uni: m is multicast, u is unicast. 1027 sent by: C is coordinator (p is potential coordinator), R is 1028 repetitor, s is sender, r is receiver. 1030 *) Not yet described in the present version of the document. 1032 5. References 1034 [1] S. Armstrong, A. Freier, K. Marzullo: ``Multicast Transport 1035 Protocol'', RFC 1301, February 1992. 1037 [2] C. Bormann, J. Ott, H.-C. Gehrcke, T. Kerschat and N. Seifert: 1038 ``MTP-2: Towards Achieving the S.E.R.O. Properties for Multicast 1039 Transport'', International Conference on Computer Communications 1040 and Networks (ICCCN 94), 1994 (available from ftp://ftp.cs.tu- 1041 berlin.de/pub/local/kbs/mtp/doc/sero.ps). 1043 [3] Holbrook, H.W., Singhal, S.K., and Cheriton, D.R., Log-based 1044 Receiver-Reliable Multicast for Distributed Interactive 1045 Simulation. SIGCOMM '95, Cambridge, MA, August, 1995. 1047 [4] N. Seifert, C. Bormann, J. Ott: MTP/SO: Self-Organizing 1048 Multicast, First Multicast-Workshop, GI/TU Braunschweig, May 1049 1999. 1051 [5] S. Floyd, V. Jacobson, S. McCanne: A Reliable Multicast 1052 Framework for Light-weight Sessions and Application Level 1053 Framing, SIGCOMM '95, Cambridge, MA, August, 1995. 1055 [6] C. Bormann, J. Ott, N. Seifert: MTP/SO: Receiver-Reliable 1056 Coordinated Many-to-Many Multicast, Presentation at the SIGCOMM 1057 96 Workshop on Matters Mbone (``SIG-Bone''), Palo Alto; 1058 http://www.cs.ucl.ac.uk/staff/jon/sigbone.html, 27-August-1996. 1060 [7] R. Kermode: Scoped Address Discovery Protocol (SADP), November 1061 1998, Internet-draft draft-kermode-sadp-00.txt. 1063 6. Authors' addresses 1065 Carsten Bormann, Joerg Ott 1066 Universitaet Bremen FB3 TZI 1067 Postfach 330440 1068 D-28334 Bremen, GERMANY 1069 cabo, jo@tzi.org 1070 phone +49.421.218-7024, 201-7028 1071 fax +49.421.218-7000 1073 Nils Seifert, Joerg Ott 1074 Tellique GmbH 1075 Gustav-Meyer-Allee 25, Haus 12 1076 D-13355 Berlin, GERMANY 1077 se, jo@tellique.de 1078 phone +49.30.46307-551, -550 1079 fax +49.30.46307-579