idnits 2.17.1 draft-crowcroft-rmfp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 112 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 24 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 165 has weird spacing: '...rotocol uses ...' == Line 836 has weird spacing: '...session has t...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'TIBnet' is defined on line 990, but no explicit reference was found in the text == Unused Reference: 'Vicisano98' is defined on line 994, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Clark90' -- Possible downref: Non-RFC (?) normative reference: ref. 'Diot97' -- Possible downref: Non-RFC (?) normative reference: ref. 'SRM' -- Possible downref: Non-RFC (?) normative reference: ref. 'Fuchs98' -- Possible downref: Non-RFC (?) normative reference: ref. 'Hofmann97' -- Possible downref: Non-RFC (?) normative reference: ref. 'Huitema96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Levine98' -- Possible downref: Non-RFC (?) normative reference: ref. 'Nonnenmacher97' -- Possible downref: Non-RFC (?) normative reference: ref. 'Pingali94' == Outdated reference: A later version (-07) exists of draft-speakman-pgm-spec-00 ** Downref: Normative reference to an Experimental draft: draft-speakman-pgm-spec (ref. 'PGM') -- Possible downref: Non-RFC (?) normative reference: ref. 'Raman97' -- Possible downref: Non-RFC (?) normative reference: ref. 'Rizzo97' -- Possible downref: Non-RFC (?) normative reference: ref. 'RMTP' -- Possible downref: Non-RFC (?) normative reference: ref. 'RMDP' ** Obsolete normative reference: RFC 1889 (ref. 'Schulzrinne95') (Obsoleted by RFC 3550) -- Possible downref: Non-RFC (?) normative reference: ref. 'TIBnet' -- Possible downref: Non-RFC (?) normative reference: ref. 'Vicisano98' Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Network Working Group 2 INTERNET-DRAFT J. Crowcroft (UCL) 3 Expires 15 Sept, 1998 L. Vicisano (UCL) 4 March, 1998 Z. Wang (Bell Labs) 5 A. Ghosh (UTS) 6 M. Fuchs (U. Karlsruhe) 7 C. Diot (INRIA) 8 T. Turletti (INRIA) 10 RMFP: A Reliable Multicast Framing Protocol 11 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-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 To learn the current status of any Internet-Draft, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 Distribution of this document is unlimited. Please send comments to 32 the authors. 34 1. Introduction 36 There has been considerable interest in reliable multicast, and a 37 number of reliable multicast transport applications and systems have 38 been built in the past years, e.g. [PGM], [RMDP], [RMTP], [SRM]. A 39 survey of most of current reliable multicast protocols is available in 40 [Diot97]. 42 Reliable multicast transport is considerably more complex than 43 reliable unicast. It is generally difficult to build a generic 44 reliable transport protocol for multicast, much as TCP is a generic 45 transport protocol for unicast, since different applications often 46 have very different reliability requirements and modes of operation. 48 In this document we propose a framing protocol for reliable multicast 49 transport - Reliable Multicast Framing Protocol (RMFP). RMFP runs over 50 multicast UDP and itself does not provide any reliability (or 51 functionality in a larger extend). Reliability and other protocol 52 functionalities will be defined in specific profiles. The purpose of 53 RMFP is to provide a common framework upon which a set of reliable 54 multicast systems can be built and share similar functionalities where 55 exist. 57 The philosophy of RMFP is in many respects similar to the one of RTP. 58 However, we believe that using RTP for reliable multicast is not a 59 right approach and will not lead to a clean application design. 61 This draft is intended to stimulate more discussion on the one issue 62 of a generic framing protocol for reliable multicast. 64 2. Design Philosophy 66 This section presents the key mechanisms that have been the foundation 67 for the specification of RMFP. 69 2.1. Error Control 71 Since RMFP is a framework for reliable multicast, the error control is 72 the most important issue. RMFP itself provides no error control 73 functionality, this is the task of the protocol profiles. However, 74 since RMFP follows the ALF principle [Clark90], some of the error 75 control functionalities have to be provided by the application. 77 o RMFP specifies the format of the ADUs. The sequence number field 78 and the FEC and retransmissions flags of the ADU header are 79 primarily provided for the protocol profiles to be used for error 80 control. 82 o Any protocol profile has to be able to detect the loss of ADUs and 83 to initiate the retransmissions. This includes the transmission of 84 control information from a receiver that suffered a loss to some 85 group member that can perform the retransmission. 87 The ALF principle introduces ADUs as common unit of transmission for 88 all layers from the transport protocol up to the application. To 89 enable the unordered delivery of ADUs each ADU has an ADU name 90 assigned that identifies the ADU data in the application context 91 independent of the history of received ADUs. This ADU name is of no 92 meaning to the transport protocol. However, the transport protocol 93 uses its own naming concept to perform loss detection and recovery -- 94 the sequence numbers. 96 The remainder of this section assumes, that only one sender is active 97 in the regarded session. This assumption simplifies the problem in a 98 way, but without limiting generality. If there are several senders in 99 a session, each sender will mark its ADUs with his source ID. Each 100 member of the session has its unique source ID, and all packets can be 101 assigned to their sender. Although the following analysis treats only 102 the case of sessions with a single sender, multiple senders in a 103 session can be regarded as independent from each other, and the 104 discussion corresponds to each sender respectively. 106 2.1.1. The Automatic Repeat Request (ARQ) mechanism 108 The ARQ mechanism is one of the two basic approaches to ensure 109 reliable data transmission, and is the most reliable. The other 110 mechanism, Forward Error Correction (FEC), can only reduce the loss- 111 rate. ARQ consists of two components: the loss detection and the loss 112 recovery. 114 Loss detection: 116 Even if the application does not need any ordering of the data, the 117 protocol will use some kind of sequence numbers to assign an order to 118 its ADU stream. Normally, this order corresponds to the sending 119 order. Losses are detected by means of gaps in the sequence number 120 space. The actual algorithm can reside at the receiver (receiver-based 121 loss detection) or at the sender (sender-based loss detection). The 122 loss detection algorithm uses some state information, the history of 123 ADUs already received successfully, and computes the necessary 124 information to do the loss recovery, i.e. the sequence numbers 125 corresponding to the lost ADUs. 127 o The receiver-based algorithm detects the lost ADUs at the 128 receiving protocol instance, that will encode and transmit the 129 sequence numbers of the lost ADUs in control packets. The encoding 130 is mostly done in form of spans to reduce the necessary bandwidth. 131 The addressee of the control packets (in a unicast transmission 132 this is the sender) can then compute the sequence numbers of the 133 lost packets without other information. 135 o The sender-based algorithm requires that the sender is in charge 136 for the reliability of all the receivers. Consequently, the sender 137 has to keep status information on all of the receivers, see 138 [Levine98]. 140 In the remainder of the report only the receiver-based approach will 141 be considered, since at least for multicast, the sender-based approach 142 has several disadvantages (a comparison of the receiver- and sender- 143 based approach can be found in [Pingali94]): 145 o To detect the gaps, the history of lost and received ADUs has to 146 be available. If the sender has to do this, the number of 147 receivers would be limited by the senders capacity in keeping this 148 state information. 150 o Since the sender has to track the history of all ADUs at all 151 receivers, it has to process the control packets from all 152 receivers. With many receivers, the sender will suffer the so- 153 called ack-implosion. This is an overload of the sender by 154 processing the control packets. Some receiver-based protocols use 155 the so-called NACK suppression mechanism to prevent the overload 156 of control packets. A receiver that suffered a loss, does not need 157 to send a control packet with lost ADU information, if another 158 receiver has done so before for the same ADU. If the 159 retransmission for the first request is transmitted, both 160 receivers will receive it. 162 The following two protocols have been investigated more thoroughly for 163 integration into RMFP as profiles: 165 The SRM [SRM] protocol uses a receiver-based mechanism with NACK 166 suppression to free the senders completely from management tasks for 167 special error control state information and to avoid the ack- 168 implosion. 170 The LGC protocol [Hofmann97] uses a combined approach. To prevent the 171 nack-implosion at the sender, LGC builds a tree structure with the 172 sender as source. The control packets are not sent directly to the 173 sender, but are gathered at the inner nodes (group controllers) of the 174 tree. Thus, the sender and each of the group controllers has only to 175 process the control packets of its children. 177 Loss Recovery: 179 For unicast transmission, the sender of the retransmissions is always 180 the original sender. For multicast transmission, receivers that have 181 successfully received a given PDU can also retransmit that PDU to the 182 receivers that have lost the PDU. An example protocol is SRM, where 183 every group member is involved in loss recovery. 185 2.1.2. Forward Error Control 187 FEC reduces the loss-rate in sending redundancy information 188 additionally to the useful data. The encoding takes a block of n ADUs 189 and computes a given number k of redundancy packets. The n+k packets 190 form a transmission group. If the packets of a transmission group are 191 sent, it is sufficient to receive any subset of size n of the 192 transmission group to reconstruct the original n ADUs. However, if 193 more then k packets of the transmission group get lost, the losses 194 cannot be repaired. Thus, FEC can only reduce the packet loss-rate. An 195 introduction to FEC can be found in [Rizzo97]. 197 FEC can be combined with ARQ to the so-called hybrid ARQ. This 198 mechanism is especially useful for reliable multicast, since it can 199 effectively reduce the overall loss-rate and thus retransmissions, 200 too. An investigation of hybrid ARQ is presented in [Nonnenmacher97]. 202 There are several possibilities to use FEC in RMFP: 204 o The usage of FEC within RMFP transparent for the protocol profile, 205 i.e. as some layer under the profile could improve the behavior of 206 all profiles. The effects of such a transparent FEC mechanism have 207 been investigated in [Huitema96] and [Nonnenmacher97]. 209 o FEC can be implemented as a mechanism of a protocol profile. 211 o The application can implement the FEC mechanism or use some 212 standard module provided by a RMFP implementation, see [Fuchs98]. 214 Sequence numbers are generally ignored when the FEC bit is set. 215 However, specific profiles can use the sequence number field to encode 216 specific protocol information relative to the FEC packet. The 217 transmission of an FEC packet does not increment the sequence number 218 counter at the source. This insulates the mechanism for detecting 219 normal packet loss from the FEC recovery scheme. 221 2.1.3. ALF and loss recovery 223 According to the ALF principle, the application has to handle the data 224 retransmission. In RMFP the protocol profiles have the task to detect 225 the losses and inform the application about the need of 226 retransmissions. The application then provides the retransmission 227 data. However, the protocol profiles use the sequence numbers to 228 identify ADUs, whereas the application requires the ADU name to 229 identify the ADUs. This leads to the need for a mapping between the 230 protocols sequence numbers and the ADU names. 232 The retransmissions of ADUs can only be performed by group members 233 that have the ADU either sent themselves or received already 234 successfully. Since the complete ADU contains both the sequence number 235 and the ADU name, the mapping information required to provide the 236 retransmission data is already available at the retransmitting group 237 member. The member can map the sequence number to the ADU name and 238 then the ADU name to the retransmission data. Depending on the 239 management of the retransmission data, the mapping may also be 240 performed directly from sequence number to retransmission data. 242 The RMFP specification doesn't specify, if the mapping from sequence 243 number to ADU name should be performed already at the protocol profile 244 or at the application; this decision is implementation dependent. 246 2.2. Hierarchical Naming with Objects 248 Additionally to the sequence number field and the ADU name there is 249 another field in the ADU header to support the mechanisms to identify 250 the data carried in the ADUs: The object ID field. It can be used to 251 optimize the transmission overhead caused by the ADU name. 253 For example, a file transfer application can put the name of the file 254 into the ADU name field of each ADU. If the file name includes some 255 path name, the file name can become considerably big. This file name, 256 however, doesn't change for all the ADUs belonging to the file; only 257 the byte-offset field varies from ADU to ADU. 259 The object ID field can reduce the bandwidth required by the ADU name. 260 Each file name used during the transmission is mapped onto a unique 261 object ID. The file name can then be omitted in the ADU name. The 262 problem with this approach is the transmission of the mapping 263 information of object ID to ADU name that is required at the receivers 264 to process the ADUs. It can be transmitted in one of the ADUs of the 265 file in the ADU name field or separately as session information. In 266 the example, the first approach has the disadvantage, that all ADUs of 267 the file can only be processed, when the ADU with the file name in the 268 ADU name field has been received successfully. The other approach has 269 the disadvantage, that the session packet has to be transmitted 270 reliably, since the ADUs of a file are only useful, if the file name 271 is known. 273 How the object ID field is used is up to the application. It has to 274 find the optimal way to suit its requirements and to optimize the used 275 bandwidth. 277 Another issue is the relationship between objects and sequence 278 numbers. Three possibilities are suggested: 280 1/ The object ID is independent to the sequence number field and is 281 only used by the application. The ADUs are sequenced relative to 282 the start of the session and are not influenced by the object ID. 283 This is suitable for applications that require all ADUs to be 284 received reliably. This is the mechanism defined at the 285 specification the SRM profile. 287 2/ The sequence numbers are computed relative to the objects and the 288 object IDs are sequenced. If the objects are transmitted one 289 after the other, i.e. the ADUs of several objects are not 290 interleaved, every two ADUs can be compared in respect to their 291 sending order. 293 To reorder the ADUs and to detect ADU losses at the receiver, the 294 object IDs and sequence numbers are compared hierarchically: 295 Since the objects are transmitted sequentially, the sending order 296 of two ADUs can be computed out of the object ID, if the object 297 IDs of the ADUs differ. If both ADUs belong to the same object, 298 the sequence number decides about the order. The loss detection 299 is more difficult than with the first sequencing approach: 301 - Lost ADUs within an object are detected by gaps in the objects 302 sequence number name-space. 304 - Objects lost in total are detected by gaps in the object ID 305 name-space. 307 - If the first or last ADUs of an object are lost, the start-of- 308 object/end-of-object flags are used to detect the losses. 310 These mechanisms are sufficient to be able to detect all possible 311 ADU losses, although, in the third case, it is not always 312 possible to determine the number of all lost ADUs and their 313 sequence numbers. The coding of negative acknowledgments for 314 retransmission requests must be performed as spans. 316 The problematic loss of ADUs around object boundaries (i.e. the 317 loss of ADUs carrying start-of-object/end-of-object flags) 318 imposes the constraint on the transmission order of objects: The 319 transmission of an object must be completed (by an ADU carrying 320 the end-of-object flag) before the first ADU of the next object 321 (i.e. an object with an object ID incremented by one) can be 322 sent. This limits the usability of this approach for applications 323 that want to transmit several objects simultaneously, e.g. a 324 white-board application. Such applications require the next 325 model. 327 3/ The sequence numbers are computed relative to the objects, i.e. 328 every object has its own sequence number space, but there is no 329 ordering relation between the ADUs of different objects. This 330 requires, however, that all control information has to refer to 331 each object independently, too. In [Fuchs98] a concept is 332 presented that is based on this model of sequencing. It allows 333 the receiver application to decide, which objects have to be 334 received reliably (semantic reliability). Another very general 335 approach of how this can be done is described in [Raman97]. 337 2.3. Late-joining Receivers 339 An important problem for reliable multicast is the synchronization of 340 late-joining receivers. In general, applications may require to allow 341 receivers to join an ongoing session. Such receivers have to figure 342 out, at which point of the ADU stream they start with the receipt of 343 data. 345 The following discussion assumes, that the ADUs are sequenced relative 346 to the session and not relative to the objects (see [Fuchs98]), since 347 this is the method used in the current specification of RMFP. 349 In the rest of the section the term initial sequence number refers to 350 the sequence number of the packet with the lowest sequence number that 351 a receiver processes. A receiver keeps information about the initial 352 sequence number for each sender independently. Similarly, the 353 highest-sequence-number-sent is the highest sequence number used by 354 the sender. For a receiver, this is actually the highest sequence 355 number seen from a given sender so far. 357 Several solutions are possible: 359 o The receiver uses the ADU with the lowest sequence number it 360 receives. It won't ask for retransmissions for any ADU with a 361 lower sequence number. 363 o The senders transmit synchronization points as session 364 information. Those synchronization points are sequence numbers 365 within their ADU stream, that are determined by the application 366 and are useful in the application context. A joining receiver that 367 receives such information, can ask for retransmission of all ADUs 368 starting at this synchronization point. 370 It is up to the application to decide, which style of receiver 371 synchronization to use. Consequently, the RMFP supports both. The 372 senders transmit the information of the style to use and if necessary 373 the current synchronization point within the sender report packets. 375 RMFP defines following behavior at a joining receiver: 377 1/ The receiver has no information yet. This means that the receiver 378 has not yet received any information about the sequence numbers 379 sent by the sender. 381 - ADU received: The sequence number of this ADU is used as an 382 initial sequence number. 384 - Highest-sequence-number-sent received: This information is 385 carried e.g. by a SRM heartbeat control packet. The next 386 sequence number is used as the initial sequence number. 388 - Synchronization point received: The receiver takes the 389 synchronization point as the first sequence number of the ADU 390 stream from the sender. Since the sender report packet carrying 391 the synchronization information also carries the highest- 392 sequence-number-sent, the receiver can ask for retransmission 393 for all ADUs starting with the synchronization point's sequence 394 number and up to the highest-sequence-number-sent. 396 2/ The receiver is synchronized without synchronization point 397 received. The receiver is already synchronized due to a received 398 ADU or highest-sequence-number-sent information. 400 - ADU received: If the ADU's sequence number is lower than the 401 present initial sequence number for that sender, the initial 402 sequence number is set back to the ADU's sequence number and 403 missing packets starting with this sequence number are 404 requested for retransmission. 406 - Highest-sequence-number-sent received: It should be greater 407 than the already known initial sequence number, which has no 408 impact on the synchronization. If it is not, which could happen 409 in case of out-of-order receipt of control packets, this 410 information is discarded. 412 - Synchronization point received: If the synchronization point's 413 sequence number is greater than or equal to the initial 414 sequence number, the information is regarded as obsolete. 415 Otherwise, the initial sequence number is set back to the 416 received sequence number and the missing packets are requested 417 for retransmission. 419 3/ The receiver has already received a synchronization point. This 420 implies, that the synchronization process is already finished. 421 Received synchronization information is not considered anymore at 422 all, and ADUs with lower sequence numbers than the used 423 synchronization point are discarded. 425 Because of the finite sequence number space, there are problems with 426 the described synchronization algorithm. To ensure proper operation 427 the synchronization process has to be stopped after a defined span of 428 sequence numbers has been seen by a receiver (again independently for 429 each sender). In the implementation the size of the span is a quarter 430 of the sequence number space. At this point the receiver assumes that 431 it is fully synchronized. 433 2.4. Automatic Profile Configuration 435 One of the foundations that provide flexibility in RMFP are the 436 different protocol profiles. The protocol profiles have different 437 characteristics and the optimal protocol profile depends on the 438 scenario, i.e. the number of group members, the number of senders etc. 439 If it is clear at the development of an application, that one of the 440 protocol profiles is a good choice for all envisioned scenarios for 441 the application, the application can always use that profile and every 442 group member always knows this profile, when it joins. 444 However, for some applications it might prove useful to support 445 several protocol profiles. The information of the profile has to be 446 distributed to all members. RMFP provides a mechanism for joining 447 members to be configured automatically by received sender control 448 packets. However, this mechanism works correctly only if the senders 449 of a session agree about the profile. RMFP provides no mechanism to 450 deal with conflicts, if members of the same group use different 451 profiles. 453 2.5. External Modules 455 Some of the standard functionality of other transport protocols have 456 been omitted in RMFP to allow the applications to use the transport 457 functionality in a more flexible way. However, many applications could 458 use the standard functionality. To simplify the use of RMFP it is 459 possible to use some implementations of this functionality as external 460 modules. Some possible modules are the following: 462 o Retransmission buffer: According to the ALF principle the 463 application is responsible to manage the retransmission data. This 464 brings flexibility, but many application programmers might want to 465 use the classical mechanism, a simple buffer indexed by the 466 sequence numbers. 468 o Reordering module: ALF explicitly introduces the unordered 469 delivery of received ADUs. Applications, that do not require the 470 flexibility and performance of that mechanism or are not even 471 capable to process the ADUs out-of-order could be implemented 472 simpler, if they could rely on ordered delivery. 474 3. The RMFP Specification 476 RMFP specifies three types of packets: 478 o Data packets (corresponding to ADUs) sent by senders. 480 o Control packets sent by senders and receivers control. 482 o Sessions packets that can be defined by the application using the 483 generic session packet header. 485 The protocol profiles that provide the reliability can define their 486 own control packets. Those profile specifications are not part of the 487 RMFP specification, but are defined separately. Two profile 488 specifications for SRM and LGC can be found in [Fuchs98]. 490 3.1. General Aspects 492 3.1.1. Network environment 494 This specification suggests an addressing scheme for the different 495 packet types: For each of the three packet types -- ADU, control and 496 session -- RMFP uses the same IP multicast address, but different UDP 497 ports. Since all packets can be identified due to their type field, 498 they could be well sent on the same IP multicast address/UDP port. 499 However, such an approach can lead to inefficiencies at the buffer 500 management, since the type of a received packet can only be retrieved 501 after the packet has been copied into the application buffers. That's 502 why RMFP relies on UDP to multiplex/demultiplex the three flows. 504 Some protocol profiles may need to use more addresses and/or ports or 505 cannot even use the global multicast groups in which every group 506 member takes part. However, the profile developers should seek to be 507 as compliant as possible to this suggestion to reduce profile specific 508 differences at the API. 510 This specification requires the application to provide a single 511 address/port pair for the session, the session address and the session 512 port. 514 o The data flow (all the ADUs) is assigned to the session 515 address/session port. 517 o The control flow (sender and receiver report packets as well as 518 the profiles' control packets) is assigned to the session 519 address/session port + 1. 521 o The session flow (all application defined session packets) is 522 assigned to the session address/session port + 2. 524 3.1.2. System environment 526 To avoid problems with alignment, all packet fields are naturally 527 aligned, e.g. all two-octet sized fields are placed on even addresses. 528 The packets themselves are assumed to be four-octet aligned. 530 3.2. RMFP ADU Format 532 The RMFP ADUs have the following header format: 534 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 2 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | V |P|R|F|S|E|X| PAYLOAD TYPE | LENGTH | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | SOURCE ID | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | SEQUENCE NUMBER | OBJECT ID | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 542 | NAME LENGTH | ADU NAME : 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 544 : ADU NAME : 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 The intention in designing this format was to include enough 548 information to be sufficient for the different protocol profiles, but 549 to keep the overhead small. 551 Version(V): 2 bits 552 This field identifies the version of RMFP. 554 Padding(P): 1 bit 555 If the padding bit is set, the packet contains one or more 556 additional padding bytes at the end, which are not part of the 557 payload. The last octet of the padding contains a count of how many 558 bytes should be ignored. The padding bytes keep all the ADUs four- 559 byte aligned. 561 Retransmission (R): 1 bit 562 Set to 1 if the ADU is being retransmitted. 564 Forward Error Correction (F): 1 bit 565 Set to 1 if FEC is used. 567 Start of Object (S): 1 bit 568 Set to 1 if the ADU is the first one of an object. 570 End of Object (E): 1 bit 571 Set to 1 if the ADU is the last one of an object. 573 Exceptional Handling (X): 1 bit 574 This bit is free for use by the application. It is not processed at 576 RMFP or any profile and is intended to allow the application to mark 577 ADUs that should be treated in a unusual way. 579 Payload Type: 8 bits 580 This field is intended to serve the application in a similar way as 581 the payload type field in RTP [Schulzrinne95] does. The application 582 can use this field to indicate the type of the payload. Some values of 583 this field are used to indicate control or session packets used by 584 RMFP and the profiles and may not be used for application purposes. 585 Following values are so far defined: 587 o 201: Sender report packets. 589 o 202: Receiver report packets. 591 o 203: Session packets. 593 o 205: SRM control packets. 595 o 206: LGC control packets. 597 The application can use the other values freely, however, it is 598 possible that other values above 200 may be used by other profiles, or 599 added functionality in future versions of RMFP. 601 Length: 16 bits 602 This field identifies the length of the packet in 32 bits minus one, 603 including the header and any padding. To count in multiples of four 604 bytes avoids an alignment check. This algorithm has been introduced by 605 RTP. 607 It can be used to combine several ADUs into one UDP packet. In a 608 compound UDP packet only the length fields allow the detection of the 609 ADU boundaries. 611 When several ADUs (original and retransmitted) are concatenated within 612 one UDP packet, the original ADUs should all be placed at the 613 beginning of the UDP packet so that receivers that do not encounter 614 losses can just drop the tail of the retransmitted ADUs without 615 processing it. 617 Source ID: 32 bits 618 This field identifies the source. The source IDs are generated 619 randomly similar to the SSRC field in RTP to avoid collisions between 620 several members. 622 Sequence Number: 16 bits 623 The sequence number is an ADU counter. It is incremented by one for 624 each ADU sent. It can be used to detect ADU losses and calculate loss 625 rates. The exact semantics of the sequence number is determined by 626 the protocol profile. It is possible to count the sequence number 627 starting with the first ADU sent and incrementing it for each ADU 628 throughout the session. Another possibility would be to use the 629 sequence number object-relative, i.e. each object has its own counter 630 assigned starting at zero for its first ADU. 632 Object ID: 16 bits 633 This field identifies the object carried in the packet. 635 Name Length: 8 bits 636 This field specifies the length in bytes of the following ADU Name. 637 zero is a valid value, indicating that no explicit ADU name is 638 available. 640 ADU Name: variable length 641 The ADU name is used by the application to identify an ADU in the 642 application context. The contents of this field are completely 643 transparent to RMFP and the protocol profiles. The length of the ADU 644 name can be between 0 and 255 bytes. There can be unused bytes to 645 ensure proper alignment (32bit) within the ADU header. This field can 646 contain the information to identify both the object and the position 647 within the object of the ADU, e.g. the filename and the byte-offset 648 for ADUs in a file transfer application. However, the application can 649 also use the object IDs and sequence numbers to identify objects and 650 ADUs. 652 3.3. RMFP Control Packet Format 654 RMFP control packets include sender report packets and receiver report 655 packets. Those packets can be used by the senders and receivers 656 respectively to transmit session information. 658 3.3.1. Sender Report packet 660 Sender report packets are sent periodically by the sender and contain 661 information about the current sending state. They can help to 662 configure new joining receivers and provide information to detect tail 663 losses. The structure of the header is shown in the following figure: 665 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 2 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | V |P| SR | PAYLOAD TYPE | LENGTH | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | SOURCE ID | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | PROFILE ID | L |S|V| RESERVED | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 673 | BASE OBJECT ID | BASE SEQUENCE NUMBER | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 675 | CURRENT OBJECT ID | HIGHEST SEQUENCE NUMBER | 676 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 677 | PROFILE-SPECIFIC EXTENSIONS | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 Version(V): 2 bits 681 This field identifies the version of RMFP. 683 Padding(P): 1 bit 684 If the padding bit is set, the packet contains one or more 685 additional padding bytes at the end which are not part of the payload. 686 The last octet of the padding contains a count of how many bytes 687 should be ignored. Since the actual header is already aligned, the 688 padding flag is only necessary, if an application specific extension 689 is included in the packet. 691 SR Type: 5 bits 692 This field has no interpretation by RMFP and can be used by the 693 application, e.g. to transmit extra information like an end of 694 transmission indication. It might also be used to denote the type of 695 the application specific extension. 697 Payload Type: 8 bits 698 This field is set to 201 for sender report packets 700 Header Length: 16 bits 701 This field specifies the length of the packet in multiples of 32 702 bits minus one. 704 Source ID: 32 bits 705 This field identifies the sender. 707 Profile: 8 bits 708 This field indicates the type of the protocol profile used. It is 709 used together with the LSV, first object ID and lowest sequence number 710 fields to configure late joining receivers. A receiver that wants to 711 join a session and does not know a-priori which protocol profile is 712 used, can wait for receipt of a sender report packet and configure its 713 protocol profile according to this field. 715 Lowest Sequence Valid (LSV): 2 bits 716 These bits define the interpretation of lowest sequence number 717 field: 719 o 00: The sequence number of the first ADU sent by the sender in 720 this session. 722 o 01: The sequence number of some position in the transmission that 723 can be used to synchronize. 725 o 10: No valid information. The sender provides no special help to 726 synchronize. The new receiver should synchronize its join on the 727 first ADU it receives. 729 o 11: Reserved. 731 If the lowest sequence number fields is valid, a late-joining receiver 732 can ask for retransmission back to the indicated sequence number. The 733 sender can choose the value of this field appropriately to mark some 734 logical boundary in the ADU stream. 736 First Object ID: 16 bits 737 The object ID for late-joining receivers to synchronize. 739 Lowest Sequence Number: 16 bits 740 This field encodes the sequence number for late-joining receivers to 741 synchronize. 743 Current Object ID: 16 bits 744 This field and the highest sequence number field are used to 745 indicate the current state of the sender. The receivers can use this 746 information to detect tail-losses. 748 Highest Sequence Number: 16 bits 749 This field comes together with the current object ID and is the 750 sequence number of the last ADU sent. It is used to detect tail- 751 losses. 753 3.3.2. Receiver Report packet 755 Receiver report packets are sent periodically by the receivers to give 756 feedback on congestion and packet losses. They contain some receive 757 statistics for each sender. The format of this packet type is shown in 758 the following figure. 760 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 2 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | V |P| RC | PAYLOAD TYPE | LENGTH | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | SOURCE ID | 765 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 766 | SENDER'S SOURCE ID 1 | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 768 | FRACTION LOST | RESERVED | HIGHEST SEQUENCE NUMBER | 769 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 770 : : 771 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 772 | SENDER'S SOURCE ID N | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 774 | FRACTION LOST | RESERVED | HIGHEST SEQUENCE NUMBER | 775 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 776 | PROFILE-SPECIFIC EXTENSIONS | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 The fields have the following meaning: 781 Version(V): 2 bits 782 This field identifies the version of RMFP. 784 Padding(P): 1 bit 785 The padding bit is used to force alignment of the packet. It is used 786 in the same way as in the sender report packet. 788 Report Block Count(RC): 5 bits 789 The RC denotes, how many report blocks are contained in this packet. 790 Each report block consists of a sender's source ID, a fraction lost 791 field and a highest sequence number field. 793 Payload Type: 8 bits 794 Set to 202 for receiver report packets. 796 Header Length: 16 bits 797 This field specifies the length of the packet in multiples of 32 799 bits minus one. 801 Source ID: 32 bits 802 Identifies the sender of this packet (a receiver). 804 Senders Source ID X: 32 bits 805 This field identifies the sender X corresponding to the following 806 fraction lost and highest sequence number information. 808 Fraction Lost: 8 bits 809 The fraction of packets lost since last receiver report, expressed 810 as a fixed point number with the binary point at the left edge of the 811 field. Fraction lost is the loss rate seen by the receiver in respect 812 to the sender identified by the previous sender's source ID field. The 813 information may be used for congestion control or error recovery (FEC) 814 by the sender. 816 Highest Sequence Number: 16 bits 817 Indicates the highest sequence number received from the 818 corresponding sender so far. 820 3.4. RMFP Session Packet Format 822 The session packets are used to enable group members to easily 823 exchange session information. RMFP defines a very light-weight 824 approach, that merely supports the sending and receiving of unreliable 825 data, that is marked as session information. Thus the RMFP just 826 defines the protocol header and provides the transmission and receipt 827 of such packets. There are no special packets defined for some 828 specific use, this is up to the application. Session packets can be 829 used e.g. to support the following functions: 831 - - Remote configuration: A sender can transmit configuration 832 parameters to configure other members. This mechanism is only 833 used to transmit parameters. The application has the 834 responsibility to use the parameters to configure the protocol. 836 - - Support at joining a session: A member joining a session has to 837 be informed about the current state of the session. For small 838 groups, it could use a special session packet to issue some 839 status request packet, and the senders can answer to that packet 840 with some status reply session packets. 842 The RMFP session packet has the following format: 844 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 2 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | V |P| FLAGS | PAYLOAD TYPE | LENGTH | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | SOURCE ID | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 Version(V): 2 bits 852 This field identifies the version of RMFP. 854 Padding(P): 1 bit 855 The padding bit is used to force alignment of the packet. It is used 856 in the same way as in the sender report packet. 858 FLAGS: 5 bits 859 The usage of this field is defined by the application. It could be 860 used e.g. to identify different types of session packets. 862 Payload Type: 8 bits 863 This field is set to 203 for RMFP session packets. 865 Length: 16 bits 866 This field specifies the length of the packet in multiples of 32 867 bits minus one, including the header and any padding. 869 Source ID: 32 bits 870 This field identifies the sender of the session packet. It is 871 calculated like the length field of the ADU. 873 Addresses of Authors 875 J. Crowcroft, L. Vicisano 876 {j.crowcroft,l.vicisano}@cs.ucl.ac.uk 877 Department of Computer Science 878 University College London 879 Gower Street 880 London WC1E 6BT 881 UK 883 Zheng Wang 884 zhwang@dnrc.bell-labs.com 885 Bell Labs Lucent Tech. 886 101 Crawfords Corner Road 887 Holmdel NJ 888 USA 890 Atanu Ghosh 891 atanu@socs.uts.EDU.AU 892 School of Computing Sciences 893 University of Technology 894 Sydney 895 PO Box 123 , Broadway 896 NSW 2007 897 Australia 899 Michael Fuchs 900 Michael.Fuchs@telematik.informatik.uni-karlsruhe.de 901 Institute of Telematics 902 University Karlsruhe 903 Germany 905 Christophe Diot, Thierry Turletti 906 {cdiot,turletti}@sophia.inria.fr 907 INRIA Sophia Antipolis 908 2004 route des Lucioles 909 BP 93, 06902 Sophia Antipolis 910 France 911 References 913 [Clark90] 914 D. Clark, D. Tennenhouse, Architectural Considerations for a New 915 Generation of Protocols, Proceedings of ACM SIGCOMM '90, Sept. 916 1990, pp. 201-208. 918 [Diot97] 919 C. Diot, W. Dabbous, and J. Crowcroft, Multipoint Communication: 920 A Survey of Protocols, Functions, and Mechanisms, IEEE/JSAC, Vol. 921 15, No. 3, pp. 277-290, April 1997. 923 [SRM] 924 S. Floyd, V. Jacobson, S. McCanne, C.G. Liu, and L. Zhang, A 925 Reliable Multicast Framework for Light-weight Session and 926 Application Level framing, IEEE/ACM Transactions on Networking, 927 Dec. 1997, Vol. 5, No 6, pp. 784-803. 929 [Fuchs98] 930 M. Fuchs, C. Diot, T. Turletti, and M. Hofmann, A Framework for 931 reliable Multicast in the Internet, INRIA Research report No 932 3363, Feb. 1998. See also the RMFP Home page at URL 933 ``www.inria.fr/rodeo/rmfp/''. 935 [Hofmann97] 936 M. Hofmann, Enabling group communication in global network, 937 Proceedings of Global Networking '97, Calgary, Canada, June 1997. 939 [Huitema96] 940 C. Huitema, The case for packet level FEC, Proceedings of IFIP 941 5th International Workshop on Protocols for High Speed Networks 942 (PfHSN'96)}. INRIA, Sophia Antipolis, France, Oct. 1996. 944 [Levine98] 945 B.N. Levine, and J.J. Garcia-Luna-Aceves, A Comparison of 946 Reliable Multicast Protocols, to appear in ACM Multimedia Systems 947 Journal, August 1998. 949 [Nonnenmacher97] 950 J. Nonnenmacher, E. Biersack, and D. Towsley, Parity-Based Loss 951 recovery for Reliable Multicast Transmission, Proceedings of ACM 952 SIGCOMM '97, Sept. 1997. 954 [Pingali94] 955 S. Pingali, D. Towsley, and J. Kurose. A Comparison of Sender- 956 Initiated and Receiver-Initiated Reliable Multicast Protocols, 957 Proceedings of SIGMETRICS'94, 1994. 959 [PGM] 960 T. Speakman, S. Farinacci, S. Lin, and A. Tweedly, Pretty Good 961 Multicast (PGM) Transport Protocol Specification, Internet Draft, 962 draft-speakman-pgm-spec-00.txt, January 1998. 964 [Raman97] 965 S. Raman, and S.R. McCanne, General Data Naming and scalable 966 State Announcements for Reliable Multicast, Technical report, 967 Computer Science Division (EECS), University of California, June 968 1997. 970 [Rizzo97] 971 L. Rizzo, On the feasibility of software FEC, Technical report, 972 Universita di Pisa, January 1997. 974 [RMTP] 975 J.C. Lin, and S. Paul, RMTP: A Reliable Multicast Transport 976 Protocol, Proceedings of IEEE INFOCOM '96, pp. 1414-1424. 978 [RMDP] 979 L. Rizzo, and L. Vicisano, A Reliable Multicast data Distribution 980 Protocol based on software FEC techniques, Proceedings of the 4th 981 IEEE Workshop on the Architecture and Implementation of High 982 Performance Communication Systems (HPCS'97), Sani Beach, 983 Chalkidiki, Greece June 23-25, 1997. 985 [Schulzrinne95] 986 H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP: A 987 Transport Protocol for Real-Time Applications, RFC 1889, November 988 1995. 990 [TIBnet] 991 TIBCO, TIBNnet White Paper, 992 "http://www.tibco.com/products/tibwhite.html" 994 [Vicisano98] 995 L. Vicisano, l. Rizzo, and J. Crowcroft, TCP-like congestion 996 control for layered multicast data transfer, to appear in 997 Infocom'98. 999 Table of Contents 1001 Status of this Memo ............................................ 1 1002 1 Introduction .................................................. 1 1003 2 Design Philosophy ............................................. 2 1004 2.1 Error Control ............................................... 2 1005 2.1.1 The Automatic Repeat Request (ARQ) mechanism .............. 3 1006 2.1.2 Forward Error Control ..................................... 5 1007 2.1.3 ALF and loss recovery ..................................... 6 1008 2.2 Hierarchical Naming with Objects ............................ 6 1009 2.3 Late-joining Receivers ...................................... 8 1010 2.4 Automatic Profile Configuration ............................. 10 1011 2.5 External Modules ............................................ 11 1012 3 The RMFP Specification ........................................ 11 1013 3.1 General Aspects ............................................. 12 1014 3.1.1 Network environment ....................................... 12 1015 3.1.2 System environment ........................................ 12 1016 3.2 RMFP ADU Format ............................................. 13 1017 3.3 RMFP Control Packet Format .................................. 15 1018 3.3.1 Sender Report packet ...................................... 15 1019 3.3.2 Receiver Report packet .................................... 18 1020 3.4 RMFP Session Packet Format .................................. 19 1021 Addresses of Authors ........................................... 21 1022 References ..................................................... 22