idnits 2.17.1 draft-miller-mftp-spec-03.txt: -(60): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(645): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1299): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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-26) 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. == There are 9 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 58 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 58 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 364 has weird spacing: '...its own resou...' == Line 1093 has weird spacing: '...esponse tran...' == Line 1701 has weird spacing: '...pletion messa...' == Line 1702 has weird spacing: '...pletion messa...' == Line 2079 has weird spacing: '...y Group messa...' == (1 more instance...) -- 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: '1' is defined on line 3042, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 3045, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 3048, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 3052, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1889 (ref. '3') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 1890 (ref. '4') (Obsoleted by RFC 3551) Summary: 9 errors (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT K. Miller, StarBurst 2 Expires in Six Months K. Robertson, StarBurst 3 A. Tweedly, Cisco 4 M. White, StarBurst 5 April, 1998 7 StarBurst Multicast File Transfer Protocol (MFTP) Specification 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- 20 Drafts as reference material or to cite them other than as 21 work in progress. 23 To view the entire list of current Internet-Drafts, please check 24 the "1id-abstracts.txt" listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 26 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 27 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 28 (US West Coast). 30 Abstract 32 The Multicast File Transfer Protocol (MFTP) is a protocol that 33 operates above UDP in the application layer to provide a reliable 34 means for transferring files from a sender to up to thousands 35 (potentially millions with network "aggregators" or relays) of 36 multiple receivers simultaneously over a multicast group in a 37 multicast IP enabled network. The protocol consists of two parts; an 38 administrative protocol to set up and tear down groups and sessions, 39 and a data transfer protocol used to send the actual file reliably and 40 simultaneously to the multiple recipients residing in the group . 42 Intellectual Property Rights 44 StarBurst Communications Corporation("StarBurst")owns U.S. Patents 45 5,553,083 and 5,727,002 which relate to the method for data transfer 46 used in MFTP as described herein. StarBurst will grant a limited 47 royalty-free license under these patents to any party to help 48 facilitate adoption of MFTP by the Internet community, conditioned 49 upon (i) the party executing a written agreement with StarBurst (see 50 below) and (ii) the party�s implementation and operation of MFTP 51 complying fully with MFTP as described herein. 53 Any rights a party may acquire or have as a result of this conditional 54 license offer by StarBurst will terminate immediately on the date any 55 patent is asserted against StarBurst directly or indirectly by the 56 party. 58 A written confirmation of this conditional license with StarBurst, 59 and/or any other license under any of StarBurst�s technology, under 60 StarBurst�s then current terms, conditions, and royalty rates, must be 61 obtained by sending a request to: 63 Edward M. Durkin 64 StarBurst Communications Corporation 65 150 Baker Avenue 66 Concord, MA 01742 68 Table of Contents 70 1. Introduction.....................................................3 71 1.1 Changes from Previous Draft................................5 72 2. Definitions......................................................6 73 3. MFTP Architecture................................................9 74 4. Scaling..........................................................10 75 4.1 Scaling Extensions.........................................11 76 4.1.1 Aggregation of Administrative Back Traffic............11 77 5. Performance......................................................12 78 6. Group Management.................................................13 79 6.1 Joining Clients to Private Groups..........................14 80 6.2 Joining Clients to the Public Group........................15 81 7. Response Address ................................................16 82 8. Response Suppression.............................................17 83 9. Configuration....................................................18 84 9.1 Announce Time Limit........................................18 85 9.2 Fast Announce Option.......................................18 86 9.3 Announce Intervals.........................................18 87 9.4 Status Interval............................................18 88 9.5 Status Retry Timer.........................................19 89 9.6 Status Retry Count.........................................19 90 9.7 Delivery Time Limit........................................19 91 9.8 Completion Interval........................................19 92 9.9 Transmit Rate..............................................19 93 9.10 Register Retry Timer......................................20 94 9.11 Register Retry Count......................................20 95 9.12 Response Back-off Timer...................................20 96 9.13 Response TTL..............................................20 97 9.14 Aggregation Time..........................................20 98 9.15 Aggregation Time per Hop..................................20 99 10. Multicast Control Protocol......................................20 100 10.1 Creating Multicast Groups (Join Group & Group Query)......21 101 10.2 Dissolving Multicast Groups (Leave Group).................22 102 10.3 Determining Group Membership (Echo & Echo Response).......22 103 11. Multicast Data Protocol.........................................22 104 11.1 Product Announcement......................................24 105 11.1.1 Closed Groups.......................................27 106 11.1.2 Open Limited Groups.................................27 107 11.1.3 Open Unlimited Groups...............................27 108 11.2 Product Delivery..........................................28 109 11.2.1 File Delivery - Server..............................28 110 11.2.2 File Delivery - Client..............................31 111 11.3 Product Completion........................................32 112 11.3.1 File Product Completion - Client....................32 113 11.3.2 File Product Completion - Server....................33 114 11.4 Flow Control..............................................35 115 12. Message Formats.................................................35 116 12.1 MCP Messages .............................................39 117 12.1.1 Query Group Message..................................40 118 12.1.2 Join Group Message ..................................41 119 12.1.3 Leave Group Message .................................42 120 12.1.4 Echo Message ........................................42 121 12.1.5 Echo Response Message ...............................43 122 12.2 MDP Messages..............................................43 123 12.2.1 Announce Message.....................................43 124 12.2.2 Registration Message ................................48 125 12.2.3 Data Transfer Message ...............................49 126 12.2.4 Status Request Message...............................50 127 12.2.5 NAK Response Message.................................51 128 12.2.6 ACK Response Message.................................53 129 12.2.7 Done Message.........................................54 130 12.2.8 Completion Message...................................54 131 12.2.9 Abort Message........................................55 132 12.2.10 Quit Message........................................55 133 12.2.11 End Message.........................................55 134 13. Reason Codes....................................................56 135 14. Future Extensions...............................................57 136 15. Security Considerations.........................................57 137 16. Acknowledgments.................................................57 138 References..........................................................57 139 Author's Addresses..................................................58 141 1. Introduction 143 This document provides a description of the StarBurst Multicast File 144 Transfer Protocol. The MFTP protocol is designed to provide 145 efficient, reliable transfer of data organized as files from one 146 sender to multiple receivers. This protocol has been optimized for 147 file delivery, rather than attempting to be a generalized reliable 148 multicast transport layer that can handle both file delivery and 149 streaming data. 150 Real Time Non-Real Time 151 +--------------+--------------+ 152 | | | 153 Multimedia | RTP/RTCP | MFTP | 154 | | | 155 +--------------+--------------+ 156 | Many | | 157 Data only | Proposals | MFTP | 158 | | | 159 +--------------+--------------+ 161 Figure 1-1 Multicast Applications and Protocols 163 Figure 1-1 shows a spectrum of multicast applications and the 164 protocols serving them. StarBurst MFTP is designed to address the 165 non-real time applications depicted in the right half of the diagram. 166 Other reliable multicast protocols attempt to solve the non-real time 167 and data only real time applications with one protocol. 169 This MFTP specialization brings a number of benefits, including: 171 1. Simplicity, which generally means increased reliability 172 2. Virtually no performance change over high delay networks such as 173 satellite 174 3. Ability to be scaleable to thousands of recipients over one hop 175 networks such as satellite with no intermediate relaying 176 entities 177 4. Ability for the sender (Server) to have complete knowledge of 178 the state of receivers (Clients) 180 Additionally, MFTP has flexibility so that optional features can be 181 invoked to increase scalability beyond thousands, including: 183 1. Aggregation and relaying of responses by the network 184 infrastructure or other intermediate entity 185 2. Response suppression to reduce responses from members of a 186 subnet similar to that used by IGMP as specified in RFC 1112 188 Both of these techniques can be used to increase scalability by 189 reducing Client message traffic to the Server. 191 Typical applications for MFTP include electronic software 192 distribution, transmission of critical information to field offices, 193 distribution of multimedia information to local servers, and 194 replication of web servers to the edges of networks for improved 195 performance. A significant new application is the ability to provide 196 subscription based "push" information delivery to receivers who have 197 signed up for a particular information service. 199 MFTP is designed to operate with networks that support multicast and 200 broadcast data transport at the link layer such as LANs and SMDS, and 201 with multicast IP router networks. Multicast user groups can be set 202 up for either type network. When the network is router-based, data is 203 delivered only to hosts in the multicast group based on multicast IP 204 addresses. Each host supports RFC 1112, Host Extensions for IP 205 Multicasting. 207 When the network does not support multicast, data may be broadcast 208 with multicast groups defined at the application layer at each MFTP 209 host. This means that data is broadcast within the network but 210 filtered at the MFTP host so that only members of the defined group 211 receive the data. Data may also be sent in unicast mode to a single 212 receiver. 214 The MFTP Server (data sender) manages the multicast groups, initiates 215 the file transfer, and controls the transfer operation. The MFTP 216 Client (data receiver) joins the multicast group, receives the data 217 sent by the Server, and provides reception status to the Server when 218 requested. 220 MFTP transmission is efficient because data is sent in a streaming 221 mode. This means that the Server continuously sends data without 222 waiting for responses from Clients. Acknowledgment traffic generated 223 by the Clients is minimized because the Clients send responses only 224 for Data Transmission Units (DTUs) that are not received. In addition, 225 the status for a range of DTUs is aggregated in each response, further 226 reducing the response traffic. At the end of a file transmission, the 227 DTUs reported by the Clients as lost or received in error are 228 retransmitted by the Server. 230 MFTP supports file checkpoint/restart so that an interrupted file 231 transfer may be resumed without retransmitting data that has already 232 been received by the Clients. Unlike other protocols that use all 233 available bandwidth to transmit data, MFTP allows a maximum Server 234 transmit rate to be specified. This allows files to be transmitted 235 without stealing bandwidth needed by other applications. 237 MFTP consists of two protocol components - the Multicast Control 238 Protocol (MCP) and the Multicast Data Protocol (MDP). MCP allows the 239 Server to dynamically control the joining and leaving of Clients to 240 multicast groups. MDP then handles the reliable transmission of data 241 products to the Clients that have joined the multicast group. 243 The major features and characteristics of MFTP are summarized below. 245 Reliable data transfer via selective NAK mechanism 246 Uses multicast transmission, as defined in RFC 1112 247 Scaleable to thousands of recipients without intermediate entities 248 Scaleable to millions with intermediate entities to aggregate 249 responses 250 Includes multicast group management and control 251 First level congestion control mechanism defined 252 Minimal performance change on high delay networks such as satellite 253 Additionally supports broadcast and unicast transmission 254 The maximum data rate of each transmission is specified 255 File checkpoint/restart is supported 257 1.1 Changes from Previous Draft 259 This document makes changes from the previous draft in four basic 260 areas. These changes are enhancements and clarifications made to MFTP. 262 The first is a major clarification and discussion of aggregation by 263 network entities, i.e., routers in the network. This was only briefly 264 discussed in the previous draft. 266 The second change is the addition of a global ID to identify members 267 of a group instead of by using their host IP address. This is useful 268 for situations where a host does not have a permanent IP address but 269 may be temporarily assigned one every time the host becomes connected 270 to the network. 272 The third change is ability of group members to filter content 273 delivery based on the source address. This allows group members to 274 select content delivery based on pre-configured allowable sources. 276 The fourth change provides for �host list pruning�. This reduces 277 traffic for confirmation of Registration in Closed and Open Limited 278 Groups and confirmation of completion at the end of a transmission in 279 Closed and Open Limited Groups. 281 2. Definitions 283 This section provides definitions for terms used in this document. 285 Aggregation: The process of collecting responses from Clients and 286 combining them into one response to be relayed back to the Server. 287 This reduces the back traffic to the Server and thus increases the 288 number of Clients that can be served. 290 Announcement: The process of informing Clients that a data transfer is 291 about to start. This involves sending a message to the "well known" 292 multicast group address where Client hosts have joined and are 293 listening for such messages. The message identifies the data product, 294 its size, name, etc. This message is retransmitted at regular 295 intervals for a configured time period (e.g. 3 minutes). After the 296 product announcement phase is completed, the Server begins the 297 transmission of the product (see Product Delivery below). 299 ARS: Application Reference String. This is a variable length, case- 300 sensitive string that the application provides to identify itself. It 301 is used by MFTP to ensure that data is sent and received by like 302 applications. 304 Authorized Client: A term used primarily for Closed Groups where the 305 IP address or the Global ID of each Client that is allowed to receive 306 the data is included in the Announce message. That is, the Client is 307 "authorized" by the applications to receive the data if the Client 308 finds its IP address or Global ID in the Announce message. All other 309 Clients are prohibited from receiving the data. 311 Block: A group of MFTP data messages. Clients report the receive 312 status of data messages a block at a time. 314 Client: The receive function of the MFTP protocol. A single MFTP 315 implementation may contain only a Client function, or it may contain 316 both a Client and Server function (see Server below). Therefore, 317 Client does not necessarily refer to the host itself. 319 Closed Group: A form of group management where the Server specifies 320 the Clients that are allowed to participate in the data transfer. All 321 other Clients are prohibited from receiving the data. Also refer to 322 Open Limited Group and Open Unlimited Group. 324 Data Product: A file that is sent by the Server to Clients. 326 Done Message: A message sent from the Clients to the Server to 327 indicate that the Client has received a complete data product. 329 DTU: Data Transfer Unit. A protocol message which contains the data 330 that is being sent by the Server to the Clients. 332 Global ID: An alternative method for identifying a host that may not 333 have a semi-permanent IP address. The format is that of a Class E IP 334 address, 32 bits long. 336 Host List: The list of hosts that are members of the group. Used in 337 Closed Groups and Open Limited Groups at the Server to track client 338 status and to direct hosts to join a group in Closed Groups. 340 Host List Pruning: A method of pruning the list Client IP addresses or 341 GIDs in a PDU which define a group while still confirming to receivers 342 that their membership is acknowledged or that their Done message is 343 acknowledged. This technique reduces traffic as it reduces the size 344 of the list which needs to be transmitted. 346 Message Implosion: With a large number of Client hosts, all sending 347 messages to the Server, it is possible for the Server to be overrun 348 and messages to be lost. It is important for the protocol to minimize 349 the number of messages that are being directed to any single host. An 350 example of this is the negative-acknowledgment scheme that is used to 351 obtain a Client's reception status and the way that the status for a 352 range of DTUs is grouped together into a single response message. 354 MFTP: Multicast File Transfer Protocol. The protocol described in this 355 document. 357 MTU: Maximum Transmission Unit. The largest unit of data, in bytes, 358 that can be transmitted over the user's physical network. 360 Open Limited Group: A form of group management where the Server does 361 not specify which Clients may participate in the data transfer. Any 362 Client that wishes to receive the data is required to register with 363 the Server. The Server may limit the number of participants based on 364 its own resources or some other criteria. Also refer to Closed Group 365 and Open Unlimited Group. 367 Open Unlimited Group: A form of group management where the Server does 368 not specify which Clients may participate in the data transfer. 369 Clients that wish to receive the data are not required to register 370 with the Server. Also refer to Closed Group and Open Limited Group. 372 Pass: For a file transmission, MFTP makes one "pass" through the file 373 to transmit the file data. It then makes another "pass" through the 374 file to retransmit data that was not received during the first pass. 375 Additional passes may also be made to deliver the product successfully 376 to all receiving hosts. 378 Private Address: The network address to which a Server transmits the 379 data product. The Server specifies the Private Address in the Announce 380 message for each product transfer. The private address is most 381 relevant in multicast transmission because separate multicast 382 addresses may be used for product announcement and delivery. Only 383 Clients that are authorized to receive a product actually join the 384 multicast group defined by the private address. 386 Product Delivery: The process of transmitting the data product from a 387 Server to Clients. The data is transmitted in messages called Data 388 Transfer Units (DTUs). A group of DTUs is called a block. The 389 transmission of the entire data product once is called the first pass. 390 No DTU retransmissions occur during the first pass. Rather, additional 391 passes are made when retransmissions are required. However, only the 392 missed DTUs are retransmitted on each subsequent pass. This phase is 393 always preceded by the Product Announcement phase (see Announcement 394 above). 396 Public Address: The network address to which a Server transmits a 397 product announcement. The public address is most relevant in multicast 398 transmission because separate multicast addresses may be used for 399 product announcement and delivery. Any number of Servers may announce 400 products to a single public address and any number of Clients may join 401 the multicast group defined by the public address. 403 Registration: The process of a Client informing a Server that the 404 Client intends to participate in the product transmission that is 405 currently being announced. The Client does this by sending a 406 Registration response message to the Server. This response is sent to 407 the address specified by the "Response Address" parameter in the 408 Announce message. 410 Relay: An entity that forwards messages to another destination after 411 receiving them. For example, an aggregator also acts as a relay by 412 combining Client responses and then forwarding them to the Server or 413 another aggregator. Relays can also be Clients that in turn act as 414 Servers for another group that cannot be reached directly by the 415 Server or for efficiency. 417 Response Address: An IP address (unicast or multicast) to which 418 Clients send Registration, Status, and Done messages. The Response 419 Address is specified in the Announce message. The ability to specify 420 an address other than the Server's address allows an intermediate 421 entity to perform aggregation/relaying of the responses. 423 Server: The transmit function of the MFTP protocol. A single MFTP 424 implementation may contain only a Server function, or it may contain 425 both a Server and Client function (see Client above). Therefore, 426 Server does not necessarily refer to the host itself. 428 Transmission ID: A number that uniquely identifies an individual data 429 product transmission that originates from a single Server. The 430 concatenation of the Server's IP address and the Transmission ID 431 uniquely identifies any MFTP transmission in the network. The 432 Transmission ID is included in every MDP message sent by the Server 433 and Client. 435 3. MFTP Architecture 437 MFTP operates above the User Datagram Protocol (UDP) layer of the 438 TCP/IP protocol suite. As such, it uses the UDP Sockets interface. 440 MFTP defines both a send function (the Server) and a receive function 441 (the Client). The Server only transmits data products and the Client 442 only receives data products. An implementation may optionally include 443 both functions, as shown in Figure 3-1 or may only have one. The 444 checksum, defined in UDP, is the usual mechanism to determine if a 445 datagram is corrupted. Some implementations may not include a UDP 446 checksum; in these cases, an optional checksum is provided by MFTP. 448 +-+-+-+-+ +-+-+-+-+ 449 | File | | File | 450 +-+-+-+-+ +-+-+-+-+ 451 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 452 +-+-+-+->| Server | Client |+-+-+-+-> 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | ^ 455 V | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | UDP Layer | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | IP Layer | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 Figure 3.1 MFTP Data Architecture 464 File products can be transmitted directly from the file system by the 465 Server and written directly to the file system by the Client. All 466 implementations are required to support the MFTP Echo message and Echo 467 Response message, which provide functions similar to "ping". 469 Transmission Modes 471 Messages sent by the Server may be sent in either unicast, broadcast, 472 or multicast mode. The Client must be able to receive Server messages 473 in any of these modes. This allows flexibility in designing the Server 474 to achieve network optimization goals. For example, unicast may be 475 used to send an Abort message to a single Client when that is the only 476 Client that is being aborted. All other Clients are spared from having 477 to receive the message on the multicast group. An entire product 478 transfer can occur in unicast mode when there is only a single Client 479 receiver. 481 Broadcast mode may be used when the network does not support IP 482 multicast. All Clients receive the messages, but messages that are not 483 directed to the Client are filtered and discarded. This mode should 484 normally be avoided because of its impact on the network. 486 The remainder of this document generally assumes multicast 487 transmission, unless otherwise stated. 489 IANA Assigned UDP Port 491 IANA has assigned UDP port 5402 for MFTP. Certain MFTP messages must 492 be sent to this port because it will be the only port number known 493 both to the sender (Server) and the receivers (Clients). This includes 494 the MCP messages, the Announce message, the Data messages, the 495 Completion message, the Abort message and the End message. 497 An MFTP station may include both the Server and Client function, both 498 using the port 5402. To reduce the traffic on port 5402, a Server may 499 dynamically allocate a source "session" port to send a data product 500 and to receive responses from the Clients. The Announce message is 501 sent to the Client's port 5402. Client responses are returned to 502 the source session port number. The Client may also allocate a session 503 port to send messages, rather than using port 5402. 505 The Server sends all messages to the Client's port 5402. The 506 specified session port is in effect only for the current product 507 delivery. This use of session ports is illustrated in Figure 3-2. 509 +-+-+-+-+-+ +-+-+-+-+-+ 510 | | | | 511 | +-+-+-+-+-+-+-+-+ Announce, data+-+-+-+-+-+-+-+-+ | 512 | | port 5402 | /+-+-+-+-+-+->| port 5402 | | 513 | +-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+ | 514 | Server | / | Client | 515 | | / | | 516 | +-+-+-+-+-+-+-+-+/ Client Resp. +-+-+-+-+-+-+-+-+ | 517 | | session port |<-+-+-+-+-+-+-+-+-| session port | | 518 | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | 519 | | | | 520 +-+-+-+-+-+ +-+-+-+-+-+ 522 Figure 3-2 Session Ports 524 4. Scaling 526 By focusing on file based delivery rather than attempting to be a 527 generalized reliable multicast transport layer, improvements in 528 scaling without requiring intermediate aggregation points are 529 achieved. It is known that the limitation for scaling in reliable 530 multicast protocols is the �NAK Implosion� problem, where the 531 administrative (NAK) back traffic from receiver (Client) to sender 532 (Server) eventually overwhelms the sender as the number of receivers 533 grows. The use of �blocks� in MFTP combines NAKs from each 534 recipient so that one NAK with a bit map of the DTUs in the block can 535 represent thousands of bad or dropped DTUs, depending on the actual 536 number of bad or dropped DTUs in the block. 538 Although not required, MFTP recommends that the block size be tied to 539 the MTU size so that the bit map in one NAK packet exactly fits the 540 number of DTUs in a block. For example, if the MTU is 1500 bytes at 541 the MAC layer (the maximum for Ethernet), the block size consists of 542 over 11 thousand DTUs. Thus, a burst of thousands of dropped DTUs 543 within a block results in only one NAK rather than thousands (see 544 Section 11.2.1). 546 Even when the MTU at the IP layer is 576 bytes, the maximum guaranteed 547 in TCP/IP networks with no fragmentation, the block size is over 3800 548 DTUs which still provides a high level of minimization of NAK traffic. 550 Experiments have been performed by StarBurst to emulate up to 10,000 551 Client receivers in one Closed group transmission and no significant 552 performance degradation was observed. Obviously, scaling behavior 553 will be affected by percent error rate and/or packet loss rate in the 554 network, with the better the network characteristic the better the 555 scaling. With MFTP, the Open Unlimited group model has scaling 556 performance totally dependent on NAK traffic; however, for Closed and 557 Open Limited group models, all Client receivers Register and all 558 Client receivers send Done messages, the latter acting as one ACK for 559 the entire file. Thus, in these models, all receivers send one 560 message at the beginning and at the ending of the transmission. This 561 traffic in fact becomes the scaling limitation in the Closed and Open 562 Limited group models. 564 Products using MFTP in essentially the same form as described in this 565 document have been operating in private networks since mid 1995. At 566 the time of this writing, several installations are operating in a 567 production environment with over 3000 simultaneous receivers and one 568 installation is operating with over 8000 receivers in a group growing 569 to about 9000 in early 1998. 571 4.1 Scaling Extensions 573 In addition to the minimization of administrative back traffic 574 described above, provision is made in MFTP to extend scaling to 575 hundreds of thousands and perhaps millions of simultaneous receivers 576 depending on the network characteristics by using network aggregation 577 entities to further consolidate administrative back traffic. 578 Additionally, provision is made for NAK suppression on subnets, 579 similar to the method used by IGMP as specified in RFC 1112. 581 4.1.1 Aggregation of Administrative Back Traffic 583 Three different types of administrative traffic may be aggregated by 584 network entities; NAKs, and (in Closed and Open Limited group models) 585 Registrations and Dones. 587 Figure 4-1 shows a network where the back traffic is suppressed and 588 aggregated. 590 +--------+ /---\ 591 |Subnet 1|--|DR1|--------\ 592 +--------+ \---/ \/---\ 593 |RTR|-- -- -- -- -- -> To Source 594 +--------+ /---\ /\---/ 595 |Subnet 2|--|DR2|--------/ 596 +--------+ \---/ 598 Figure 4-1 599 Subnet Suppression and Aggregation by Routers 601 DR1 is the Designated Router (DR) for subnet 1 and DR2 is the 602 Designated Router for subnet 2. The DR for each subnet provides the 603 multicast routing interface for hosts on that subnet. Hosts send 604 Registrations, NAKs, and Dones back to the source using a response 605 multicast group address to which all data group members and the data 606 source join. This administrative traffic is sent after a random 607 backoff time, with the maximum time separately configurable for NAKs, 608 Registrations and Dones. These are defaulted to half the value of the 609 status interval time, i.e., half the time to send a block for NAKs, 610 half the Announce Interval for Registrations, and half the Completion 611 Interval for Dones. Suppression is accomplished in similar manner as 612 IGMP, reducing subnet traffic to the DR. The DR for the subnet 613 collects all of the responses, and aggregates them into one response 614 for transmission upstream to the source. Each packet is sent to the 615 response group address to which aggregating routers are also members 616 but which also includes the original source address. Aggregating 617 routers use this information to forward the response multicast group 618 traffic only toward the source, rather than back to the other members 619 of the group. Intermediate routers similarly suppress and aggregate 620 downstream responses from multiple respondents to provide a 621 consolidated message back to the source. 623 Multicast routers learn the response group address by reading Announce 624 packets on the Announce address and join the response group. An MD5 625 hash function is used to assist the router in determining if two NAK 626 packets received should be aggregated or suppressed. 628 To do suppression and aggregation, delay is introduced. To keep this 629 delay from compounding linearly by hop, the packets that may be 630 aggregated are aged as they progress through the network. A maximum 631 end to end aggregation time for all hops and the aggregation time 632 allowed per hop are both parameters. Each hop calculates the time 633 remaining and adds this parameter to the aggregated packet. If the 634 time remaining becomes zero, the next hop simply forwards it to the 635 source without any further suppression or aggregation. These 636 parameters are discussed in more detail in section 12. 638 5. Performance 640 MFTP is a rate based protocol with a transmission rate defined by the 641 sender (Server). By design, it does not attempt to provide error 642 correction in real time but takes advantage of the non-real time 643 nature of file transmission. Thus, transmission remains continuous at 644 the set transmission rate through the total transmission of the file 645 in the first �pass�, with corrections (sent at the same rate) made in 646 subsequent passes. This makes MFTP very insensitive to delay such as 647 occurs over satellite networks and also makes it tolerant of 648 asymmetric data channels. 650 Performance is affected as the number of simultaneous receivers grows, 651 as this increases the number of bad or dropped packets in aggregate 652 for the group resulting in more retransmissions. However, in practice 653 there is often high correlation in bad/dropped packets among 654 receivers. For example, all receivers downstream from a congested 655 node will experience the same packet drops caused by that node. Since 656 the retransmissions are sent to the same multicast group, they will 657 all get the same correction simultaneously on a subsequent pass. 659 Protocol overhead is modest, both in header size and in the amount of 660 processing needed. Thus, MFTP can be expected to be able to exceed 661 the performance of FTP even in a point to point application. 663 6. Group Management 665 MFTP uses the push method for distributing data products. That is, at 666 a time determined by the Server user application, a data product 667 transmission is "announced" to the Client population. This 668 announcement consists of transmitting Announce messages for a 669 period of time, followed by the data product itself. The Announce 670 message identifies the data product that will be transmitted, its 671 size, and other parameters documented herein. 673 MFTP uses two separate multicast groups, called the public group and 674 the private group. The Server announces products on its public group 675 address and Clients join the address to receive announcements. The 676 product data is transmitted on the private group address. That is, the 677 public group address is where any Client may join and listen for 678 announcements made by any Server that is sending to the public 679 address. However, only Clients that are authorized by the application 680 to receive a particular transmission actually join the private 681 address. 683 The public/private group architecture is shown in Figure 6-1. Clients 684 1 - 3 are joined to and listening on the public group. Only Client 3 685 wants to receive the product that has been announced and has joined 686 the private group to receive it. 688 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+ 689 | Server |+-+-+-+-+-+->| Public Group |+-+-+-+-+-+->|Client1| 690 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+\ +-+-+-+-+ 691 | \ \ 692 | \ \ 693 | \ \ +-+-+-+-+ 694 | \ \+-+-+-+>|Client2| 695 | \ +-+-+-+-+ 696 | \ 697 | +-+-+-+-+-+-+-+-+ \+-+-+->+-+-+-+-+ 698 +-+-+-+-+-+-+-+-+-+-+>| Private Group |+-+-+-+-+-+->|Client3| 699 +-+-+-+-+-+-+-+-+ +-+-+-+-+ 701 Figure 6-1 Group Architecture 703 Group management deals with how Clients learn about and are joined 704 to the public and private groups. The attributes of the public group 705 are discussed first, with the assumption that Clients are already 706 joined to it. Once a Client is joined to the public group, it learns 707 about the private group in the Announce message. Finally, the method 708 used to join Clients to the public group is discussed. 710 6.1 Joining Clients to the Private Group 712 Use of the public group is completely flexible in that there may be 713 one for each Server or multiple Servers may transmit product 714 announcements to a single group address. It is recommended that the 715 number of public groups be kept to a minimum, even one. This allows 716 the use of a single public group for Clients to listen for 717 announcements from many Servers without requiring a separate multicast 718 group for each one. 720 In order to direct the product data to only those Clients that 721 actually want to receive it, the product announcement message includes 722 a field that specifies a separate private multicast address. The 723 Clients then dynamically join the private address and the Server 724 transmits the product data on that address. Note that while joined to 725 the private group the Client continues to be a member of and listens 726 for product announcements on the public address. This allows the 727 Client to receive multiple data products simultaneously, if it so 728 desires. 730 Normally, the Clients leave the private address at the end of the 731 product transfer and continue to listen for product announcements 732 on the public address. However, if the Server is going to transmit 733 multiple data products, it may set an option in the product 734 announcement that directs the Clients to not leave the private 735 address. This reduces the overhead associated with joining and leaving 736 multicast groups. By also announcing the next product transmission 737 on the public group, Clients that did not hear or did not participate 738 in the previous transfer may be added to the private group. 740 If the Server is supplied with more than one private address, it may 741 arbitrarily use any one of the addresses to transmit a data product. 743 Multiple addresses would typically be used to send multiple products 744 to different groups at the same time by a single Server. 746 MFTP includes a unique transmission identifier in each message so that 747 the Client can always distinguish messages that are associated with an 748 individual data transmission. 750 6.2 Joining Clients to the Public Group 752 To discuss how Clients are joined to the public address, there are two 753 models that are considered, Closed and Open. 755 In the Closed model, the Server knows in advance which Clients 756 are authorized to receive a data transmission, and the number of 757 Clients is relatively small (e.g. thousands of Clients). This allows 758 the Server to tightly control group membership. 760 The public address may be known and configured in advance at the 761 Clients or the Server may use the MFTP Multicast Control Protocol to 762 direct Clients to join the public group. This type of group 763 management is called Closed Groups since the Server restricts the 764 membership of the group. This control occurs at two levels - (1) 765 either by configuration or by use of MCP, the members of the group 766 are restricted and (2) the product announcement itself includes a list 767 of Clients that are authorized to participate. 769 Upon receiving the Announce message, the Clients designated to join 770 the group register with the Server by sending a Registration message, 771 unless there is some legitimate reason not to, e.g., there is not 772 enough disk space to store the transmission or the client has been 773 configured to reject content from that source. In these cases, the 774 Client sends back a Registration message with a �Decline� code. 776 All other Clients are administratively told not to join the group and 777 thus do not receive the transmission. This is a Server-centric mode of 778 operation that allows the Server to tightly control which Clients 779 receive the data and also minimizes the number of Registration 780 messages arriving at the Server. It also allows the Server to keep 781 detailed statistics on each Client. This mode is most useful when the 782 data product has a value associated with it that prevents it from 783 being freely distributed. 785 In the Open models, the receiving Clients are not known to the Server. 786 This means that the Server is not able to configure the multicast 787 groups via MCP. A Client must be able to obtain the public group 788 address of Servers that it is interested in, perhaps by using the MCP 789 Group Query message or by using one of the external protocols defined 790 in the mmusic working group. 792 Since the MFTP server is not determining those Clients that join its 793 session, this type of group management is called "Open Group". 794 There are two variations of Open Groups, called "Limited" and 795 "Unlimited", as discussed below. 797 The Limited mode allows the Server to announce a transmission without 798 specifying the Clients that are authorized to receive the data. This 799 may be because the Server does not know in advance which Clients may 800 want to receive the data, or the number of potential Clients may be 801 very large. 803 This type of group allows any Client to request participation in the 804 data delivery, but the Server limits the number of actual participants 805 based on some criteria determined by the application. As Clients 806 register to receive the data, the Server learns the identity of each 807 Client. Therefore, like the Closed Group, the Server is able to keep 808 detailed statistics on each Client that has joined the group. In fact, 809 after the Announce/Registration phase, protocol operation is identical 810 to the Closed Group. This mode is most useful when it is permissible 811 to freely distribute the product, but the sender wants to know who is 812 receiving it. 814 The Unlimited mode allows any Client to participate in the data 815 delivery and the Server does not limit the number of participants. To 816 achieve this, certain types of Client responses are waived to prevent 817 message implosion at the Server. This includes the Registration and 818 Done messages. The only Client response that is retained is the Status 819 Response message. Since Clients send this message only for DTUs that 820 are not received, there will not necessarily be a response from every 821 Client. The Server is unable to identify each receiving Client when 822 this mode is used, so it is most useful when the data product can be 823 freely distributed and the sender does not care to know who is 824 receiving the product. 826 7. Response Address 828 The Server specifies the response address parameters in the Announce 829 message. Each Client then sends all response messages to the specified 830 response address (regardless of whether the Server message is received 831 in unicast or multicast mode). 833 A different response address than the Server may be used by an 834 aggregating entity in the network to collect responses from clients 835 and reduce implosion traffic to the Server. This increases the 836 scalability, i.e., the number of clients supported. The use of a 837 multicast response address with a suitable TTL may be used for 838 aggregation and is required for response suppression (see Section 6). 839 The response parameters include the following: 841 Response IP Address (may be different than Server's IP address) 842 Response port number (may be different than Server's port number) 843 Server IP address 844 Server port number 846 The Response IP Address may be either a unicast or multicast address. 847 The normal mode is that the Response IP Address and port number be 848 that of the Server if optional aggregation and/or suppression is not 849 used. 851 The Server IP address and port number are echoed in the Client's 852 response. This is the address and port where the response must 853 eventually be sent by an intermediate relay point, if present. 855 8. Response Suppression 857 Response message suppression is an optional Client function that 858 eliminates the sending of redundant status messages from a single 859 subnet, such as a LAN. That is, congestion that occurs upstream from 860 the subnet will produce an identical set of dropped messages at each 861 Client on the subnet. The result is all Clients send identical status 862 responses to a Status Request message. This can be avoided by having 863 the Clients listen to each other's response and suppress duplicate 864 responses. 866 Response message suppression is used only with the sending of the NAK 867 Response message. Other Client responses are sent in the normal manner 868 described in this document. 870 The NAK Response message is sent to the multicast Response Address 871 as specified in the Announce message. Each Client must be joined to 872 this address in order to hear the response of other Clients on the 873 subnet. 875 When a Status Request message is received by the Client, and the 876 request causes a NAK response message to be built, the Client does not 877 immediately send the message. Rather, a delay timer is started. Each 878 Client's delay timer is a different, randomly-chosen value between 0 879 and n seconds, where n is configurable with a default value of 1 880 second. The Client hashes the host IP address to compute its delay 881 timer to reduce the chance of multiple Clients generating the same 882 delay. 884 While waiting for its own delay timer to expire, each Client receives 885 and examines the status responses sent by other Clients. If the pass 886 number, block number, and event hash fields all match the Client's 887 unsent message, the Client's unsent message is discarded and the delay 888 timer is canceled. Otherwise, the Client continues to listen to and 889 examine additional responses. If no matching message is received 890 before the Client's delay timer expires, the Client transmits its own 891 response message. Any response messages received after the Client's 892 message has been transmitted are ignored. If a new Status Request 893 message is received from the Server while the delay timer is running, 894 the Client immediately sends its current response message, cancels the 895 timer, and processes the new Status Request as described above. 897 The response suppression function is applied at the subnet level. 898 Since all Clients participating in a product transfer will join to the 899 multicast Response Address, messages that leave a subnet will also 900 arrive at all other Clients joined to the group and will be processed 901 as described above. When message aggregation is performed by the 902 network infrastructure (see Message Aggregation above), the network 903 can prevent responses from being propagated anywhere except back to 904 the Server. 906 9. Configuration 908 The following configuration parameters affect the operation of the 909 protocol: 911 Announce Time Limit 912 Fast Announce Option 913 Announce Interval 914 Status Interval 915 Status Retry Timer 916 Status Retry Count 917 Delivery Time Limit 918 Completion Interval 919 Transmit Rate 920 Register Retry Timer 921 Register Retry Count 922 Response Back-off Timer 923 Response TTL 924 Aggregation Time 925 Aggregation Time per Hop 927 Some parameters may apply only to product transmission, only to 928 product reception, or to both. The application of each parameter is 929 noted in the following descriptions. Also refer to the description of 930 the protocol and message formats below for additional information. 932 9.1 Announce Time Limit 934 This parameter sets the maximum time, in seconds, that MFTP will 935 use for the announce phase of a product transmission. The announce 936 phase will last for this duration unless the Fast Announce Option (see 937 below) is used. 939 9.2 Fast Announce Option 941 This parameter only applies to Closed Groups. The Server may shorten 942 the duration of the Announcement immediately after all members of the 943 group register. This is the normal mode of operation in the Closed 944 Group model. 946 9.3 Announce Intervals 948 This parameter sets the interval, in seconds, between successive 949 transmissions of the Announce message during the product announce 950 phase. 952 9.4 Status Interval 954 This parameter specifies the interval, in seconds, between Status 955 Request messages sent by the Server to the Clients. It is used to 956 establish the transmit block size. A default block size will be 957 computed, based on the MTU. This block size will maximize the amount 958 of NAK information that can be sent in a single status response 959 message by the Client. The Server sends the status request message at 960 the end of each transmitted block. However, for a large MTU (and 961 therefore a corresponding large block size), a relatively long time 962 may elapse before there is any status information that can be returned 963 to the application about the NAK status of individual Clients. The 964 application may set the Status Interval parameter to the time interval 965 that it wants the Server to request NAK status from the Clients. The 966 block size is adjusted for the requested interval so that a block of 967 DTUs is sent in the interval and then NAK status is requested by the 968 Server. 970 9.5 Status Retry Timer 972 This parameter specifies the time duration, in seconds, that the 973 Server will wait for Client responses after a Status Request message 974 is sent. 976 This timer is not used for Status Request messages sent during a pass 977 because the Server does not stop and wait for responses. However, at 978 the end of the pass, the Server cannot begin the next pass if no 979 responses (status response or Done message) have been received for 980 the current pass. In this case, the Server sends a Status Request 981 message, starts the Status Retry timer, and waits for any responses. 982 When the timer expires, the Server begins the next pass if any status 983 response messages were received. If there is no response, the Server 984 sends another Status Request message and restarts the retry timer. 985 When there are no responses, this procedure continues up to the 986 retry limit set by the Status Retry Count (see below) or until the 987 Delivery Time Limit is reached, whichever occurs first. 989 9.6 Status Retry Count 991 This parameter specifies the maximum number of times that the 992 Server will retransmit a Status Request message when no response is 993 received from any Client. Refer to Status Retry Timer above to see 994 how it is used. 996 9.7 Delivery Time Limit 998 This parameter sets the maximum time for the product delivery phase of 999 a file transmission. The parameter is an integer that represents a 1000 percentage, with a minimum value of 10% (i.e. value =1.10). MFTP 1001 multiplies the integer by the optimal time that it takes to make one 1002 pass through the transmit file. The result is the maximum time devoted 1003 to the product delivery phase, in seconds. 1005 9.8 Completion Interval 1007 This parameter sets the interval, in seconds, between successive 1008 transmissions of the Completion message during the product 1009 Completion phase. 1011 9.9 Transmit Rate 1013 This parameter specifies the bit rate at which a data product will be 1014 transmitted by the Server. The transmit rate may fall below this 1015 value due to other processing demands on the Server, but the rate 1016 shall never exceed the configured value. The transmit rate applies to 1017 all bits sent by the Server in a DTU, including all protocol headers. 1018 The algorithm to be used to control the transmit rate is unspecified. 1020 9.10 Register Retry Timer 1022 This parameter specifies the frequency, in seconds, that the Client 1023 will resend a Registration message once data transfer phase begins. 1024 During the Announce phase, the Registration message is resent every 1025 time that an Announce message is received that does not confirm the 1026 previous Registration transmission. Hence, the stimulus for 1027 Registration retransmission is the received Announce message and the 1028 rate of retransmission is identical to that of the Announce message 1029 (see Announce Interval parameter above). 1031 9.11 Register Retry Count 1033 This parameter specifies the maximum number of times that the 1034 Client will retransmit a Registration message during the data 1035 delivery phase in order to solicit a confirmation from the Server. 1036 Refer to Register Retry Timer above to see how it is used. 1038 9.12 Response Back-off Timer 1040 This parameter specifies the maximum length of the back-off timer when 1041 suppression is invoked. It is also used to spread out responses so 1042 when there is no aggregation so that the server receives a spread out 1043 load of administrative traffic. 1045 9.13 Response TTL 1047 This parameter specifies the TTL of the response message from the 1048 client. It should normally be set to the maximum for the network. 1050 9.14 Aggregation Time 1052 This parameter is only used when aggregation in the network is 1053 performed. It is the maximum amount of time that is allowed to 1054 aggregate return traffic that is aggregatable, i.e., Registrations, 1055 ACK/NAKs, and Dones. 1057 9.15 Aggregation Time per Hop 1059 This parameter is used to determine how long a network element is 1060 allowed to wait to accumulate return traffic which it will then 1061 aggregate for transmission upstream to the source. This is also only 1062 used when aggregation is invoked. 1064 10. Multicast Control Protocol 1066 This section describes the Multicast Control Protocol (MCP). 1067 Configuration parameters and message formats are described in 1068 separate sections. 1070 The purpose of MCP is to allow a Server to control the dynamic 1071 joining and leaving of remote hosts to multicast groups. MCP defines 1072 the following message types: 1074 Join Group transmitted by the Server to dynamically join Clients 1075 to multicast groups. This message is normally unicast 1076 to an individual Client, but may be multicast to an 1077 existing multicast group. 1079 Group Query transmitted by the Client to query a Server for its 1080 current public multicast group address. This message 1081 is unicast to the Server. 1083 Leave Group transmitted by the Server to dynamically cause Clients 1084 to leave a multicast group. This message may be 1085 unicast to an individual Client or multicast to an 1086 existing multicast group. 1088 Echo transmitted by any MFTP station to determine if a 1089 remote host is reachable and running MFTP. This 1090 message may be unicast to an individual host, or 1091 multicast to an existing multicast group. 1093 Echo Response transmitted as a response to a received Echo message. 1094 This message is unicast to the originating host. 1096 MCP provides for creating multicast groups, dissolving multicast 1097 groups, and determining group membership. Each of these is 1098 discussed below. Also refer to the Message Format section for 1099 additional information. 1101 The Echo message may be sent by either a Server or Client. It is also 1102 useful for network testing, for example, determine if hosts are 1103 reachable, or to calculate response times. 1105 10.1 Creating Multicast Groups (Join Group and Group Query) 1107 Multicast group formation may be initiated by both the Server and 1108 the Client. If a Client knows the IP address of a Server, but not its 1109 public address where it is announcing product transmissions, it may 1110 send the Group Query message to the Server. The Server then sends 1111 a Join Group message to the Client to get it to join the Server's 1112 public multicast address. 1114 The Join Group message may be sent by a Server at any time to 1115 dynamically direct one or more Clients to join a specified multicast 1116 group. If the Client(s) are not already a member of a multicast group, 1117 the message is sent in unicast or broadcast mode. Otherwise, the 1118 message may be sent to an existing multicast group to direct Clients 1119 joined to that group to join an additional group. 1121 The Join Group message identifies the application type that is sending 1122 the message and the type of data that will be sent by the application. 1123 If the Client has an application layer user of the same type that 1124 wants to receive the indicated data products from this Server, it 1125 joins the multicast group. 1127 There is no response to the Join Group message. However, the Echo 1128 message (see below) may be used to determine which Clients have 1129 successfully joined the group. Since the Echo message can be sent to 1130 the new group address, only those Clients that have actually joined 1131 the new group will respond to the Echo message. 1133 10.2 Dissolving Multicast Groups (Leave Group) 1135 The Leave Group message is used to direct one or more Clients to 1136 leave a specified multicast group. The message may be sent to the 1137 existing multicast group to direct its members to leave the group, or 1138 the message may be sent in unicast or broadcast modes. 1140 There is no response to the Leave Group message. However, the Echo 1141 message (see below) may be used to determine which Clients have 1142 successfully left the group. If the Echo message is sent to the group 1143 address, there should be no response from those Clients that have 1144 left the group. 1146 10.3 Determining Group Membership (Echo and Echo Response) 1148 The Echo message may be sent at any time to determine which 1149 Clients have joined a multicast group. The receiving host responds 1150 with the Echo Response message. The response is sent if MFTP is 1151 running on the target host, without regard to whether there are any 1152 application layer users of MFTP. When users do exist, the receipt of 1153 the Echo message and the transmission of the Echo Response in no 1154 way affects those users. 1156 The Echo message may be multicast, broadcast, or unicast. If the 1157 message is unicast, then the receiving host always responds to the 1158 message. If the message is multicast or broadcast, it may contain a 1159 list of the hosts that should respond to the message. In this case, 1160 the receiving host responds only if it is specified in the host list. 1161 If there is no host list, the receiving host always responds. 1163 11. Multicast Data Protocol 1165 This section describes the Multicast Data Protocol (MDP). 1166 Configuration parameters and message formats are described in separate 1167 sections. 1169 The purpose of MDP is to transfer the product data from the Server 1170 to the Clients in a reliable and efficient manner. MDP defines the 1171 following message types: 1173 Announce transmitted by the Server to announce an 1174 impending product transfer. This message is 1175 sent to the Public multicast address. 1177 Registration transmitted by the Client as a response to 1178 the Announce message. This message is sent 1179 to the "Response IP Address" that is 1180 specified in the Announce message for the 1181 Closed and Open Limited group models. 1183 Data Transfer Unit(DTU) transmitted by the Server to deliver a data 1184 product. There is no explicit response to 1185 this message. This message is sent to the 1186 Private multicast address. 1188 Status Request transmitted by the Server to solicit status 1189 from Clients. This message is sent to the 1190 Private multicast address. 1192 Status Response/ACK transmitted by the Client in response to a 1193 Status Request message to acknowledge 1195 correct reception of a block of data 1196 messages. Normally, the Server requests 1197 only the NAK form of the status response to 1198 minimize responses from Clients. This 1199 message is sent to the Response IP Address. 1201 Status Response/NAK transmitted by the Client in response to a 1202 Status Request message to request the 1203 retransmission of data messages within a 1204 block. This is the normal response type 1205 requested by the Server and is the message 1206 that the generic term "status response" 1207 refers to in the following protocol 1208 discussion, unless otherwise noted. This 1209 message is sent to the Response IP Address 1210 (see Definition, Section 2). 1212 Done transmitted by the Client when it has 1213 received all of a product transfer 1214 successfully. This message is sent to the 1215 Response IP Address. 1217 Completion transmitted by the Server to confirm receipt 1218 of a Done message from one or more Clients. 1219 This message is sent to the Private 1220 multicast address. 1222 Abort transmitted by the Server to indicate that 1223 one or more Clients should quit 1224 participating in the current product 1225 transfer, or to indicate the premature 1226 termination of the current product transfer 1227 to all Clients. There is no response. This 1228 message is sent to the Private multicast 1229 address. 1231 Quit sent by the Client to indicate it is no 1232 longer participating in the current product 1233 transfer. There is no response. This message 1234 is sent to the Response IP Address. 1236 End sent by the Server four times to indicate to 1237 the Response Group when aggregation is 1238 invoked that the session is over. 1240 MDP consists of three general phases - Product Announcement, 1241 Product Delivery, and Product Completion. Each of these is discussed 1242 below. Also refer to the Configuration and Message Format sections 1243 for additional information. 1245 11.1 Product Announcement 1247 Product Announcement is the process of letting the Client population 1248 know that a product is about to be transmitted. The Server transmits 1250 the Announce message for this purpose. If multicast is being used, the 1251 message is sent to the Public address. Otherwise, the message is sent 1252 in unicast or broadcast mode. The message identifies the product name, 1253 type, and other information about the transfer, including whether it 1254 is Closed, Open Limited or Open Unlimited (see Group Management 1255 above). 1257 The Announce message is sent periodically during the Announce phase. 1258 The transmission interval is specified by the Announce Interval 1259 parameter, and the duration of the Announce phase is specified by the 1260 Announce Time Limit parameter. 1262 The Announce phase serves several purposes. First, it helps to ensure 1263 that the message is actually received by the Clients since it is 1264 transmitted more than once. Second, subsequent transmissions of the 1265 message serve to confirm receipt of Registration messages received 1266 from Clients by the setting of a flag per client in the message. 1267 Third, the announce duration allows Clients that are experiencing 1268 problems (e.g. insufficient disk space) to resolve those problems and 1269 still register for the product transfer. 1271 When the first Announce message is sent, the Server starts the 1272 Announce Time Limit timer and the Announce Interval timer. When the 1273 interval timer expires, the Server resends the message unless one of 1274 the following conditions is true: 1276 1. The Group type is Closed and all Clients in the Host List (see 1277 below) have registered. Actually, this behavior can be modified 1278 with the Fast Announce Option (see Configuration section). Note 1279 that after the last Client registers, there must be at least one 1280 additional transmission of the Announce message to confirm the 1281 registration. Also, the Server may introduce a delay to ensure that 1282 the last Client has actually joined the Private address before the 1283 data transfer phase is started. In any case, data missed by such 1284 Clients is recovered by subsequent data transmissions of the 1285 Server. No delay is currently specified by this protocol. 1287 2. The Announce type is Open Limited and the maximum number of Clients 1288 that can be handled have registered. 1290 3. The Announce Time Limit timer has expired. If no Clients have 1291 registered when this timer expires, then the product transmission 1292 is canceled. 1294 The Announce message may contain a Host List. It is included for a 1295 Closed Group in order to identify those Clients that are directed to 1296 participate in the product transfer. As Client Registration messages 1297 are received, a flag is set in subsequent transmissions of the 1298 Announce message to confirm receipt of the Registration for each 1299 Client and the Host List is �pruned� of hosts that have already had 1300 confirmation sent to them. The Host List is not initially included in 1301 the Announce message for an Open Limited group. However, it is 1302 included in subsequent messages to confirm those Clients that have 1303 registered. The Host List is never included in the Announce message 1304 for an Open Unlimited group. 1306 Clients specified in a Closed group announcement respond with a 1307 Registration message whether they are going to participate in the 1308 transfer or not. If the Client is not going to participate, a reason 1309 is provided in the message. This allows the Server to track problems 1310 in the group. 1312 A Server may receive more than one response from a Client during the 1313 same product announcement. The last response received should be 1314 considered the Client's "official" response. For example, the Client 1315 may initially decline the transfer due to insufficient disk space. The 1316 announce duration may allow the Client operator time to resolve the 1317 problem. If the Client operator frees up disk space, the Client may 1318 then respond that it will be participating in the transfer. 1320 The Server may receive a Quit message from the Client after the Client 1321 has registered. After receipt of the sent message, the Server should 1322 not consider the Client a participant in the product transfer. 1324 The logic flow diagram below illustrates the Server's product 1325 announcement phase. "Registration fulfilled?" refers to whether all 1326 Clients in a Closed group have registered, or whether the maximum 1327 number of Clients in an Open Limited group have registered (it does 1328 not apply at all to an Open Unlimited group). "Update confirmations" 1329 refers to the setting of the registration-confirmed flag in the 1330 Announce message to confirm Client registrations. This step also would 1331 not apply to Open Unlimited groups. 1333 When a Client receives an Announce message, it examines the product 1334 information contained in the message and compares it with the 1335 requirements set by its application layer user(s). That is, it is 1336 expected that the application layer will designate the Servers that it 1337 is interested in receiving from and the types of data products that it 1338 wants to receive. The application may also select only particular 1339 sources to receive product from and reject those not selected. Based 1340 on this information, the Client decides whether or not to receive the 1341 announced product. 1342 +-+-+-+-+-+-+-+-+ 1343 | Idle |<---------------------------+ 1344 User request to +-+-+-+-+-+-+-+-+ | 1345 transmit prod. --------------->V | 1346 +-+-+-+-+-+-+-+-+ | 1347 | Start | | 1348 |duration timer | | 1349 +-+-+-+-+-+-+-+-+ | 1350 V | 1351 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | 1352 | Send |<------| Update | | 1353 | Announce | | confirmations | | 1354 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | 1355 V ^ | 1356 +-+-+-+-+-+-+-+-+ | | 1357 | Start | | | 1358 |interval timer | | | 1359 +-+-+-+-+-+-+-+-+ | | 1360 V | | 1361 +-+-+-+-+-+-+-+-+ | | 1362 Yes | Registration |<-----+ | | 1363 +---------| fulfilled? | | | | 1364 | +-+-+-+-+-+-+-+-+ | | | 1365 | V No | | | 1366 | +-+-+-+-+-+-+-+-+ | | | 1367 | Yes | Duration timer| | | | 1368 | +----| expired? | | | | 1369 | | +-+-+-+-+-+-+-+-+ | | | 1370 | | V No | | | 1371 | | +-+-+-+-+-+-+-+-+ | | | 1372 | | |Interval timer | No | | | 1373 | | | expired? |+-----+ | | 1374 | | +-+-+-+-+-+-+-+-+ | | 1375 | | | Yes | | 1376 | | +-----------------------+ | 1377 | | +-+-+-+-+-+-+-+-+ | 1378 | | | Anyone | No | 1379 | +--->| register? |+---------------------------+ 1380 | +-+-+-+-+-+-+-+-+ 1381 | V Yes 1382 | +-+-+-+-+-+-+-+-+ 1383 | | Send | 1384 +-------->|final Announce | 1385 +-+-+-+-+-+-+-+-+ 1386 V 1387 +-+-+-+-+-+-+-+-+ 1388 | Start data | 1389 | delivery | 1390 +-+-+-+-+-+-+-+-+ 1392 Figure 11-1 1393 Server Product Announcement Phase 1395 If the Announcement is for Open Limited or Open Unlimited Groups and 1396 the Client does not want to receive the product, then the Client sends 1397 no response and discards the message. If the Announcement is for 1398 Closed Groups and the Client does not want to, or is not able to 1399 receive the product, then it still must send a Registration message 1400 stating the reason it is declining the transfer. 1402 If a Client wants to participate in a transfer, its action is 1403 described separately for each group management type below. Note that 1404 joining and leaving the multicast group in the discussion below refers 1405 to IGMP operations and not MCP. 1407 11.1.1 Closed Groups 1409 If the Client's IP address or GID is not contained in the Host List of 1410 the Announce message, the Client sends no message and is 1411 administratively prohibited from participating in the transfer. 1412 Otherwise, it joins the data delivery multicast address (i.e. Private 1413 address) contained in the Announce message and sends a Registration 1414 message to the Response Address, unless the Client is configured to 1415 not receive content from that Server or there is a lack of resource 1416 that does not allow the Client to receive content. 1418 The Client's registration must be confirmed by the Server before it is 1419 allowed to receive the data product. The confirmation is indicated by 1420 a flag set in a subsequent Announce message, as discussed above. If 1421 the confirmation is received, the Client waits for and receives the 1422 product data. If confirmation is not received in the next Announce, 1423 the Client resends its Registration message. 1425 If the announce duration (specified in Announce message, see Messages 1426 below), expires or the Client begins to receive product data before 1427 confirmation is received, it implies that the Server did not receive 1428 the Registration message before the start of the data delivery phase. 1429 The Client discards the received data and resends its Registration 1430 message at the Register Retry Timer interval. The number of times that 1431 the Client resends its Registration message is limited by the Register 1432 Retry Count. If no confirmation is received before the retry limit is 1433 reached, the Client returns to idle state and makes no further 1434 attempts to register for the current product transfer. Note that the 1435 Client also returns to idle state if a Completion or Abort message is 1436 received while the Client is still trying to register with the Server. 1438 11.1.2 Open Limited Groups 1440 The Client joins the data delivery address contained in the Announce 1441 message and sends a Registration message to the Response Address. 1442 Subsequent operation is identical to Closed Groups in that the Client 1443 must receive confirmation of its registration before it is allowed to 1444 receive the product data. 1446 11.1.3 Open Unlimited Groups 1448 The Client joins the data delivery address contained in the Announce 1449 message but sends no Registration message to the Server. The Client 1450 receives the data as sent by the Server on the data delivery address. 1452 A Client may receive an Abort message from the Server at any time 1453 during the product registration. The Client returns to idle state and 1454 is not allowed to participate in the current product transfer. When 1455 returning to idle state, the Client normally leaves the data delivery 1456 group. 1458 However, the Client would remain a member of the group if: 1460 1. The Server specified in the Announce message that Clients 1461 should not leave the data delivery group (see Announce 1462 message below). 1464 2. Other transmissions being received by this Client are using 1465 the same data delivery group address. 1467 3. The private address is the same as the public address. 1469 11.2 Product Delivery 1471 The Product Delivery phase occurs after the Product Announcement 1472 phase. The file product is transmitted by the Server to the Clients. 1474 11.2.1 File Delivery - Server 1476 DTUs are transmitted to the private multicast address. The Server 1477 logically divides the file into one or more parts, called blocks. Each 1478 block is further divided into the data size that can be transmitted in 1479 a single DTU. All blocks and DTUs are a fixed size, except the last 1481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1482 | File | 1483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1484 | | 1485 | | 1486 | | 1487 +-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+ 1488 | Block 1 | Block 2 | --- | Block n | 1489 +-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+ 1490 / \ 1491 / \ 1492 / \ 1493 / \ 1494 / \ 1495 / \ 1496 / \ 1497 +-+-+-+-+-+-+ +-+-+-+ 1498 |DTU1 |DTU2 | --- |DTUn | 1499 +-+-+-+-+-+-+ +-+-+-+ 1501 Figure 11-2 1502 Organization of Transmitted Data 1504 DTU which may be shorter. The manner in which the block size is 1505 determined is discussed further below. This data organization is 1506 illustrated in Figure 11-2. 1508 The Server transmits the file data in "passes". That is, the entire 1509 file is sent initially (i.e. pass 1). If any DTU retransmissions are 1510 required, the Server then makes another pass (i.e. pass 2) through the 1511 file, but sends only those DTUs that were reported as missed by the 1512 Clients. Additional passes may be required to successfully deliver all 1513 DTUs to all Clients. 1515 The pass, block, and DTU number of each file fragment is indicated in 1516 the DTU header (see Message Formats below). The block and DTU number 1517 assignment is static for a given MTU size such that the retransmission 1518 of any file fragment will indicate the same block and DTU number. This 1519 allows the receiver to properly insert each fragment into the file 1520 regardless of when the fragment is received. 1522 The Server uses the Status Request message to query the Clients for 1523 their receive status. The Clients send a Status Response message if 1524 they need to request the retransmission of any DTUs. Otherwise, a 1525 Client sends no Status Response to the request. Although Client status 1526 may be requested by the Server at any time, it is normally requested 1527 at the end of each block transmission. The response message contains a 1528 bit map where each bit represents the receive status of an individual 1529 DTU within the block. Hence, the status of an entire block is 1530 contained within a single response message. 1532 The Server does not stop at the end of each block and wait for a 1533 response to the Status Request message nor does it immediately resend 1534 requested DTUs. Rather, the Server simply receives and processes the 1535 responses in order to schedule which DTUs need to be resent on the 1536 next pass. This makes the protocol insensitive (unless the data 1537 product sent is very short) to network delay that can be excessive in 1538 some networks, e.g. satellite. Note that the Status Request message 1539 may be sent at any time rather than at block boundaries, if 1540 information is desired about transmissions before the end of the 1541 block. 1543 After the last block of a pass has been transmitted, the Server sends 1544 a Status Request message for that block and immediately starts the 1545 next pass if there are DTUs that need to be resent. However, if no 1546 responses have been received for any previous block in the file, the 1547 Server stops and waits for responses. The length of time that the 1548 Server waits for a response is specified by the Status Delay parameter 1549 (see Configuration above). Note that the Status Request message may 1550 specify that status is requested for a single block or for a range of 1551 blocks. When the Server sends the Status Request message because no 1552 responses have been received, it specifies all blocks in the file. If 1553 a Client has not responded because it missed a previous individual 1554 block message, this ensures that such responses are solicited. 1556 Each Status Request message specifies the current transmit pass number 1557 and the block for which status is being requested. These values are 1558 echoed by the Client in its response. The Server uses the following 1559 rules for processing Client responses. 1561 1.If the response pass number is equal to the current transmit 1562 pass number, accept the response and schedule the requested 1563 DTUs for retransmission. 1565 2.If the response pass number is not equal to the current 1566 transmit pass number, examine the block number and proceed as 1567 follows: 1569 a. If the response block number is greater than the 1570 current transmit block number, accept the response and 1571 schedule the requested DTUs for retransmission. 1573 b. Else, schedule for retransmission only those DTUs that 1574 have not already been retransmitted on this pass. 1576 The block size is a function of the Status Interval and Transmit Rate 1577 parameters. That is, the application layer user specifies the 1578 frequency at which receive status should be obtained from the Clients. 1579 The Server computes how many DTUs it can send at the Transmit Rate in 1580 the Status Interval and establishes that as the block size. The block 1581 size is computed with the following formula: 1583 block size = Status Interval x (Transmit Rate/(8 x (MTU - protocol 1584 headers))) 1586 There is an upper limit to the block size that the application may set 1587 per Transmit Rate, as determined by the maximum DTU bit map size that 1588 the MTU will allow. 1590 The default block size (used when application does not specify a 1591 Status Interval) maximizes the amount of status information that can 1592 be returned in a single message according to the MTU size. 1594 Retransmissions may continue until all Clients have received the 1595 entire file or until the Delivery Time Limit duration has expired or 1596 until the Status Retry Limit has been exceeded. If the timer expires, 1597 the Server sends an Abort message and terminates the product delivery 1598 unless it is an Open Unlimited group, at which time a Completion 1599 message is sent. It is required to send several Abort messages to 1600 ensure that the Client receives at least one message since there is no 1601 confirmation message from the Client. 1603 The logic flow diagram in Figure 11-3 illustrates the Server's Product 1604 Delivery phase. The completion processing is explained in a following 1605 section. 1607 If a file is being restarted by the Server, the Server must first 1608 determine what part of the file has not yet been received by the 1609 Clients. There are many possible ways this can be done and no specific 1610 way is specified by the protocol. For example, the Server may locally 1611 store the state at the end of an aborted transfer and restore it for a 1612 file restart. Alternatively, the Server may want to query one or more 1613 Clients to determine what parts of the file still need to be 1614 transmitted. Once this initial restart state is determined, subsequent 1615 Server operation is identical to any retransmission pass (i.e. the 1616 Server sends only those DTUs necessary to complete the file transfer). 1617 File restart is allowed for Closed and Open Limited groups, but not 1618 for Open Unlimited groups. 1620 11.2.2 File Delivery - Client 1622 As DTUs are received by the Client, the Client must examine the block 1623 and DTU number in order to store the data in its proper place in the 1625 from Announce +-+-+-+-+-+ 1626 phase | Idle | 1627 | +-+-+-+-+-+ 1628 | ^ 1629 V | 1630 +-+-+-+-+-+-+-+ +-+-+-+-+-+ 1631 +--->|Xmit duration| Yes | Send | 1632 | | expired? |----->| Abort | 1633 | +-+-+-+-+-+-+-+ +-+-+-+-+-+ 1634 | |No 1635 | V 1636 | +-+-+-+-+-+-+-+ 1637 | | Send | 1638 | | DTU | 1639 | +-+-+-+-+-+-+-+ 1640 | | 1641 | V 1642 | +-+-+-+-+-+-+-+ 1643 |No | End of | 1644 |<---| block? | 1645 | +-+-+-+-+-+-+-+ 1646 | | Yes 1647 | V 1648 | +-+-+-+-+-+-+-+ 1649 | | Send Status | 1650 | | Request | 1651 | +-+-+-+-+-+-+-+ 1652 | | 1653 | V 1654 | +-+-+-+-+-+-+-+ 1655 |No | End of | 1656 |<---| pass? | 1657 | +-+-+-+-+-+-+-+ 1658 | | Yes 1659 | V 1660 | +-+-+-+-+-+-+-+ 1661 |Yes | Retrans. |No Completion 1662 +<---| required? |----> processing 1663 +-+-+-+-+-+-+-+ 1665 Figure 11-3 Server Product Delivery 1667 file. As discussed above, a bit map of each block is maintained that 1668 indicates whether a DTU has yet been received. If a duplicate DTU is 1669 received, it is discarded. 1671 When a Status Request message is received from the Server, the Client 1672 immediately responds with a Status Response message for the indicated 1673 block. File delivery continues until all DTUs in the file have been 1674 received or until the receive timer expires. The receive timer value 1675 is specified by the Server in the Announce message. If the timer 1677 expires, the Client sends a Quit message and returns to idle state. It 1678 is required to send several Quit messages to ensure that the Server 1679 receives at least one message since there is no confirmation message 1680 from the Server. 1682 The logic flow diagram in Figure 11-3 illustrates the Client's receive 1683 data processing. The completion processing is explained in a following 1684 section. 1686 11.3 Product Completion 1688 Product Completion is the process of terminating a product transfer. 1689 File product completion for the Client is discussed first, since it is 1690 the Client that normally initiates the completion procedure. 1692 11.3.1 File Product Completion - Client 1694 As each DTU is received, the Client determines if it has now received 1695 the entire file. If not, data reception continues. Otherwise, for 1696 Closed and Open Limited groups, the Client sends a Done message to the 1697 Server. For Open groups, the Client simply returns to idle state 1698 without sending any message to the Server. 1700 After sending a Done message, the Client waits for receipt of a 1701 Completion message from the Server. Like the Announce message, the 1702 Completion message contains a Host List that specifies each Client 1704 for which a Done message has been received (i.e. it confirms receipt 1705 of the Done message). 1707 If the Client receives a Completion message and it's address is in the 1708 Host List, then the transfer is complete, the Client leaves the data 1709 delivery group (subject to conditions, as discussed above) and returns 1710 to idle state. Otherwise, the Done message is resent. The Done message 1711 is also resent for each Status Request message received from the 1712 Server (a Status Response is not sent). This procedure continues until 1713 the Client's Done message is confirmed or until the receive timer 1714 expires. 1716 The logic flow diagram below illustrates the Client's completion 1717 processing as it applies to a Closed or Open Limited group. 1719 from Announce +-+-+-+-+-+ 1720 phase | Idle | 1721 | +-+-+-+-+-+ 1722 | ^ 1723 V | 1724 +-+-+-+-+-+-+-+ +-+-+-+-+-+ 1725 +--->|Receive timer| Yes | Send | 1726 | | expired? |----->| Quit | 1727 | +-+-+-+-+-+-+-+ +-+-+-+-+-+ 1728 | |No 1729 | V 1730 | +-+-+-+-+-+-+-+ 1731 | | Receive | 1732 | | DTU | 1733 | +-+-+-+-+-+-+-+ 1734 | | 1735 | V 1736 | +-+-+-+-+-+-+-+ 1737 |No | Received | 1738 |<---| Status Req.?| 1739 | +-+-+-+-+-+-+-+ 1740 | | Yes 1741 | V 1742 | +-+-+-+-+-+-+-+ 1743 | | Send Status | 1744 | | Response | 1745 | +-+-+-+-+-+-+-+ 1746 | | 1747 | V 1748 | +-+-+-+-+-+-+-+ 1749 |Yes | Retrans. |No Completion 1750 +<---| required? |----> processing 1751 +-+-+-+-+-+-+-+ 1753 Figure 11-4. Client Product Reception 1755 11.3.2 File Product Completion - Server 1757 For Closed and Open Limited groups, the receipt of a Done message from 1758 a Client means that the Client has received all of the file 1759 successfully. The Server confirms the receipt of Done messages with 1760 the Completion message. However, a separate message is not sent for 1761 each Done received. Rather, the Host List is used to "batch-confirm" 1762 all Done messages that have been received up to the time that the 1763 Completion message is sent. 1765 The first Completion message is sent as soon as the first Done message 1766 is received, and periodically thereafter at intervals specified by the 1767 Completion Interval parameter. When a Completion message is sent, the 1768 interval timer is started. When the timer expires, the Server updates 1769 the Host List of the message with all Clients that have sent Done 1770 messages and sends the message again. If all Clients have not yet 1771 completed, the timer is restarted. There must be at least one 1772 from Delivery 1773 phase 1774 | 1775 V 1776 +-+-+-+-+-+-+-+ 1777 +--->| Send | 1778 | | Done msg. | 1779 | +-+-+-+-+-+-+-+ 1780 | | 1781 | V 1782 | +-+-+-+-+-+-+-+ +-+-+-+-+-+ 1783 | | Done | Yes | Idle | 1784 +-------->| confirmed? |----->| | 1785 | | +-+-+-+-+-+-+-+ +-+-+-+-+-+ 1786 | | |No ^ 1787 | | V | 1788 | | +-+-+-+-+-+-+-+ | 1789 | |Yes | Status Req. | | 1790 | +<---| received? | | 1791 | +-+-+-+-+-+-+-+ | 1792 | |No | 1793 | V | 1794 | +-+-+-+-+-+-+-+ +-+-+-+-+-+ 1795 | No |Receive timer| Yes | Send | 1796 +<--------| expired? |----->| Quit | 1797 +-+-+-+-+-+-+-+ +-+-+-+-+-+ 1799 Figure 11-5 Client Product Completion 1801 additional transmission of the Completion message after the last 1802 Client has completed. 1804 Since Clients will experience different network error rates, some 1805 Clients may complete the transfer while other Clients are still 1806 receiving retransmissions. This means that the Completion message may 1807 be sent while the file transfer is still in progress. 1809 Data delivery continues until there are no longer any participating 1810 Clients (all Clients have sent Done or Quit messages), there is no 1811 response from any Client, or until the Delivery Time Limit duration 1812 has expired, whichever occurs first. 1814 When the last Client completion has been confirmed with the Completion 1815 message, the Server considers the transfer complete and sends no 1816 further messages. 1818 If the Server receives no response to a Status Request sent at the end 1819 of a pass, there may no longer be any Clients listening to the Server. 1820 The Status Delay and Status Retry Count parameters limit the length of 1821 time that the Server will attempt to receive a response. When the 1822 Status Request message is sent, the Server starts the Status Delay 1823 timer. If any status responses have been received by the time the 1824 delay timer expires, the Server begins the next pass where it 1825 retransmits the DTUs specified in the responses. If no responses are 1826 received, the Server sends another Status Request message and restarts 1827 the delay timer. This procedure repeats up to the limit set by the 1828 Status Retry Count parameter, or the delivery time limit expires, 1829 whichever occurs first. At that time, the Server sends an Abort 1830 message, terminates the product delivery, and sends four End 1831 messages over the Public Address. End messages are read by 1832 aggregation devices, if present, to determine that the session is 1833 over. 1835 The Server may also use the Abort message to terminate transfer to one 1836 or more Clients at any time due to conditions at the Server or at the 1837 Client. Several Abort messages are sent to insure delivery as no 1838 response to the Abort message is required from the Clients. 1840 For Open Unlimited groups, the Clients do not send Done messages. The 1841 Server simply continues to send retransmissions as long as there are 1842 responses to the Status Request message. When there are no responses, 1843 the Server continues to send Status Request messages up to the Status 1844 Retry Limit (as discussed above) or the Delivery Time Limit expires. 1845 At that time, the Server sends a Completion message (with no Host 1847 List) and considers the transfer complete. There is no response from 1848 the Clients. 1850 For all group types, when the session is over the Server sends an End 1851 message on the same multicast address used for Announce. This message 1852 is sent four times and is used to conveniently notify infrastructure 1853 that may be aggregating that the session is ended. The End message 1854 structure is described in Section 12. 1856 11.4 Flow Control 1858 A first level of flow control may optionally be invoked to make sure 1859 particular parts of the network multicast tree do not become 1860 overloaded and bad receivers do not hold up transmission to the other 1861 members of the group. 1863 The Announce message may optionally contain an error rate threshold 1864 (Note that this should probably be mandatory when MFTP is used in 1865 large heterogeneous networks such as the Internet). This threshold is 1866 used to inform clients that if they measure a DTU loss over the 1867 threshold they abort themselves from the group. By leaving the group, 1868 that leaf of the multicast tree is dissolved, removing congestion in 1869 that part of the network. The Server may then be directed by the 1870 application to set up a new group of aborted clients and create a new 1871 session at a later time at a lower transmission rate to service those 1872 clients. 1874 12. Message Formats 1876 This section defines the format of all MFTP protocol messages. All 1877 messages begin with a common protocol header that is 12 bytes in 1878 length and includes the message type. Additional information, 1879 depending on message type, is included in the message payload area. 1880 The format of the common header is shown in Figure 12-1 below. 1882 0 32 1883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1884 | Protocol version | Message type | 1885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Common 1886 | Message length | Checksum | 1887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header 1888 | Transmission Identifier | 1889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1890 | Optional Parameters and Data | 1891 | |Payload 1892 ~ ~ Area 1893 | | 1894 | | 1895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1897 Figure 12-1 Protocol Header Format 1899 Each header field is an unsigned integer. The fields are described 1900 below. 1902 Protocol Version Number 1904 This field contains an integer that identifies the MFTP protocol 1905 version that is implemented by the sender of this message. This 1906 document describes version 1. 1908 Message Type 1910 This field identifies the MFTP message type, as defined in the 1911 following table. 1913 QUERY GROUP 0x0001 1914 JOIN GROUP 0x0002 1915 LEAVE GROUP 0x0003 1916 ANNOUNCE 0x0004 1917 DATA TRANSFER 0x0005 1918 STATUS REQUEST 0x0006 1919 NAK RESPONSE 0x0007 1920 COMPLETION 0x0008 1921 ABORT 0x0009 1922 REGISTRATION 0x000A 1923 DONE 0x000B 1924 QUIT 0x000C 1925 ECHO 0x000D 1926 ECHO RESPONSE 0x000E 1927 ACK RESPONSE 0x000F 1928 END 0x0015 1930 Message Length 1932 This field contains the length, in bytes, of the entire MFTP message, 1933 beginning with the Protocol Version field. 1935 Checksum 1937 This field contains a checksum that verifies the integrity of the 1938 entire message including the MFTP header. A checksum is computed by 1939 the sender of each message and placed into this field. The receiver 1940 also computes the checksum and compares it with the received value. If 1941 the values do not match, the received message is discarded and treated 1942 as if it were never received. 1944 The checksum is the 16 bit one's complement of the one's complement 1945 sum of all 16 bit words in the header and payload area. While 1946 computing the checksum, the checksum field itself is replaced with 1947 zeros. 1949 The use of this field is optional as the UDP checksum provided within 1950 UDP should be used for this function. If the UDP checksum is used, 1951 this field should be set to zero. 1953 Transmission Identifier 1955 This field contains a number that uniquely identifies this 1956 transmission. A receiver uniquely identifies messages associated with 1957 this transmission by examining the source IP address and this 1958 transmission identifier. The transmission identifier is not 1959 applicable in MCP and is set to zero in MCP messages. 1961 Payload 1963 The information contained in the payload section of each message is 1964 parameterized. This is done for several reasons. First, it facilitates 1965 the addition of new parameter types as the protocol evolves. Second, 1967 it allows for the omission of parameters that do not pertain to a 1968 particular product type. This is particularly important in the 1969 Announce message. 1971 All parameter data fields are a multiple of four bytes (i.e. 32 bits). 1972 When such a field is used to contain an integer, its format is as 1973 shown below. The integer is represented in two's complement notation. 1974 The most and least significant bytes are 0 and 3, respectively. 1976 MSB LSB 1977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1978 | Byte 0 | Byte 1 | Byte 2 | Byte 3 | 1979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1980 <--------------------------- 32 Bits ---------------------------> 1982 Figure 12-2 Basic Field Format 1984 The type-length-value structure is shown below. The minimum parameter 1985 unit length is 64 bits. The Name and Length fields both consist of 1986 two 16 bit fields. The value field is variable length, but is always 1987 a multiple of 32 bits. When the value field contains a character or 1988 octet string that is not a multiple of 32 bits, the field is extended 1989 so that the 32 bit multiple requirement is always met. This means that 1990 1, 2, or 3 pad bytes are added to the end of the string, and the value 1991 of those bytes is set to zero. However, the length field defines the 1992 true length of the value. 1994 |<------------ 32 bits -------->| Variable 1995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -+ 1996 | Type/length | Value | 1997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -+ 1999 Figure 12-3 Type-Length-Value Format 2001 Each item of data that is conveyed in the payload area of the message 2002 is identified as a separate message parameter and structured with the 2003 type-length-value format. Each parameter may be used in one or more 2004 message types. 2006 The following table defines the complete list of parameters and 2007 includes the parameter description, type, and length. 2009 Each parameter is described in the message definition sections below 2010 so that their use is understood in the context of each message type. 2011 Parameters may be required, optional, or omitted depending on the 2012 message type and data product type. 2014 Parameter | Type | Data Length 2015 --------------------------------------------------------------- 2016 Announce Duration 0x0100 4 2017 Announce Options 0x0101 4 2018 Application Reference 0x0102 variable(1-64) 2019 Block Number 0x0103 4 2020 Block Range 0x0104 8 2021 Block Size 0x0105 4 2022 Cancel Reason 0x0106 4 2023 Client Address 0x0107 4 2024 Data Rate 0x0108 4 2025 Data Transfer Duration 0x0109 4 2026 DTU Number 0x010A 4 2027 DTU Range 0x010B 8 2028 DTU Size 0x010C 4 2029 Echo Sequence 0x010D 4 2030 Echo Data 0x010E variable(1-4096) 2031 Error Threshold 0x010F 4 2032 Event Count 0x0110 4 2033 Event Hash 0x0111 16 2034 Event List 0x0112 variable 2035 Host List(complex) 0x0113 variable 2036 Host List(simple) 0x0114 variable 2037 Group Options 0x0115 4 2038 Public Address 0x0116 4 2039 Pass Number 0x0117 4 2040 Private Address 0x0118 4 2041 Product Data 0x0119 variable 2042 Product Name 0x011A variable (1-256) 2043 Product Size 0x011B 4 2044 Registration Response 0x011C 4 2045 Response Address 0x011D 4 2046 Response Port 0x011E 4 2047 Serial Number 0x011F 4 2048 Server Address 0x0120 4 2049 Server Port 0x0121 4 2050 Status Type 0x0122 4 2051 User Data 0x0123 variable (1-64) 2052 Backoff Window 0x0124 4 2053 Aggregation Time Remaining 0x0128 4 2054 Aggregation Time per Hop 0x0129 4 2056 Figure 12-4 Message Parameters 2058 12.1 MCP Messages 2060 The MCP messages have been listed in the Protocol Description section 2061 above. The format of each message is described below. All messages 2062 begin with the common protocol header (see Protocol Header above). 2064 All subsequent fields are used to convey parameters to the receiving 2065 host, and use the type-length-value format. Each message description 2066 provides a list of the parameters included in that message type and 2067 whether each parameter is required or optional. The parameters may 2068 appear in the message in any order, not necessarily in the order 2069 presented in the list. 2071 12.1.1 Query Group Message 2073 The purpose of the Query Group message is to allow a Client to 2074 determine a Server's public address when only the Server's IP address 2075 is known. The message is sent in unicast mode to the Server. The 2076 response to this message is a Join Group message, also sent in unicast 2077 mode. A separate Join Group is returned for each public address active 2078 at the Server. If there are no public addresses active, then no 2079 response is sent by the Server. The Query Group message contains the 2080 following parameters. 2082 Application Reference String (Mandatory) 2083 Group Options (Mandatory) 2085 Application Reference String 2087 Given that there may be different (i.e. incompatible) application 2088 layer users of MFTP, this parameter serves to identify the application 2089 type operating at the Server and the Clients. 2091 The parameter is an ASCII character string that identifies the 2092 application type. For example, the StarBurst file transfer application 2093 uses the string "StarBurstMFTP". 2095 In a Client message, such as Query Group, the application running at 2096 the Client is identified. Hence, the Server responds to the message 2097 only when an application of the same type is running at the Server. In 2098 a Server message, such as Join Group (see below), this parameter 2099 identifies the application type that is running at the Server. The 2100 Client may then use the information to determine if it will respond to 2101 the Server message. That is, only Clients that have the same type 2102 application layer users should respond to the message. 2104 Group Options 2106 This parameter defines various options associated with group 2107 management and is contained in both the Group Query and Join Group 2108 messages. The parameter is a combination bit and byte field, as 2109 defined below: 2111 Byte Bit Setting 2112 PRODUCT TYPE 2113 0 0-7 'F' = file product 2114 'A' = all product types 2115 COMMON OPTIONS 2116 1 0-7 Unused, set to zero 2118 2 0-7 Unused, set to zero 2119 3 0-7 Unused, set to zero 2121 Each option is explained below: 2123 Product Type This option identifies the product type(s) that a 2124 Client wants to receive (as used in Query Group 2125 message) or that a Server is transmitting(as used 2126 in Join Group message). Only file product is now 2127 defined. 2129 Common Options None currently defined. 2131 12.1.2 Join Group Message 2133 This message may be sent as a response to the Query Group message (see 2134 above), or as an unsolicited message to one or more Clients. In the 2135 former case, it provides the Server's public multicast address to the 2136 Client so that the Client may join the group to receive product 2137 announcements. In the latter case, it may specify the public address, 2138 or any other multicast address that the Server wants the Client(s) to 2139 join. When sent as a response to the Query Group message, it is sent 2140 in unicast mode. Otherwise, the message may be sent in unicast, 2141 broadcast, or multicast modes. The message contains the following 2142 parameters. 2144 Application Reference (mandatory) 2145 Multicast Address (mandatory) 2146 Group Options (mandatory) 2147 Host List (simple) (optional) 2149 Application Reference String 2151 Refer to the Query Group message for a description of this parameter. 2152 The Client joins the indicated group only if the Client has an 2153 application user of the same type indicated in the message. 2155 Multicast Address 2157 This parameter contains the multicast address that the receiving host 2158 should join. Normally, this will be the Server's public address, but 2159 may be any multicast address that the Server wants the Client(s) to 2160 join. 2162 Group Options 2164 Refer to the Query Group message for a description of this parameter. 2165 The Server sets the Product Type field of this parameter to identify 2166 the type of data products that may be received by joining the 2167 indicated public multicast address. 2169 Host List (simple) 2171 This parameter is included when the sender wants to specify specific 2172 hosts that should act on the message. If the message is to apply to 2173 all receiving hosts, this parameter is omitted. 2175 This parameter is an array of host records. Each host record in the 2176 array consists of a single 32 bit field, called the host identifier. 2177 Each host identifier contains the IP address, or optionally a GID, of 2178 a host. The address is stored in network byte order. 2180 There are other messages that may contain the Host List parameter 2181 (e.g. Announce, Abort). Whenever the length of the Host List does not 2182 fit within a single message, the Host List is divided and sent in two 2183 or more copies of the same message type. The multiple messages are 2184 considered a single logical message by the Server. 2186 12.1.3 Leave Group Message 2188 The purpose of the Leave Group message is to direct one or more remote 2189 hosts to leave a multicast group. The message may be sent in unicast, 2190 broadcast, or multicast modes. The message contains the following 2191 parameters. 2193 Multicast Address (mandatory) 2194 Host List(simple) (optional) 2196 Multicast Address 2198 This parameter specifies the multicast group that the Client(s) should 2199 leave. 2201 Host List (simple) 2203 Refer to the Join Group message for a description of this parameter. 2205 12.1.4 Echo Message 2207 The Echo message may be transmitted by any MFTP station. The purpose 2208 of the message is to test the network path, and the reliable transfer 2209 of data over that path, between the source and destination hosts. The 2210 response to this message is the Echo Response message (see next 2211 section). This message is similar in concept to the Echo message of 2212 the Internet Control Message Protocol (RFC792). This message may be 2213 sent in unicast, broadcast, or multicast modes. The message contains 2214 the following parameters. 2216 Echo Sequence (mandatory) 2217 Echo Data (optional) 2218 Host List(simple) (optional) 2220 Echo Sequence 2222 This parameter is a sequence number to aid in matching a response with 2223 a transmitted message. 2225 Echo Data 2227 This optional parameter is an octet string that can be sent with the 2228 Echo message and is returned in the Echo Response message. 2230 Host List (simple) 2232 Refer to the Join Group message for a description of this parameter. 2234 12.1.5 Echo Response Message 2236 The Echo Response message may be transmitted by either a Server or 2237 Client, as a response to a received Echo message. This message is sent 2238 in unicast mode always. 2240 All parameters received in the Echo message, except the host list, are 2241 echoed back to the sender exactly as received. The host list, if 2242 contained in the Echo message, is omitted from the response. Refer to 2243 the Echo Message above. 2245 12.2 MDP Messages 2247 The MDP messages have been listed in the Protocol Description section 2248 described previously. The format of each message is described below. 2249 All messages begin with the common protocol header (see Protocol 2250 Header, Figure 12-1). All subsequent fields are used to convey 2251 parameters to the receiving host, and use the type-name-length-value 2252 format. Each message description provides a list of the parameters 2253 included in that message type and whether each parameter is required 2254 or optional. 2256 Unless otherwise stated, the parameters in messages sent by the Server 2257 may appear in the message in any order, not necessarily in the order 2258 presented in the list. To allow efficiency in aggregating response 2259 messages (when used), most response formats specify that the 2260 parameters must be in the order shown. 2262 12.2.1 Announce Message 2264 The Announce message is sent only by the Server. The purpose of the 2265 message is to allow the Server to announce the impending transmission 2266 of a data product, to describe the data product, and to solicit 2267 Registration message responses from Clients (depending on group type). 2268 The Announce message may be sent in unicast, broadcast, or multicast 2269 mode. In multicast mode, it is sent to the Public address. 2271 The Announce message contains the parameters listed below. An 2272 intermediate network entity that is performing response aggregation 2273 may need to monitor Announce messages in order to obtain parameters 2274 that are needed for aggregation processing, such as the Response 2275 Address. Therefore, the first five parameters (Server Address/Port, 2276 Response Address/Port, and Private Address) must appear at the 2277 beginning of the message payload area and in the order shown. Other 2278 parameters may appear in any order. 2280 Server Address (mandatory) 2281 Server Port (mandatory) 2282 Response Address (mandatory) 2283 Response Port (mandatory) 2284 Private Address (mandatory) 2285 Announce Duration (mandatory) 2286 Announce Options (mandatory) 2287 Application Reference (mandatory) 2288 Block Size (mandatory) 2289 Data Rate (mandatory) 2290 Product Name (mandatory) 2291 Data Transfer Duration (mandatory) 2292 DTU Size (mandatory) 2293 Product Size (mandatory) 2294 Error Threshold (optional) 2295 User Data (optional) 2296 Host List (complex) (optional) 2298 Server Address 2300 This parameter is the IP address, in network byte order, of the 2301 Server. Its purpose is primarily for response aggregation. This 2302 parameter is copied to the response by the Client so that the 2303 aggregating entity knows where to send the aggregated response. 2305 Server Port 2307 This parameter is the receive UDP port number of the Server. Its 2308 purpose is primarily for response aggregation. This parameter is 2309 copied to the response by the Client so that the aggregating entity 2310 knows where to send the aggregated response. 2312 Response Address 2314 This parameter is the address to which Client response messages are to 2315 be sent. This allows responses to be sent to or intercepted by an 2316 intermediate aggregating entity. The address may be a unicast or 2317 multicast address, in network byte order. If response aggregation is 2318 not being performed, this address is the host IP address of the 2319 Server. 2321 Response Port 2323 This parameter is the receive UDP port at the Response Address to 2324 which Client response messages are to be sent. 2326 Private Address 2328 This parameter specifies the network address to which the Server will 2329 transmit the product data. For a multicast transmission, this is a 2330 multicast group address. The Client must join the multicast group to 2331 receive the product data. Otherwise, this parameter specifies a 2332 unicast or broadcast address. 2334 Announce Duration 2336 This parameter is the time, in seconds, remaining before the product 2337 data transmission will begin. It is updated at each Announce message 2338 transmission so that it accurately reflects the remaining time. The 2339 Client does not act on this information. It is provided primarily as 2340 an item of information to the application layer user. The initial 2341 value of this parameter is provided by the Announce Time Limit 2342 configuration parameter (see Configuration above). 2344 Announce Options 2346 This parameter defines various options associated with a product 2347 transmission. The parameter is a combination bit and byte field, as 2348 defined below: 2350 Byte Bit Setting 2351 PRODUCT TYPE 2352 0 0-7 'F' = file product 2353 COMMON OPTIONS 2354 1 0-1 01 = closed group 2355 10 = open limited group 2356 11 = open unlimited group 2357 2 1 = do not leave delivery group 2358 0 = leave delivery group 2359 3-7 Unused, set to zero 2360 FILE OPTIONS 2361 2 0 1 = initial transmission 2362 0 = restart transmission 2363 1 1 = overwrite existing file 2364 0 = preserve existing file 2365 2 1 = late entry allowed 2366 0 = late entry disallowed 2367 3-7 Unused, set to zero 2369 Each option is explained below: 2371 Product Type This option identifies the product type. Only 2372 file product is currently defined. 2374 Common Option 1 This group option defines whether the product 2375 (bit 0-1) may be received by any Client, or only by those 2376 specified in the Host List parameter (refer to 2377 the Group Management section above) 2379 Common Option 2 This option specifies whether the Client should 2380 (bit 2) or should not leave the data delivery group 2381 after the product delivery has completed. If 2382 the Server intends to send more than one 2383 product to the same Client group, then group 2384 setup time can be minimized by keeping Clients 2385 joined to the group. Since this option is 2386 contained in each product announcement, the 2387 final product announcement can direct Clients 2388 to leave the group after the transmission has 2389 completed. 2391 File Option 1 The initial/restart option indicates whether 2392 this is an initial transmission of the file 2393 (i.e. the entire file will be sent) or whether 2394 it is a restart of a file previously sent but 2395 not received completely by all Clients. 2397 File Option 2 The overwrite/preserve option indicates whether 2398 a Client should overwrite or preserve a current 2399 file that has the same name as specified in the 2400 Product Name parameter (see above). If this 2401 option is set to overwrite, then the Client is 2402 allowed to receive the new file and overwrite 2403 the old file. If this option is set to 2404 preserve, then the Client declines to receive 2405 the new file and preserves the existing file at 2406 the host. 2408 File Option 3 The late entry option defines whether a Client 2409 may participate in a file restart if it has not 2410 yet received any of the file. Since the file 2411 will have to be entirely transmitted for the 2412 Client, it will slow down other Clients that 2413 may need only a small portion of the file to 2414 complete their receipt of it. However, it does 2415 allow the Server to transmit the file to 2416 Clients that may have been offline when the 2417 file was originally sent. If the option is set 2418 to allowed, then a Client that has not yet 2419 received any of the file may participate in the 2420 file transfer. If the option is set to 2421 disallowed, then only Clients that have 2422 previously received some portion of the file 2423 may participate. 2425 Application Reference String 2427 Refer to the Join Group message for a description of this parameter. 2428 The Client will not respond to this message unless its application 2429 type matches this value. 2431 Block Size 2433 This parameter is the number of DTUs that will be transmitted in each 2434 block. It allows the Client to initialize and manage its memory 2435 resources used for tracking DTUs that have been received or missed. If 2436 the product is a file, this value is limited by the maximum size of 2437 the bit map form of the Event List that can be carried in a Status 2438 Response message (see Event List below). 2440 Data Rate 2442 This parameter specifies the Server's transmit data rate. The Client 2443 may use this information to decide whether it can successfully 2444 participate in the product transfer. That is, the Client might decline 2445 a product transfer if it knows that the data rate will overrun the 2446 Client. 2448 Data Transfer Duration 2450 This parameter specifies the maximum amount of time, in seconds, that 2451 the Server will devote to the product delivery (not including the 2452 product announcement phase). The Client uses this value as its receive 2453 timeout. This parameter is configured (see Configuration section 2454 above). 2456 DTU Size 2458 This parameter is the maximum number of data bytes that will be 2459 contained in each DTU for a file transfer. The last DTU may contain 2460 less than this number of bytes. This value is computed by MFTP based 2461 on the size of the network Maximum Transmission Unit, the lower level 2462 protocol headers, and the other parameters that must reside in a DTU. 2464 Error Threshold 2466 This parameter defines the percentage of missed DTUs, relative to the 2467 total number of DTUs in the transmission, that can occur at a Client 2468 before the Client voluntarily removes itself from participation in the 2469 product transfer. That is, the Client monitors its own error rate and 2470 initiates its own removal from the transfer if this threshold is 2471 reached. This mechanism helps to prevent a small number of Clients 2472 with high error rates from adversely affecting all other Clients by 2473 requesting a high percentage of retransmissions. It is permissible for 2474 the Client to continue to receive and process DTUs in anticipation of 2475 a file restart, but the Client must not send any message to the 2476 Server. 2478 Product Name 2480 This parameter is an ASCII character string that is the formal name 2481 for the product being announced. If the product is a file, this field 2482 contains the name of the file that should be created on the Client 2483 system to store the product (the filename may be different than the 2484 filename at the Server). 2486 Product Size 2488 This parameter is the total length, in bytes, of a file product. It 2489 allows the Client to determine if there is sufficient disk space to 2490 receive and store the product. 2492 User Data 2494 This parameter is an octet string that is provided by the application 2495 layer user. It is delivered to the application layer user at the 2496 Client. It could be used, for example, to describe the product being 2497 announced. Its use is optional and is limited to 64 octets. 2499 Host List (complex) 2501 This parameter is an array of host records. Each host record in the 2502 array consists of two 32 bit fields. The first field, called the host 2503 identifier, contains the IP address, or optionally the GID, of the 2504 remote host, in network byte order. The second field, called the admin 2505 status, contains the status of the host specified in host identifier 2506 field. The format of the admin status field is defined below. 2508 Byte Bit Setting 2509 0 0-7 'A' = accepted to receive 2510 product 2511 'D' = declined status confirmed 2512 'P' = pending status 2513 1 0-7 Decline reason 2514 2 0-7 Unused, set to zero 2515 3 0-7 Unused, set to zero 2517 The usage of the Host List depends on Group type being used (also see 2518 Group Management, Section 6). For Closed Groups, the Host List is 2519 included in the message and contains the IP address or GID of each 2520 Client that is being invited to participate in the product transfer. 2521 The Admin status is initially set to 'P'. As Clients send 2522 Registration messages, the Server acknowledges receipt of the message 2523 by setting the Admin status in the next Announce message that is 2524 transmitted. When an invited Client indicates that it will be 2525 participating in the product transfer, its Admin status is set to 'A' 2526 (accepted). When an invited Client indicates that it is declining the 2527 product, its Admin status is set to 'D' (declined) and the Decline 2528 Reason field is set to the value received in the Registration message. 2529 If an uninvited Client sends a Registration message for a Closed Group 2530 announcement, the Server simply ignores the registration and sends an 2531 Abort to the client. 2533 For Open Limited Groups, the Host List is initially omitted from the 2534 Announce message. As Clients begin to send Registration messages, the 2535 Server includes the Host List in subsequent Announce messages and adds 2536 an entry for each Client that is accepted to participate in the 2537 product delivery, and the Admin status is set to 'A'. If a host is 2538 rejected by the Server (e.g. the maximum number of hosts that the 2539 Server can handle is reached), its registration is simply ignored and 2540 an entry is not placed in the Announce message. The Host List is never 2541 included for Open Unlimited Groups. 2543 12.2.2 Registration Message 2545 The Registration message is sent only by the Client in order to 2546 respond to a received Announce message. The Registration message is 2547 sent to the Response Address contained in the Announce message. The 2548 message contains the following parameters, which must appear in the 2549 order shown. 2551 Server Address (mandatory) 2552 Server Port (mandatory) 2553 Client Address (mandatory) 2554 Registration Response (mandatory) 2556 This response may be aggregated and relayed by an intermediate entity 2557 to increase scalability. A single response that is not relayed 2558 contains only the parameters shown. A relayed response repeats the 2559 Client Address, Serial Number, and Registration Response parameters 2560 for each Client that is being relayed. 2562 Server Address 2564 This field is echoed by the Client, exactly as received in the 2565 Announce message. It may be used by an intermediate network entity 2566 during the aggregation/relaying process. 2568 Server Port 2570 This field is echoed by the Client, exactly as received in the 2571 Announce message. It may be used by an intermediate network entity 2572 during the aggregation/relaying process. 2574 Client Address 2576 This field identifies the Client that is sending the response, and 2577 identifies individual Clients in an aggregated/relayed response. The 2578 address is in network byte order. 2580 Registration Response 2582 This parameter indicates the Client's intention to participate or not 2583 participate in the transmission of a product announced by a Server. If 2584 the Client accepts the offer to participate in the transmission, the 2585 reason for decline field has no meaning and is set to the value zero. 2586 This parameter is a byte array with the following definition. Refer to 2587 Section 13 for a list of the decline reasons. 2589 Byte Bit Setting 2590 0 0-7 'A' = accept 2591 'D' = decline 2592 1 0-7 Decline reason 2593 2 0-7 Unused, set to zero 2594 3 0-7 Unused, set to zero 2596 12.2.3 Data Transfer Message 2598 The Data Transfer message is transmitted only by the Server in order 2599 to transfer the data product to the Clients. There is no response by 2600 the Client to this message. This message may be sent in unicast, 2601 broadcast, or multicast mode. In multicast mode, this message is sent 2602 to the Private address. The message contains the following parameters. 2604 Pass Number (mandatory) 2605 Block Number (mandatory) 2606 DTU Number (mandatory) 2607 Product Data (mandatory) 2609 Pass Number 2611 This parameter contains the current pass number. The first pass is 2612 numbered 1, and increments for each additional pass. This parameter 2613 allows the Client to unambiguously determine the current pass number. 2614 This is primarily useful for reporting reception status to an 2615 application layer user. 2617 Block Number 2619 This parameter contains the sequence number of the current block, 2620 within the current pass, starting at 1. 2622 DTU Number 2624 This parameter contains the sequence number of the current DTU, within 2625 the current block, starting at 1. 2627 Product Data 2629 This parameter is the actual file data bytes being delivered to the 2630 Client. 2632 12.2.4 Status Request Message 2634 The Status Request message is sent only by the Server in order to 2635 query the Client for its reception status. The Client responds with an 2636 ACK or NAK Response message, depending on the type of status requested 2637 (only NAKs are normally used). The Status Request message may be sent 2638 in unicast, broadcast, or multicast mode. In multicast mode, it is 2639 sent to the Private address. The message contains the following 2640 parameters. 2642 Pass Number (mandatory) 2643 Block Range (mandatory) 2644 DTU Range (mandatory) 2645 Status Type (mandatory) 2646 Host List (simple) (optional) 2648 Pass Number 2650 This parameter identifies the pass for which the Server is requesting 2651 status. If there is no applicable pass number (e.g. the Server is 2652 querying for status prior to a file restart), then this parameter 2653 value is set to zero. 2655 Block Range 2657 This parameter identifies the range of blocks for which the Server is 2658 requesting status. The parameter consists of two 32-bit fields. The 2659 first field contains the number of the first block in the range, and 2660 the second field contains the number of the last block in the range. 2661 If status is being requested for a single block, both fields are set 2662 to the same block number. 2664 DTU Range 2666 This parameter identifies the range of DTUs within a block for which 2667 the Server is requesting status. The parameter consists of two 32-bit 2668 fields. The first field contains the number of the first DTU in the 2669 range, and the second field contains the number of the last DTU in the 2670 range. The range cannot span multiple blocks. If status is being 2671 requested for a single block, then this parameter may specify a subset 2672 of all DTUs in the block. When status for multiple blocks is being 2673 requested, this parameter is set to the first and last DTU numbers of 2674 the entire block. That is, a DTU subset request is invalid when the 2675 Server is requesting status for multiple blocks. 2677 Status Type 2679 This parameter is an integer that identifies the type of status 2680 response that is being requested by the Server. The values are shown 2681 below: 2683 1 = NAK responses only - The Client responds only if it recognizes 2684 that it has not received one or more DTUs 2685 in the block(s) specified by the Server. 2686 It sends a NAK response message. 2687 Otherwise, it sends no response at all. 2688 This is the preferred mode of operation. 2689 2 = ALL responses - The Client always responds regardless of 2690 its reception status. If it has received 2691 all DTUs in the indicated block, it sends 2692 an ACK response message. Otherwise, it 2693 sends a NAK response message. 2695 Host List (simple) 2697 Refer to the Join Group message for a description of this parameter. 2698 It is included when the sender wants to specify Clients that should 2699 respond to the message. If the message is to apply to all receiving 2700 Clients, this parameter is omitted. 2702 12.2.5 NAK Response Message 2704 The NAK Response message is sent only by the Client when queried by 2705 the Server via the Status Request message. The Client sends this 2706 response if the Status Request message specifies either the ALL or NAK 2707 response status type and the Client needs to request the 2708 retransmission of one or more DTUs in the indicated block. The NAK 2709 Response message is sent to the Response Address as specified in the 2710 Announce message. The response message contains the following 2711 parameters, which must appear in the order shown. 2713 Server Address (mandatory) 2714 Server Port (mandatory) 2715 Client Address (mandatory) 2716 Pass Number (mandatory) 2717 Block Number (mandatory) 2718 Event Count (mandatory) 2719 Event Hash (mandatory) 2720 Event List (mandatory) 2722 Server Address 2724 This field is echoed by the Client, exactly as received in the 2725 Announce message. 2727 Server Port 2729 This field is echoed by the Client, exactly as received in the 2730 Announce message. 2732 Client Address 2734 This field identifies the Client that is sending the response. The 2735 address is in network byte order. 2737 Pass Number 2739 This parameter is as specified for the Status Request message above. 2740 That is, the received value is echoed in the response message. 2742 Block Number 2744 The value of this parameter is set to the block number that is being 2745 reported. If the Server requests status for a single block, then this 2746 parameter contains the same number. If the Server requests status for 2747 a range of blocks, then a separate response message is returned for 2748 each block in the range and this parameter is set to the block number 2749 that is being reported in each message. 2751 Event Count 2753 This parameter indicates the total number of NAKed DTUs that are being 2754 reported in this message. In other words, this is the number of bits 2755 that are set in the Event List parameter. 2757 Event Hash 2759 This parameter is the result of a hash function being applied to the 2760 Event List parameter. The purpose is for the receiver to be able to 2761 easily determine if the Event List for any two or more Clients is 2762 identical. The MD5 hash function is used. This is useful for 2763 aggregation/relaying, when used. 2765 Event List 2767 This parameter identifies the DTUs that the Client has not received 2768 for the block in the Block Number field. It is a bit map, where each 2769 bit in the map represents a single DTU in the block. A bit set to '1' 2770 means that the DTU has not been received and a bit set to '0' means 2771 the DTU has been successfully received by the Client. Note that the 2772 Server may request the status for a subset of the DTUs in a block via 2773 the DTU Range parameter in the Status Request message. The Client 2774 still sends a complete bit map, but sets the bits for all DTUs outside 2775 the range to '0' (successfully received). Also note that the DTU Range 2776 parameter is not echoed in the response message. 2778 12.2.6 ACK Response Message 2780 The ACK Response message is sent only by the Client when queried by 2781 the Server via the Status Request message. The Client sends this 2782 response if the Status Request message specifies the ALL response 2783 status type and the Client has successfully received all of the DTUs 2784 in the indicated block (Note that this is not the preferred mode of 2785 operation). The ACK Response message is sent to the Response Address 2786 as specified in the Announce message. The response message contains 2787 the following parameters, which must appear in the order shown. 2789 Server Address (mandatory) 2790 Server Port (mandatory) 2791 Pass Number (mandatory) 2792 Block Range (mandatory) 2793 Client Address (mandatory) 2795 Server Address 2797 This field is echoed by the Client, exactly as received in the 2798 Announce message. 2800 Server Port 2802 This field is echoed by the Client, exactly as received in the 2803 Announce message. 2805 Pass Number 2807 This parameter is as specified for the Status Request message above, 2808 i.e. the received value is echoed in the response message. 2810 Block Range 2812 This parameter identifies the range of blocks for which the Client is 2813 reporting ACK status. The parameter consists of two 32-bit fields. The 2814 first field contains the number of the first block in the range, and 2815 the second field contains the number of the last block in the range. 2816 If status is being reported for a single block, both fields are set to 2817 the same block number. 2819 Note that the Server may request the status of a range of blocks, and 2820 the Client may return both ACK and NAK responses, according to the 2821 status of each block. While NAK responses are sent individually for 2822 each block being reported by the Client, the ACK response may report 2824 the successful reception of a range of blocks. 2826 Client Address 2828 This field identifies the Client that is sending the response, and 2829 identifies individual Clients in an aggregated response. The address 2830 is in network byte order. 2832 12.2.7 Done Message 2834 The Done message is sent only by the Client to the Server to indicate 2835 that a complete product has been received successfully. The message is 2836 sent to the Response Address as specified in the Announce message. The 2837 message contains the following parameters, which must appear in the 2838 order shown. 2840 Server Address (mandatory) 2841 Server Port (mandatory) 2842 Client Address (mandatory) 2843 Event Count (mandatory) 2844 Data Transfer Duration (mandatory) 2846 Server Address 2848 This field is echoed by the Client, exactly as received in the 2849 Announce message. 2851 Server Port 2853 This field is echoed by the Client, exactly as received in the 2854 Announce message. 2856 Client Address 2858 This field identifies the Client that is sending the response. The 2859 address is in network byte order. 2861 Event Count 2863 This parameter reports the total number of DTUs that the Client 2864 reported as missed during reception of the product. In other words, 2865 the field contains the total of all DTUs reported in NAK Response 2866 messages sent to the Server during reception of the product. 2868 Data Transfer Duration 2870 This parameter reports the actual time, in seconds, that was required 2871 for the Client to receive the product. 2873 12.2.8 Completion Message 2875 The Completion message is sent only by the Server in order to confirm 2876 receipt of Done messages from Clients. When Clients are not sending 2877 Done messages (i.e. Open-unlimited groups), the message announces the 2878 end of a transmission. This message may be sent in unicast, broadcast, 2879 or multicast mode. In multicast mode, this message is sent to the 2880 Private address. The message contains the following parameter. 2882 Host List (simple) (optional) 2884 Host List 2886 This parameter is included only when the Clients are sending Done 2887 messages. The inclusion of a Client IP address or GID in the list 2888 confirms receipt of the Client's Done message. 2890 12.2.9 Abort Message 2892 The Abort message is sent only by the Server in order to cancel a 2893 product announcement or product delivery that is currently in progress 2894 or to abort a specific Client or Clients. There is no response to 2895 this message by the Client, so multiple Abort messages should be sent 2896 to increase the probability of success. The message may be sent in 2897 unicast, broadcast, or multicast mode. In multicast mode, the message 2898 is sent to the Private address. The message contains the following 2899 parameters. 2901 Cancel Reason (mandatory) 2902 Host List (simple) (optional) 2904 Cancel Reason 2906 This parameter indicates the reason that the Server is aborting a 2907 product transmission. Refer to Section 13 for the value list. 2909 Host List (simple) 2911 Refer to the Join Group message for a description of this parameter. 2912 This parameter is included when the Server wants to Abort a subset 2913 of the Client population. If the parameter is omitted, then all 2914 receiving Clients are affected. 2916 12.2.10 Quit Message 2918 The Quit message is sent only by the Client in order to terminate its 2919 participation in the current product transfer. There is no response to 2920 this message by the Server, so multiple messages should be sent to 2921 increase the probability of success. The message is sent to the 2922 Response Address as specified in the Announce message. It includes the 2923 following parameters. 2925 Cancel Reason (mandatory) 2927 Cancel Reason 2929 This parameter indicates the reason that a Client is terminating 2930 reception of a product transmission. Refer to Section 11 for the 2931 value list. 2933 12.2.11 End Message 2935 The End message is sent only by the Server in order to conveniently 2936 indicate to aggregating entities in the network, if present, that the 2937 session is over. End messages are sent four times after the Server 2938 has determined the session is over on the Public Address. There are no 2939 response messages back to the End message. 2941 The End message includes the following parameters. 2943 Server Address (mandatory) 2944 Server Port (mandatory) 2945 Response Address (mandatory) 2946 Response Port (mandatory) 2948 13.Reason Codes 2950 The various "reason" codes used in PDUs are listed below. Refer to 2951 previous sections for a description of the message types and 2952 configuration parameters mentioned here. 2954 Client Registration Message - decline reasons 2956 1001 insufficient disk space 2957 1002 insufficient memory 2958 1003 system error (disk, I/O, etc) 2959 1004 already have file. The Server has indicated in the Announce 2960 message that the Client should preserve any existing copy of 2961 the file. Therefore, the Client is confirming that it already 2962 has the file and will not be participating in the current 2963 transfer. Refer to the overwrite/preserve file option in the 2964 Announce message. 2965 1005 no file to restart. The Server has indicated that this is a 2966 file restart. However, the Client does not currently have any 2967 portion of the file and the sender wants to restrict the 2968 transfer to only those Clients that already have a portion of 2969 the file. Refer to the initial/restart and late entry file 2970 options in the Announce message. 2971 1006 unknown application type (ARS). The Announce message specifies 2972 an ARS that does not match the ARS set by the application 2973 layer user. Refer to the Application Reference String 2974 parameter in the Announce message. 2975 1007 no interest in sender. The application layer user has not 2976 specified this Server as one of the Servers that it wishes to 2977 receive data products from. 2978 1008 no interest in product type. The application layer user has 2979 not specified this product type as one of the types that it 2980 wishes to receive. Currently, only file product is supported 2981 but this provides expansion capability for the future. Refer 2982 to the product type specification in the Announce message. 2984 Client Quit Message - cancel reasons 2986 2001 application action. The user application has terminated 2987 this product transfer 2988 2002 transfer timeout. The maximum time duration specified for the 2989 transfer of this product has expired. Refer to the Data 2990 Transfer Duration parameter in the Announce message. 2991 2003 system error. An unrecoverable host error has occurred. 2992 2004 error threshold. The error threshold has been reached for this 2993 Client. Refer to the Error Threshold parameter in the Announce 2994 message. 2996 Server Abort Message - cancel reasons 2998 3001 application action. The user application has terminated this 2999 product transfer. 3000 3002 transfer timeout. The maximum time duration specified for the 3001 transfer of this product has expired. Refer to the Delivery 3002 Time Limit configuration parameter. 3003 3003 status timeout. The maximum time duration specified for status 3004 acquisition has expired. Refer to the Status Retry Timer and 3005 Status Retry Count configuration parameters. 3006 3004 system error. An unrecoverable host error has occurred. 3008 14. Future Extensions 3010 Work is ongoing to provide improvements to the basic MFTP protocol. 3011 Some of the improvements under consideration are: 3013 1. More comprehensive flow control. As currently defined, MFTP 3014 handles flow control simply by having client receivers with 3015 excessive DTU error rates (excessive as defined by the server) 3016 remove themselves from the group. 3017 2. Potential of using FEC techniques to reduce repair traffic 3018 when there are large numbers of receivers (erasure 3019 correction). 3020 3. Addition of Security (see Section 15). 3021 4. Interfaces to the mmusic protocols. 3022 5. Interfacing to RSVP. 3024 15. Security Considerations 3026 This version of the protocol does not include any distinct message 3027 types or additional fields for existing messages that will be needed 3028 to support security. Security is currently under study and the 3029 specification will be updated at a future time to address the security 3030 requirements based on the work performed in the IPSEC IETF Working 3031 Group. 3033 16. Acknowledgments 3035 The authors would like to thank Scott Bradner (Harvard University), 3036 Ken Cates (StarBurst Communications), and Tony Speakman (Cisco 3037 Systems) for their comments and suggestions on various aspects of 3038 this document. 3040 References 3042 [1] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, 3043 August 1989. 3045 [2] Postel, J., Reynolds, J. "File Transfer Protocol (FTP)", RFC 3046 959, October 1985. 3048 [3] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., 3049 "RTP: A Transport Protocol for Real-Time Applications", RFC 3050 1889, January 1996. 3052 [4] Schulzrinne, H.,"RTP Profile on Audio and Video Conferences 3053 with Minimal Control", RFC 1890, January 1996. 3055 Author's Addresses 3057 Kenneth Miller Phone: +1 (978) 287-5560 3058 StarBurst Communications, Inc. Email: miller@starburstcom.com 3059 150 Baker Ave. 3060 Concord, MA 01742 3062 Kary Robertson Phone: +1 (978) 287-5560 3063 StarBurst Communications, Inc. Email: krobertson@starburstcom.com 3064 150 Baker Ave. 3065 Concord, MA 01742 3067 Alex Tweedly Phone: +1 (408) 526-8114 3068 Cisco Systems, Inc. Email: agt@cisco.com 3069 170 West Tasman Drive 3070 San Jose, CA 95134 3072 Marc White Phone: +1 (978) 287-5560 3073 StarBurst Communications, Inc. Email: mwhite@starburstcom.com 3074 150 Baker Ave. 3075 Concord, MA 01742