idnits 2.17.1 draft-miller-mftp-spec-02.txt: -(62): 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-25) 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 2 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 55 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 57 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 327 has weird spacing: '...its own resou...' == Line 984 has weird spacing: '...esponse tran...' == Line 1614 has weird spacing: '...pletion messa...' == Line 1615 has weird spacing: '...pletion messa...' == Line 1950 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 2914, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 2917, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 2920, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 2924, 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 January, 1997 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 learn the current status of any Internet-Draft, please check 24 the ``1id-abstracts.txt'' listing contained in the Internet- 25 Drafts Shadow Directories on ftp.is.co.za (Africa), 26 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 27 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 29 Abstract 31 The Multicast File Transfer Protocol (MFTP) is a protocol that 32 operates above UDP in the application layer to provide a reliable 33 means for transferring files from a sender to up to thousands 34 (potentially millions with network "aggregators" or relays) of 35 multiple receivers simultaneously over a multicast group in a 36 multicast IP enabled network. The protocol consists of two parts; an 37 administrative protocol to set up and tear down groups and sessions, 38 and a data transfer protocol used to send the actual file reliably and 39 simultaneously to the multiple recipients residing in the group . 41 Intellectual Property Rights 43 StarBurst Communications owns U.S Patent 5,553,083 covering the method 44 for data transfer used in the Multicast File Transfer Protocol (MFTP) 45 described herein. StarBurst hereby records a grant by StarBurst 46 Communications Corporation to permit the conditional free use of this 47 patent to help facilitate adoption of MFTP by the Internet community 49 StarBurst hereby covenants that it will not assert its U.S. Patent 50 5,553,083 or its non-U.S. counterparts against any party that 51 implements MFTP or any derivative that includes MFTP, and operates in 52 compliance with MFTP or such derivative, when MFTP or such derivative 53 is employed in connection with any Internet Protocol. 55 This grant of rights will terminate with respect to any party that 56 asserts a patent it owns, directly or indirectly, against StarBurst 57 for StarBurst�s implementation of and operation in compliance with 58 MFTP or any derivative, as defined above. The termination will occur 59 as of the date the patent is asserted against StarBurst. 61 A written confirmation of this grant, and/or a license under any other 62 StarBurst patent under StarBurst�s then current terms, conditions, and 63 royalty rates must be obtained by sending a request to: 65 Edward M. Durkin 66 StarBurst Communications Corp. 67 150 Baker Avenue 68 Concord, MA 01742 70 Table of Contents 72 1. Introduction.....................................................3 73 2. Definitions......................................................5 74 3. MFTP Architecture................................................8 75 4. Scaling..........................................................10 76 4.1 Scaling Extensions.........................................11 77 5. Performance......................................................11 78 6. Group Management.................................................11 79 6.1 Joining Clients to Private Groups..........................12 80 6.2 Joining Clients to the Public Group........................13 81 7. Response Address ................................................14 82 8. Response Suppression.............................................15 83 9. Configuration....................................................16 84 9.1 Announce Time Limit........................................16 85 9.2 Fast Announce Option.......................................17 86 9.3 Announce Intervals.........................................17 87 9.4 Announce Persistence.......................................17 88 9.5 Status Interval............................................17 89 9.6 Status Retry Timer.........................................17 90 9.7 Status Retry Count.........................................18 91 9.8 Delivery Time Limit........................................18 92 9.9 Completion Interval........................................18 93 9.10 Transmit Rate.............................................18 94 9.11 Register Retry Timer......................................18 95 9.12 Register Retry Count......................................18 96 9.13 Response Back-off Timer...................................19 97 9.14 Response TTL..............................................19 98 10. Multicast Control Protocol......................................19 99 10.1 Creating Multicast Groups (Join Group & Group Query)......19 100 10.2 Dissolving Multicast Groups (Leave Group).................20 101 10.3 Determining Group Membership (Echo & Echo Response).......20 102 11. Multicast Data Protocol.........................................21 103 11.1 Product Announcement......................................22 104 11.1.1 Closed Groups.......................................25 105 11.1.2 Open Limited Groups.................................26 106 11.1.3 Open Unlimited Groups...............................26 107 11.2 Product Delivery..........................................26 108 11.2.1 File Delivery - Server..............................26 109 11.2.2 File Delivery - Client..............................29 111 11.3 Product Completion........................................30 112 11.3.1 File Product Completion - Client....................31 113 11.3.2 File Product Completion - Server....................32 114 11.4 Flow Control..............................................34 115 12. Message Formats.................................................34 116 12.1 MCP Messages .............................................37 117 12.1.1 Query Group Message..................................38 118 12.1.2 Join Group Message ..................................39 119 12.1.3 Leave Group Message .................................40 120 12.1.4 Echo Message ........................................40 121 12.1.5 Echo Response Message ...............................41 122 12.2 MDP Messages..............................................41 123 12.2.1 Announce Message.....................................41 124 12.2.2 Registration Message ................................47 125 12.2.3 Data Transfer Message ...............................48 126 12.2.4 Status Request Message...............................48 127 12.2.5 NAK Response Message.................................50 128 12.2.6 ACK Response Message.................................51 129 12.2.7 Done Message.........................................52 130 12.2.8 Completion Message...................................53 131 12.2.9 Abort Message........................................54 132 12.2.10 Quit Message........................................54 133 12.2.11 End Message.........................................54 134 13. Reason Codes....................................................55 135 14. Future Extensions...............................................56 136 15. Security Considerations.........................................56 137 16. Acknowledgments.................................................57 138 References..........................................................57 139 Author's Addresses..................................................57 141 1. Introduction 143 This document provides a description of the StarBurst Multicast File 144 Transfer Protocol (MFTP). 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. 151 Real Time Non-Real Time 152 +--------------+--------------+ 153 | | | 154 Multimedia | RTP/RTCP | MFTP | 155 | | | 156 +--------------+--------------+ 157 | Many | | 158 Data only | Proposals | MFTP | 159 | | | 160 +--------------+--------------+ 162 Figure 1-1 Multicast Applications and Protocols 164 Figure 1-1 shows a spectrum of multicast applications and the 165 protocols serving them. StarBurst MFTP is designed to address the 166 non-real time applications depicted in the right half of the diagram. 167 Other reliable multicast protocols attempt to solve the non-real time 168 and data only real time applications with one protocol. 170 This MFTP specialization brings a number of benefits, including: 172 1. Simplicity, which generally means increased reliability 173 2. Virtually no performance change over high delay networks such as 174 satellite 175 3. Ability to be scaleable to thousands of recipients over one hop 176 networks such as satellite with no intermediate relaying 177 entities 178 4. Ability for the sender (Server) to have complete knowledge of 179 the state of receivers (Clients) 181 Additionally, MFTP has flexibility so that optional features can be 182 invoked to increase scalability beyond thousands, including: 184 1. Aggregation and relaying of responses by the network 185 infrastructure or other intermediate entity 186 2. Response suppression to reduce responses from members of a 187 subnet similar to that used by IGMP as specified in RFC 1112 189 Both of these techniques can be used to increase scalability by 190 reducing Client message traffic to the Server. 192 Typical applications for MFTP include electronic software 193 distribution, transmission of critical information to field offices, 194 distribution of multimedia information to local servers, and 195 replication of web servers to the edges of networks for improved 196 performance. A significant new application is the ability to provide 197 subscription based "push" information delivery to receivers who have 198 signed up for a particular information service. 200 MFTP is designed to operate with networks that support multicast and 201 broadcast data transport at the link layer such as LANs and SMDS, and 202 with multicast IP router networks. Multicast user groups can be set 203 up for either type network. When the network is router-based, data is 204 delivered only to hosts in the multicast group based on multicast IP 205 addresses. Each host supports RFC1112, Host Extensions for IP 206 Multicasting. 208 When the network does not support multicast, data may be broadcast 209 with multicast groups defined at the application layer at each MFTP 210 host. This means that data is broadcast within the network but 211 filtered at the MFTP host so that only members of the defined group 212 receive the data. Data may also be sent in unicast mode to a single 213 receiver. 215 The MFTP Server (data sender) manages the multicast groups, initiates 216 the file transfer, and controls the transfer operation. The MFTP 217 Client (data receiver) joins the multicast group, receives the data 218 sent by the Server, and provides reception status to the Server when 219 requested. 221 MFTP transmission is efficient because data is sent in a streaming 222 mode. This means that the Server continuously sends data without 223 waiting for responses from Clients. Acknowledgment traffic generated 224 by the Clients is minimized because the Clients send responses only 225 for Data Transmission Units (DTUs) that are not received. In addition, 226 the status for a range of DTUs is aggregated in each response, further 227 reducing the response traffic. At the end of a file transmission, the 228 DTUs reported by the Clients as lost or received in error are 229 retransmitted by the Server. 231 MFTP supports file checkpoint/restart so that an interrupted file 232 transfer may be resumed without retransmitting data that has already 233 been received by the Clients. Unlike other protocols that use all 234 available bandwidth to transmit data, MFTP allows a maximum Server 235 transmit rate to be specified. This allows files to be transmitted 236 without stealing bandwidth needed by other applications. 238 MFTP consists of two protocol components - the Multicast Control 239 Protocol (MCP) and the Multicast Data Protocol (MDP). MCP allows the 240 Server to dynamically control the joining and leaving of Clients to 241 multicast groups. MDP then handles the reliable transmission of data 242 products to the Clients that have joined the multicast group. 244 The major features and characteristics of MFTP are summarized below. 246 Reliable data transfer via selective NAK mechanism 247 Uses multicast transmission, as defined in RFC 1112 248 Scaleable to thousands of recipients without intermediate entities 249 Scaleable to millions with intermediate entities to aggregate 250 responses 251 Includes multicast group management and control 252 First level congestion control mechanism defined 253 Minimal performance change on high delay networks such as satellite 254 Additionally supports broadcast and unicast transmission 255 The maximum data rate of each transmission is specified 256 File checkpoint/restart is supported 258 2. Definitions 260 This section provides definitions for terms used in this document. 262 Aggregation: The process of collecting responses from Clients and 263 combining them into one response to be relayed back to the Server. 264 This reduces the back traffic to the Server and thus increases the 265 number of Clients that can be served. 267 Announcement: The process of informing Clients that a data transfer is 268 about to start. This involves sending a message to the "well known" 269 multicast group address where Client hosts have joined and are 270 listening for such messages. The message identifies the data product, 271 its size, name, etc. This message is retransmitted at regular 272 intervals for a configured time period (e.g. 3 minutes). After the 273 product announcement phase is completed, the Server begins the 274 transmission of the product (see Product Delivery below). 276 ARS: Application Reference String. This is a variable length, case- 277 sensitive string that the application provides to identify itself. It 278 is used by MFTP to ensure that data is sent and received by like 279 applications. 281 Authorized Client: A term used primarily for Closed Groups where the 282 IP address of each Client that is allowed to receive the data is 283 included in the Announce message. That is, the Client is "authorized" 284 by the applications to receive the data if the Client finds its IP 285 address in the Announce message. All other Clients are prohibited from 286 receiving the data. 288 Block: A group of MFTP data messages. Clients report the receive 289 status of data messages a block at a time. 291 Client: The receive function of the MFTP protocol. A single MFTP 292 implementation may contain only a Client function, or it may contain 293 both a Client and Server function (see Server below). Therefore, 294 Client does not necessarily refer to the host itself. 296 Closed Group: A form of group management where the Server specifies 297 the Clients that are allowed to participate in the data transfer. All 298 other Clients are prohibited from receiving the data. Also refer to 299 Open Limited Group and Open Unlimited Group. 301 Data Product: A file that is sent by the Server to Clients. 303 Done Message: A message sent from the Clients to the Server to 304 indicate that the Client has received a complete data product. 306 DTU: Data Transfer Unit. A protocol message which contains the data 307 that is being sent by the Server to the Clients. 309 Message Implosion: With a large number of Client hosts, all sending 310 messages to the Server, it is possible for the Server to be overrun 311 and messages to be lost. It is important for the protocol to minimize 312 the number of messages that are being directed to any single host. An 313 example of this is the negative-acknowledgment scheme that is used to 314 obtain a Client's reception status and the way that the status for a 315 range of DTUs is grouped together into a single response message. 317 MFTP: Multicast File Transfer Protocol. The protocol described in this 318 document. 320 MTU: Maximum Transmission Unit. The largest unit of data, in bytes, 321 that can be transmitted over the user's physical network. 323 Open Limited Group A form of group management where the Server does 324 not specify which Clients may participate in the data transfer. Any 325 Client that wishes to receive the data is required to register with 326 the Server. The Server may limit the number of participants based on 327 its own resources or some other criteria. Also refer to Closed Group 328 and Open Unlimited Group. 330 Open Unlimited Group: A form of group management where the Server does 331 not specify which Clients may participate in the data transfer. 332 Clients that wish to receive the data are not required to register 333 with the Server. Also refer to Closed Group and Open Limited Group. 335 Pass: For a file transmission, MFTP makes one "pass" through the file 336 to transmit the file data. It then makes another "pass" through the 337 file to retransmit data that was not received during the first pass. 338 Additional passes may also be made to deliver the product successfully 339 to all receiving hosts. 341 Private Address: The network address to which a Server transmits the 342 data product. The Server specifies the Private Address in the Announce 343 message for each product transfer. The private address is most 344 relevant in multicast transmission because separate multicast 345 addresses are used for product announcement and delivery. Only Clients 346 that are authorized to receive a product actually join the multicast 347 group defined by the private address. 349 Product Delivery: The process of transmitting the data product from a 350 Server to Clients. The data is transmitted in messages called Data 351 Transfer Units (DTUs). A group of DTUs is called a block. The 352 transmission of the entire data product once is called a pass. No DTU 353 retransmissions occur during a pass. Rather, additional passes are 354 made when retransmissions are required. However, only the missed DTUs 355 are retransmitted on each subsequent pass. This phase is always 356 preceded by the Product Announcement phase (see Announcement above). 358 Public Address: The network address to which a Server transmits a 359 product announcement. The public address is most relevant in multicast 360 transmission because separate multicast addresses are used for product 361 announcement and delivery. Any number of Servers may announce products 362 to a single public address and any number of Clients may join the 363 multicast group defined by the public address. 365 Registration: The process of a Client informing a Server that the 366 Client intends to participate in the product transmission that is 367 currently being announced. The Client does this by sending a 368 Registration response message to the Server. This response is sent to 369 the address specified by the "Response Address" parameter in the 370 Announce message. 372 Relay: An entity that forwards messages to another destination after 373 receiving them. For example, an aggregator also acts as a relay by 374 combining Client responses and then forwarding them to the Server or 375 another aggregator. Relays can also be Clients that in turn act as 376 Servers for another group that cannot be reached directly by the 377 Server or for efficiency. 379 Response Address: An IP address (unicast or multicast) to which 380 Clients send Registration, Status, and Done messages. The Response 381 Address is specified in the Announce message. The ability to specify 382 an address other than the Server's address allows an intermediate 383 entity to perform aggregation/relaying of the responses. 385 Server: The transmit function of the MFTP protocol. A single MFTP 386 implementation may contain only a Server function, or it may contain 387 both a Server and Client function (see Client above). Therefore, 388 Server does not necessarily refer to the host itself. 390 Transmission ID: A number that uniquely identifies an individual data 391 product transmission that originates from a single Server. The 392 concatenation of the Server's IP address and the Transmission ID 393 uniquely identifies any MFTP transmission in the network. The 394 Transmission ID is included in every MDP message sent by the Server 395 and Client. 397 3. MFTP Architecture 399 MFTP operates above the User Datagram Protocol (UDP) layer of the 400 TCP/IP protocol suite. As such, it uses the UDP Sockets interface. 402 MFTP defines both a send function (the Server) and a receive function 403 (the Client). The Server only transmits data products and the Client 404 only receives data products. An implementation may optionally include 405 both functions, as shown in Figure 3-1 or may only have one. The 406 checksum, defined in UDP, is the usual mechanism to determine if a 407 datagram is corrupted. Some implementations may not include a UDP 408 checksum; in these cases, an optional checksum is provided by MFTP. 410 +-+-+-+-+ +-+-+-+-+ 411 | File | | File | 412 +-+-+-+-+ +-+-+-+-+ 413 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 414 +-+-+-+->| Server | Client |+-+-+-+-> 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | ^ 417 V | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | UDP Layer | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | IP Layer | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 Figure 3.1 MFTP Data Architecture 426 File products can be transmitted directly from the file system by the 427 Server and written directly to the file system by the Client. All 428 implementations are required to support the MFTP Echo message and Echo 429 Response message, which provide functions similar to "ping". 431 Transmission Modes 433 Messages sent by the Server may be sent in either unicast, broadcast, 434 or multicast mode. The Client must be able to receive Server messages 435 in any of these modes. This allows flexibility in designing the Server 436 to achieve network optimization goals. For example, unicast may be 437 used to send an Abort message to a single Client when that is the only 438 Client that is being aborted. All other Clients are spared from having 439 to receive the message on the multicast group. An entire product 440 transfer can occur in unicast mode when there is only a single Client 441 receiver. 443 Broadcast mode may be used when the network does not support IP 444 multicast. All Clients receive the messages, but messages that are not 445 directed to the Client are filtered and discarded. This mode should 446 normally be avoided because of its impact on the network. 448 The remainder of this document generally assumes multicast 449 transmission, unless otherwise stated. 451 Well-Known UDP Port 453 IANA-assignment of a "well-known" UDP port will be requested for MFTP. 454 Certain MFTP messages must be sent to this port because it will be the 455 only port number known both to the sender (Server) and the receivers 456 (Clients). This includes the MCP messages, the Announce message and 457 the Data message. 459 An MFTP station may include both the Server and Client function, both 460 using the well-known port. To reduce the traffic on the well-known 461 port, a Server may dynamically allocate a source "session" port to 462 send a data product and to receive responses from the Clients. The 463 Announce message is sent to the Client's well-known port. Client 464 responses are returned to the source session port number. The Client 465 may also allocate a session port to send messages, rather than using 466 the well-known port. 468 The Server sends all messages to the Client's well-known port. The 469 specified session port is in effect only for the current product 470 delivery. This use of session ports is illustrated in Figure 3-2. 472 +-+-+-+-+-+ +-+-+-+-+-+ 473 | | | | 474 | +-+-+-+-+-+-+-+-+ Announce, data+-+-+-+-+-+-+-+-+ | 475 | |well known port| /+-+-+-+-+-+->|well known port| | 476 | +-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+ | 477 | Server | / | Client | 478 | | / | | 479 | +-+-+-+-+-+-+-+-+/ Client Resp. +-+-+-+-+-+-+-+-+ | 480 | | session port |<-+-+-+-+-+-+-+-+-| session port | | 481 | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | 482 | | | | 483 +-+-+-+-+-+ +-+-+-+-+-+ 485 Figure 3-2 Session Ports 487 4. Scaling 489 By focusing on file based delivery rather than attempting to be a 490 generalized reliable multicast transport layer, improvements in 491 scaling without requiring intermediate aggregation points are 492 achieved. It is known that the limitation for scaling in reliable 493 multicast protocols is the NAK Implosion problem, where the 494 administrative (NAK) back traffic from receiver (Client) to sender 495 (Server) eventually overwhelms the sender as the number of receivers 496 grows. The use of blocks in MFTP aggregates NAKs from each 497 recipient so that one NAK with a bit map of the DTUs in the block can 498 represent thousands of bad or dropped DTUs, depending on the actual 499 number of bad or dropped DTUs in the block. 501 Although not required, MFTP recommends that the block size be tied to 502 the MTU size so that the bit map in one NAK packet exactly fits the 503 number of DTUs in a block. For example, if the MTU is 1500 bytes at 504 the MAC layer (the maximum for Ethernet), the block size consists of 505 over 11 thousand DTUs. Thus, a burst of thousands of dropped DTUs 506 within a block results in only one NAK rather than thousands (see 507 Section 11.2.1). 509 Even when the MTU at the IP layer is 576 bytes, the maximum guaranteed 510 in TCP/IP networks with no fragmentation, the block size is over 3800 511 DTUs which still provides a high level of minimization of NAK traffic. 513 Experiments have been performed by StarBurst to emulate up to 10,000 514 Client receivers in one Closed group transmission and no significant 515 performance degradation was observed. Obviously, scaling behavior 516 will be affected by percent error rate and/or packet loss rate in the 517 network, with the better the network characteristic the better the 518 scaling. With MFTP, the Open Unlimited group model has scaling 519 performance totally dependent on NAK traffic; however, for Closed and 520 Open Limited group models, all Client receivers Register and all 521 Client receivers send Done messages, the latter acting as one ACK for 522 the entire file. Thus, in these models, all receivers send one 523 message at the beginning and at the ending of the transmission. This 524 traffic in fact becomes the scaling limitation in the Closed and Open 525 Limited group models. 527 Products using MFTP in essentially the same form as described in this 528 document have been operating in private networks since mid 1995. At 529 the time of this writing, several installations are operating in a 530 production environment with over 1000 simultaneous receivers and one 531 installation expects to be operating with about 9000 receivers in a 532 group later in 1997. 534 4.1 Scaling Extensions 536 In addition to the minimization of administrative back traffic 537 described above, provision is made in MFTP to extend scaling to 538 hundreds of thousands and perhaps millions of simultaneous receivers 539 depending on the network characteristics by using network aggregation 540 entities to further consolidate administrative back traffic. 541 Additionally, provision is made for NAK suppression on subnets, 542 similar to the method used by IGMP as specified in RFC 1112. 544 5. Performance 546 MFTP is a rate based protocol with a transmission rate defined by the 547 sender (Server). By design, it does not attempt to provide error 548 correction in real time but takes advantage of the non-real time 549 nature of file transmission. Thus, transmission remains continuous at 550 the set transmission rate through the total transmission of the file 551 in the first pass, with corrections made in subsequent passes. This 552 makes MFTP very insensitive to delay such as occurs over satellite 553 networks and also makes it tolerant of asymmetric data channels. 555 Performance is affected as the number of simultaneous receivers grows, 556 as this increases the number of bad or dropped packets in aggregate 557 for the group resulting in more retransmissions. However, in practice 558 there is often high correlation in bad/dropped packets among 559 receivers. For example, all receivers downstream from a congested 560 node will experience the same packet drops caused by that node. Since 561 the retransmissions are sent to the same multicast group, they will 562 all get the same correction simultaneously on a subsequent pass. 564 Protocol overhead is modest, both in header size and in the amount of 565 processing needed. Thus, MFTP can be expected to be able to exceed 566 the performance of FTP even in a point to point application. 568 6. Group Management 570 MFTP uses the push method for distributing data products. That is, at 571 a time determined by the Server user application, a data product 572 transmission is "announced" to the Client population. This 573 announcement consists of transmitting Announce messages for a 574 period of time, followed by the data product itself. The Announce 575 message identifies the data product that will be transmitted, its 576 size, and other parameters documented herein. 578 MFTP uses two separate multicast groups, called the public group and 579 the private group. The Server announces products on its public group 580 address and Clients join the address to receive announcements. The 581 product data is transmitted on the private group address. That is, the 582 public group address is where any Client may join and listen for 583 announcements made by any Server that is sending to the public 584 address. However, only Clients that are authorized by the application 585 to receive a particular transmission actually join the private 586 address. 588 The public/private group architecture is shown in Figure 6-1. Clients 589 1 - 3 are joined to and listening on the public group. Only Client 3 590 wants to receive the product that has been announced and has joined 591 the private group to receive it. 593 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+ 594 | Server |+-+-+-+-+-+->| Public Group |+-+-+-+-+-+->|Client1| 595 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+\ +-+-+-+-+ 596 | \ \ 597 | \ \ 598 | \ \ +-+-+-+-+ 599 | \ \+-+-+-+>|Client2| 600 | \ +-+-+-+-+ 601 | \ 602 | +-+-+-+-+-+-+-+-+ \+-+-+->+-+-+-+-+ 603 +-+-+-+-+-+-+-+-+-+-+>| Private Group |+-+-+-+-+-+->|Client3| 604 +-+-+-+-+-+-+-+-+ +-+-+-+-+ 606 Figure 6-1 Group Architecture 608 Group management deals with how Clients learn about and are joined 609 to the public and private groups. The attributes of the public group 610 are discussed first, with the assumption that Clients are already 611 joined to it. Once a Client is joined to the public group, it learns 612 about the private group in the Announce message. Finally, the method 613 used to join Clients to the public group is discussed. 615 6.1 Joining Clients to the Private Group 617 Use of the public group is completely flexible in that there may be 618 one for each Server or multiple Servers may transmit product 619 announcements to a single group address. It is recommended that the 620 number of public groups be kept to a minimum, even one. This allows 621 the use of a single public group for Clients to listen for 622 announcements from many Servers without requiring a separate multicast 623 group for each one. 625 In order to direct the product data to only those Clients that 626 actually want to receive it, the product announcement message includes 627 a field that specifies a separate private multicast address. The 628 Clients then dynamically join the private address and the Server 629 transmits the product data on that address. Note that while joined to 630 the private group the Client continues to be a member of and listens 631 for product announcements on the public address. This allows the 632 Client to receive multiple data products simultaneously, if it so 633 desires. 635 Normally, the Clients leave the private address at the end of the 636 product transfer and continue to listen for product announcements 637 on the public address. However, if the Server is going to transmit 638 multiple data products, it may set an option in the product 639 announcement that directs the Clients to not leave the private 640 address. This reduces the overhead associated with joining and leaving 641 multicast groups. By also announcing the next product transmission 642 on the public group, Clients that did not hear or did not participate 643 in the previous transfer may be added to the private group. 645 If the Server is supplied with more than one private address, it may 646 arbitrarily use any one of the addresses to transmit a data product. 647 Multiple addresses would typically be used to send multiple products 648 to different groups at the same time by a single Server. 650 MFTP includes a unique transmission identifier in each message so that 651 the Client can always distinguish messages that are associated with an 652 individual data transmission. 654 6.2 Joining Clients to the Public Group 656 To discuss how Clients are joined to the public address, there are two 657 models that are considered, Closed and Open. 659 In the Closed model, the Server knows in advance which Clients 660 are authorized to receive a data transmission, and the number of 661 Clients is relatively small (e.g. thousands of Clients). This allows 662 the Server to tightly control group membership. 664 The public address may be known and configured in advance at the 665 Clients or the Server may use the MFTP Multicast Control Protocol to 666 direct Clients to join the public group. This type of group 667 management is called Closed Groups since the Server restricts the 668 membership of the group. This control occurs at two levels - (1) 669 either by configuration or by use of MCP, the members of the group 670 are restricted and (2) the product announcement itself includes a list 671 of Clients that are authorized to participate. 673 Upon receiving the Announce message, the Clients designated to join 674 the group register with the Server by sending a Registration message. 675 All other Clients are administratively told not to join the group and 676 thus do not receive the transmission. This is a Server-centric mode of 677 operation that allows the Server to tightly control which Clients 678 receive the data and also minimizes the number of Registration 679 messages arriving at the Server. It also allows the Server to keep 680 detailed statistics on each Client. This mode is most useful when the 681 data product has a value associated with it that prevents it from 682 being freely distributed. 684 In the Open models, the receiving Clients are not known to the Server. 685 This means that the Server is not able to configure the multicast 686 groups via MCP. A Client must be able to obtain the public group 687 address of Servers that it is interested in, perhaps by using the MCP 688 Group Query message or by using one of the external protocols defined 689 in the mmusic working group. 691 Since the MFTP server is not determining those Clients that join its 692 session, this type of group management is called "Open Group". 693 There are two variations of Open Groups, called "Limited" and 694 "Unlimited", as discussed below. 696 The Limited mode allows the Server to announce a transmission without 697 specifying the Clients that are authorized to receive the data. This 698 may be because the Server does not know in advance which Clients may 699 want to receive the data, or the number of potential Clients may be 700 very large. 702 This type of group allows any Client to request participation in the 703 data delivery, but the Server limits the number of actual participants 704 based on some criteria determined by the application. As Clients 705 register to receive the data, the Server learns the identity of each 706 Client. Therefore, like the Closed Group, the Server is able to keep 707 detailed statistics on each Client. In fact, after the 708 Announce/Registration phase, protocol operation is identical to the 709 Closed Group. This mode is most useful when it is permissible to 710 freely distribute the product, but the sender wants to know who is 711 receiving it. 713 The Unlimited mode allows any Client to participate in the data 714 delivery and the Server does not limit the number of participants. To 715 achieve this, certain types of Client responses are waived to prevent 716 message implosion at the Server. This includes the Registration and 717 Done messages. The only Client response that is retained is the Status 718 Response message. Since Clients send this message only for DTUs that 719 are not received, there will not necessarily be a response from every 720 Client. The Server is unable to identify each receiving Client when 721 this mode is used, so it is most useful when the data product can be 722 freely distributed and the sender does not care to know who is 723 receiving the product. 725 7. Response Address 727 The Server specifies the response address parameters in the Announce 728 message. Each Client then sends all response messages to the specified 729 response address (regardless of whether the Server message is received 730 in unicast or multicast mode). 732 A different response address than the Server may be used by an 733 aggregating entity in the network to collect responses from clients 734 and reduce implosion traffic to the Server. This increases the 735 scalability, i.e., the number of clients supported. The use of a 736 multicast response address with a suitable TTL may be used for 737 aggregation and is required for response suppression (see Section 6). 738 The response parameters include the following: 740 Response IP Address (may be different than Server's IP address) 741 Response port number (may be different than Server's port number) 742 Server IP address 743 Server port number 745 The Response IP Address may be either a unicast or multicast address. 746 The normal mode is that the Response IP Address and port number be 747 that of the Server if optional aggregation and/or suppression is not 748 used. 750 The Server IP address and port number are echoed in the Client's 751 response. This is the address and port where the response must 752 eventually be sent by an intermediate relay point, if present. 754 8. Response Suppression 756 Response message suppression is an optional Client function that 757 eliminates the sending of redundant status messages from a single 758 subnet, such as a LAN. That is, congestion that occurs upstream from 759 the subnet will produce an identical set of dropped messages at each 760 Client on the subnet. The result is all Clients send identical status 761 responses to a Status Request message. This can be avoided by having 762 the Clients listen to each other's response and suppress duplicate 763 responses. 765 Response message suppression is used only with the sending of the NAK 766 Response message. Other Client responses are sent in the normal manner 767 described in this document. 769 The NAK Response message is sent to the multicast Response Address 770 as specified in the Announce message. Each Client must be joined to 771 this address in order to hear the response of other Clients on the 772 subnet. 774 When a Status Request message is received by the Client, and the 775 request causes a NAK response message to be built, the Client does not 776 immediately send the message. Rather, a delay timer is started. Each 777 Client's delay timer is a different, randomly-chosen value between 0 778 and n seconds, where n is configurable with a default value of 1 779 second. The Client uses a pseudo-random number generator to compute 780 its delay timer value, using the Client's own host IP address as part 781 of the seed to reduce the chance of multiple Clients generating the 782 same delay. 784 While waiting for its own delay timer to expire, each Client receives 785 and examines the status responses sent by other Clients. If the pass 786 number, block number, and event hash fields all match the Client's 787 unsent message, the Client's unsent message is discarded and the delay 788 timer is canceled. Otherwise, the Client continues to listen to and 789 examine additional responses. If no matching message is received 790 before the Client's delay timer expires, the Client transmits its own 791 response message. Any response messages received after the Client's 792 message has been transmitted are ignored. If a new Status Request 793 message is received from the Server while the delay timer is running, 794 the Client immediately sends its current response message, cancels the 795 timer, and processes the new Status Request as described above. 797 The response suppression function is applied at the subnet level. 798 Since all Clients participating in a product transfer will join to the 799 multicast Response Address, messages that leave a subnet will also 800 arrive at all other Clients joined to the group and will be processed 801 as described above. When message aggregation is performed by the 802 network infrastructure (see Message Aggregation above), the network 803 can prevent responses from being propagated anywhere except back to 804 the Server. 806 9. Configuration 808 The following configuration parameters affect the operation of the 809 protocol: 811 Announce Time Limit 812 Fast Announce Option 813 Announce Interval 814 Announce Persistence 815 Status Interval 816 Status Retry Timer 817 Status Retry Count 818 Delivery Time Limit 819 Completion Interval 820 Transmit Rate 821 Register Retry Timer 822 Register Retry Count 823 Response Back-off Timer 824 Response TTL 826 Some parameters may apply only to product transmission, only to 827 product reception, or to both. The application of each parameter is 828 noted in the following descriptions. Also refer to the description of 829 the protocol and message formats below for additional information. 831 9.1 Announce Time Limit 833 This parameter sets the maximum time, in seconds, that MFTP will 834 use for the announce phase of a product transmission. The announce 835 phase will last for this duration unless the Fast Announce Option (see 836 below) is used. 838 9.2 Fast Announce Option 840 This parameter only applies to Closed Groups. The Server may shorten 841 the duration of the Announcement immediately after all members of the 842 group register. This is the normal mode of operation in the Closed 843 Group model. 845 9.3 Announce Intervals 847 This parameter sets the interval, in seconds, between successive 848 transmissions of the Announce message during the product announce 849 phase. 851 9.4 Announce Persistence 853 This parameter specifies whether the Announce message should 854 continue to be sent during the product delivery phase. This could be 855 desirable in the Open Unlimited group model where the Announce can act 856 as an advertisement" for what is being transmitted. 858 9.5 Status Interval 860 This parameter specifies the interval, in seconds, between Status 861 Request messages sent by the Server to the Clients. It is used to 862 establish the transmit block size. A default block size will be 863 computed, based on the MTU. This block size will maximize the amount 864 of NAK information that can be sent in a single status response 865 message by the Client. The Server sends the status request message at 866 the end of each transmitted block. However, for a large MTU (and 867 therefore a corresponding large block size), a relatively long time 868 may elapse before there is any status information that can be returned 869 to the application about the NAK status of individual Clients. The 870 application may set the Status Interval parameter to the time interval 871 that it wants the Server to request NAK status from the Clients. The 872 block size is adjusted for the requested interval so that a block of 873 DTUs is sent in the interval and then NAK status is requested by the 874 Server. 876 9.6 Status Retry Timer 878 This parameter specifies the time duration, in seconds, that the 879 Server will wait for Client responses after a Status Request message 880 is sent. 882 This timer is not used for Status Request messages sent during a pass 883 because the Server does not stop and wait for responses. However, at 884 the end of the pass, the Server cannot begin the next pass if no 885 responses (status response or Done message) have been received for 886 the current pass. In this case, the Server sends a Status Request 887 message, starts the Status Retry timer, and waits for any responses. 888 When the timer expires, the Server begins the next pass if any status 889 response messages were received. If there is no response, the Server 890 sends another Status Request message and restarts the retry timer. 892 When there are no responses, this procedure continues up to the 893 retry limit set by the Status Retry Count (see below) or until the 894 Delivery Time Limit is reached, whichever occurs first. 896 9.7 Status Retry Count 898 This parameter specifies the maximum number of times that the 899 Server will retransmit a Status Request message when no response is 900 received from any Client. Refer to Status Retry Timer above to see 901 how it is used. 903 9.8 Delivery Time Limit 905 This parameter sets the maximum time for the product delivery phase of 906 a file transmission. The parameter is an integer that represents a 907 percentage, with a minimum value of 100% (i.e. value =100). MFTP 908 multiplies the integer by the optimal time that it takes to make one 909 pass through the transmit file. The result is the maximum time devoted 910 to the product delivery phase, in seconds. 912 9.9 Completion Interval 914 This parameter sets the interval, in seconds, between successive 915 transmissions of the Completion message during the product 916 transfer/completion phase. 918 9.10 Transmit Rate 920 This parameter specifies the bit rate at which a data product will be 921 transmitted by the Server. The transmit rate may fall below this 922 value due to other processing demands on the Server, but the rate 923 shall never exceed the configured value. The transmit rate applies to 924 all bits sent by the Server in a DTU, including all protocol headers. 925 The algorithm to be used to control the transmit rate is unspecified. 927 9.11 Register Retry Timer 929 This parameter specifies the frequency, in seconds, that the Client 930 will resend a Registration message once data transfer phase begins. 931 During the Announce phase, the Registration message is resent every 932 time that an Announce message is received that does not confirm the 933 previous Registration transmission. Hence, the stimulus for 934 Registration retransmission is the received Announce message and the 935 rate of retransmission is identical to that of the Announce message 936 (see Announce Interval parameter above). 938 9.12 Register Retry Count 940 This parameter specifies the maximum number of times that the 941 Client will retransmit a Registration message during the data 942 delivery phase in order to solicit a confirmation from the Server. 943 Refer to Register Retry Timer above to see how it is used. 945 9.13 Response Back-off Timer 947 This parameter specifies the maximum length of the back-off timer when 948 suppression is invoked. 950 9.14 Response TTL 952 This parameter specifies the TTL of the response message from the 953 client. It should normally be set to the maximum for the network. 955 10. Multicast Control Protocol 957 This section describes the Multicast Control Protocol (MCP). 958 Configuration parameters and message formats are described in 959 separate sections. 961 The purpose of MCP is to allow a Server to control the dynamic 962 joining and leaving of remote hosts to multicast groups. MCP defines 963 the following message types: 965 Join Group transmitted by the Server to dynamically join Clients 966 to multicast groups. This message is normally unicast 967 to an individual Client, but may be multicast to an 968 existing multicast group. 970 Group Query transmitted by the Client to query a Server for its 971 current public multicast group address. This message 972 is unicast to the Server. 974 Leave Group transmitted by the Server to dynamically cause Clients 975 to leave a multicast group. This message may be 976 unicast to an individual Client or multicast to an 977 existing multicast group. 979 Echo transmitted by any MFTP station to determine if a 980 remote host is reachable and running MFTP. This 981 message may be unicast to an individual host, or 982 multicast to an existing multicast group. 984 Echo Response transmitted as a response to a received Echo message. 985 This message is unicast to the originating host. 987 MCP provides for creating multicast groups, dissolving multicast 988 groups, and determining group membership. Each of these is 989 discussed below. Also refer to the Message Format section for 990 additional information. 992 10.1 Creating Multicast Groups (Join Group and Group Query) 994 Multicast group formation may be initiated by both the Server and 995 the Client. If a Client knows the IP address of a Server, but not it's 996 public address where it is announcing product transmissions, it may 997 send the Group Query message to the Server. The Server then sends 998 a Join Group message to the Client to get it to join the Server's 999 public multicast address. 1001 The Join Group message may be sent by a Server at any time to 1002 dynamically direct one or more Clients to join a specified multicast 1003 group. If the Client(s) are not already a member of a multicast group, 1004 the message is sent in unicast or broadcast mode. Otherwise, the 1005 message may be sent to an existing multicast group to direct Clients 1006 joined to that group to join an additional group. 1008 The Join Group message identifies the application type that is sending 1009 the message and the type of data that will be sent by the application. 1010 If the Client has an application layer user of the same type that 1011 wants to receive the indicated data products from this Server, it 1012 joins the multicast group. 1014 There is no response to the Join Group message. However, the Echo 1015 message (see below) may be used to determine which Clients have 1016 successfully joined the group. Since the Echo message can be sent to 1017 the new group address, only those Clients that have actually joined 1018 the new group will respond to the Echo message. 1020 10.2 Dissolving Multicast Groups (Leave Group) 1022 The Leave Group message is used to direct one or more Clients to 1023 leave a specified multicast group. The message may be sent to the 1024 existing multicast group to direct its members to leave the group, or 1025 the message may be sent in unicast or broadcast modes. 1027 There is no response to the Leave Group message. However, the Echo 1028 message (see below) may be used to determine which Clients have 1029 successfully left the group. If the Echo message is sent to the group 1030 address, there should be no response from those Clients that have 1031 left the group. 1033 10.3 Determining Group Membership (Echo and Echo Response) 1035 The Echo message may be sent at any time to determine which 1036 Clients have joined a multicast group. The receiving host responds 1037 with the Echo Response message. The response is sent if MFTP is 1038 running on the target host, without regard to whether there are any 1039 application layer users of MFTP. When users do exist, the receipt of 1040 the Echo message and the transmission of the Echo Response in no 1041 way affects those users. 1043 The Echo message may be multicast, broadcast, or unicast. If the 1044 message is unicast, then the receiving host always responds to the 1045 message. If the message is multicast or broadcast, it may contain a 1046 list of the hosts that should respond to the message. In this case, 1047 the receiving host responds only if it is specified in the host list. 1048 If there is no host list, the receiving host always responds. 1050 The Echo message may be sent by either a Server or Client. It is also 1051 useful for network testing, for example, determine if hosts are 1052 reachable, or to calculate response times. 1054 11. Multicast Data Protocol 1056 This section describes the Multicast Data Protocol (MDP). 1057 Configuration parameters and message formats are described in separate 1058 sections. 1060 The purpose of MDP is to transfer the product data from the Server 1061 to the Clients in a reliable and efficient manner. MDP defines the 1062 following message types: 1064 Announce transmitted by the Server to announce an 1065 impending product transfer. This message is 1066 sent to the Public multicast address. 1068 Registration transmitted by the Client as a response to 1069 the Announce message. This message is sent 1070 to the "Response IP Address" that is 1071 specified in the Announce message 1073 Data Transfer Unit(DTU) transmitted by the Server to deliver a data 1074 product. There is no explicit response to 1075 this message. This message is sent to the 1076 Private multicast address. 1078 Status Request transmitted by the Server to solicit status 1079 from Clients. This message is sent to the 1080 Private multicast address. 1082 Status Response/ACK transmitted by the Client in response to a 1083 Status Request message to acknowledge 1084 correct reception of a block of data 1085 messages. Normally, the Server requests 1086 only the NAK form of the status response to 1087 minimize responses from Clients. This 1088 message is sent to the Response IP Address. 1090 Status Response/NAK transmitted by the Client in response to a 1091 Status Request message to request the 1092 retransmission of data messages within a 1093 block. This is the normal response type 1094 requested by the Server and is the message 1095 that the generic term "status response" 1096 refers to in the following protocol 1097 discussion, unless otherwise noted. This 1098 message is sent to the Response IP Address 1099 (see Definition, Section 2). 1101 Done transmitted by the Client when it has 1102 received all of a product transfer 1103 successfully. This message is sent to the 1104 Response IP Address. 1106 Completion transmitted by the Server to confirm receipt 1107 of a Done message from one or more Clients. 1108 This message is sent to the Private 1109 multicast address. 1111 Abort transmitted by the Server to indicate that 1112 one or more Clients should quit 1113 participating in the current product 1114 transfer, or to indicate the premature 1115 termination of the current product transfer 1116 to all Clients. There is no response. This 1117 message is sent to the Private multicast 1118 address. 1120 Quit sent by the Client to indicate it is no 1121 longer participating in the current product 1122 transfer. There is no response. This message 1123 is sent to the Response IP Address. 1125 MDP consists of three general phases - Product Announcement, 1126 Product Delivery, and Product Completion. Each of these is discussed 1127 below. Also refer to the Configuration and Message Format sections 1128 for additional information. 1130 11.1 Product Announcement 1132 Product Announcement is the process of letting the Client population 1133 know that a product is about to be transmitted. The Server transmits 1134 the Announce message for this purpose. If multicast is being used, the 1135 message is sent on the public "well known" address. Otherwise, the 1136 message is sent in unicast or broadcast mode. The message identifies 1137 the product name, type, and other information about the transfer, 1138 including whether it is Closed, Open Limited or Open Unlimited (see 1139 Group Management above). 1141 The Announce message is sent periodically during the Announce phase. 1142 The transmission interval is specified by the Announce Interval 1143 parameter, and the duration of the Announce phase is specified by the 1144 Announce Time Limit parameter. 1146 The Announce phase serves several purposes. First, it helps to ensure 1147 that the message is actually received by the Clients since it is 1148 transmitted more than once. Second, subsequent transmissions of the 1149 message serve to confirm receipt of Registration messages received 1150 from Clients by the setting of a flag in the message. Third, the 1151 announce duration allows Clients that are experiencing problems (e.g. 1152 insufficient disk space) to resolve those problems and still register 1153 for the product transfer. 1155 When the first Announce message is sent, the Server starts the 1156 Announce Time Limit timer and the Announce Interval timer. When the 1157 interval timer expires, the Server resends the message unless one of 1158 the following conditions is true: 1160 1. The Group type is Closed and all Clients in the Host List (see 1161 below) have registered. Actually, this behavior can be modified 1162 with the Fast Announce Option (see Configuration section). Note 1163 that after the last Client registers, there must be at least one 1164 additional transmission of the Announce message to confirm the 1165 registration. Also, the Server may introduce a delay to ensure that 1166 the last Client has actually joined the Private address before the 1167 data transfer phase is started. In any case, data missed by such 1168 Clients is recovered by subsequent data transmissions of the 1169 Server. No delay is currently specified by this protocol. 1171 2. The Announce type is Open Limited and the maximum number of Clients 1172 that can be handled have registered. 1174 3. The Announce Time Limit timer has expired. If no Clients have 1175 registered when this timer expires, then the product transmission 1176 is canceled. 1178 The Announce message may contain a Host List. It is included for a 1179 Closed Group in order to identify those Clients that are directed to 1180 participate in the product transfer. As Client Registration messages 1181 are received, a flag is set in subsequent transmissions of the 1182 Announce message to confirm receipt of the Registration for each 1183 Client. The Host List is not initially included in the Announce 1184 message for an Open Limited group. However, it is included in 1185 subsequent messages to confirm those Clients that have registered. The 1186 Host List is never included in the Announce message for an Open 1187 Unlimited group. 1189 Clients specified in a Closed group announcement respond with a 1190 Registration message whether they are going to participate in the 1191 transfer or not. If the Client is not going to participate, a reason 1192 is provided in the message. This allows the Server to track problems 1193 in the group. 1195 A Server may receive more than one response from a Client during the 1196 same product announcement. The last response received should be 1197 considered the Client's "official" response. For example, the Client 1198 may initially decline the transfer due to insufficient disk space. The 1199 announce duration may allow the Client operator time to resolve the 1200 problem. If the Client operator frees up disk space, the Client may 1201 then respond that it will be participating in the transfer. 1203 The Server may receive a Quit message from the Client after the Client 1204 has registered. After receipt of the sent message, the Server should 1205 not consider the Client a participant in the product transfer. 1207 The logic flow diagram below illustrates the Server's product 1208 +-+-+-+-+-+-+-+-+ 1209 | Idle |<---------------------------+ 1210 User request to +-+-+-+-+-+-+-+-+ | 1211 transmit prod. --------------->V | 1212 +-+-+-+-+-+-+-+-+ | 1213 | Start | | 1214 |duration timer | | 1215 +-+-+-+-+-+-+-+-+ | 1216 V | 1217 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | 1218 | Send |<------| Update | | 1219 | Announce | | confirmations | | 1220 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | 1221 V ^ | 1222 +-+-+-+-+-+-+-+-+ | | 1223 | Start | | | 1224 |interval timer | | | 1225 +-+-+-+-+-+-+-+-+ | | 1226 V | | 1227 +-+-+-+-+-+-+-+-+ | | 1228 Yes | Registration |<-----+ | | 1229 +---------| fulfilled? | | | | 1230 | +-+-+-+-+-+-+-+-+ | | | 1231 | V No | | | 1232 | +-+-+-+-+-+-+-+-+ | | | 1233 | Yes | Duration timer| | | | 1234 | +----| expired? | | | | 1235 | | +-+-+-+-+-+-+-+-+ | | | 1236 | | V No | | | 1237 | | +-+-+-+-+-+-+-+-+ | | | 1238 | | |Interval timer | No | | | 1239 | | | expired? |+-----+ | | 1240 | | +-+-+-+-+-+-+-+-+ | | 1241 | | | Yes | | 1242 | | +-----------------------+ | 1243 | | +-+-+-+-+-+-+-+-+ | 1244 | | | Anyone | No | 1245 | +--->| register? |+---------------------------+ 1246 | +-+-+-+-+-+-+-+-+ 1247 | V Yes 1248 | +-+-+-+-+-+-+-+-+ 1249 | | Send | 1250 +-------->|final Announce | 1251 +-+-+-+-+-+-+-+-+ 1252 V 1253 +-+-+-+-+-+-+-+-+ 1254 | Start data | 1255 | delivery | 1256 +-+-+-+-+-+-+-+-+ 1258 Figure 11-1 1259 Server Product Announcement Phase 1261 announcement phase. "Registration fulfilled?" refers to whether all 1262 Clients in a Closed group have registered, or whether the maximum 1263 number of Clients in an Open Limited group have registered (it does 1264 not apply at all to an Open Unlimited group). "Update confirmations" 1265 refers to the setting of the registration-confirmed flag in the 1266 Announce message to confirm Client registrations. This step also would 1267 not apply to Open Unlimited groups. 1269 When a Client receives an Announce message, it examines the product 1270 information contained in the message and compares it with the 1271 requirements set by its application layer user(s). That is, it is 1272 expected that the application layer will designate the Servers that it 1273 is interested in receiving from and the types of data products that it 1274 wants to receive. Based on this information, the Client decides 1275 whether or not to receive the announced product. 1277 If the Announcement is for Open Limited or Open Unlimited Groups and 1278 the Client does not want to receive the product, then the Client sends 1279 no response and discards the message. If the Announcement is for 1280 Closed Groups and the Client does not want to, or is not able to 1281 receive the product, then it still must send a Registration message 1282 stating the reason it is declining the transfer. 1284 If a Client wants to participate in a transfer, its action is 1285 described separately for each group management type below. Note that 1286 joining and leaving the multicast group in the discussion below refers 1287 to IGMP operations and not MCP. 1289 11.1.1 Closed Group 1291 If the Client's IP address is not contained in the Host List of the 1292 Announce message, the Client sends no message and is administratively 1293 prohibited from participating in the transfer. Otherwise, it joins the 1294 data delivery multicast address (i.e. Private address) contained in 1295 the Announce message and sends a Registration message to the Response 1296 Address. 1298 The Client's registration must be confirmed by the Server before it is 1299 allowed to receive the data product. The confirmation is indicated by 1300 a flag set in a subsequent Announce message, as discussed above. If 1301 the confirmation is received, the Client waits for and receives the 1302 product data. If confirmation is not received in the next Announce, 1303 the Client resends its Registration message. 1305 If the announce duration (specified in Announce message, see Messages 1306 below), expires or the Client begins to receive product data before 1307 confirmation is received, it implies that the Server did not receive 1308 the Registration message before the start of the data delivery phase. 1309 The Client discards the received data and resends its Registration 1310 message at the Register Retry Timer interval. The number of times that 1311 the Client resends its Registration message is limited by the Register 1312 Retry Count. If no confirmation is received before the retry limit is 1313 reached, the Client returns to idle state and makes no further 1314 attempts to register for the current product transfer. Note that the 1315 Client also returns to idle state if a Completion or Abort message is 1316 received while the Client is still trying to register with the Server. 1318 11.1.2 Open Limited Group 1320 The Client joins the data delivery address contained in the Announce 1321 message and sends a Registration message to the Response Address. 1322 Subsequent operation is identical to Closed Groups in that the Client 1323 must receive confirmation of its registration before it is allowed to 1324 receive the product data. 1326 11.1.3 Open Unlimited Group 1328 The Client joins the data delivery address contained in the Announce 1329 message but sends no Registration message to the Server. The Client 1330 receives the data as sent by the Server on the data delivery address. 1332 A Client may receive an Abort message from the Server at any time 1333 during the product registration. The Client returns to idle state and 1334 is not allowed to participate in the current product transfer. When 1335 returning to idle state, the Client normally leaves the data delivery 1336 group. 1338 However, the Client would remain a member of the group if: 1340 1. The Server specified in the Announce message that Clients 1341 should not leave the data delivery group (see Announce 1342 message below). 1344 2. Other transmissions being received by this Client are using 1345 the same data delivery group address. 1347 3. The private address is the same as the public address. 1349 11.2 Product Delivery 1351 The Product Delivery phase occurs after the Product Announcement 1352 phase. The file product is transmitted by the Server to the Clients. 1354 11.2.1 File Delivery - Server 1356 DTUs are transmitted to the private multicast address. The Server 1357 logically divides the file into one or more parts, called blocks. Each 1358 block is further divided into the data size that can be transmitted in 1359 a single DTU. All blocks and DTUs are a fixed size, except the last 1360 DTU which may be shorter. The manner in which the block size is 1361 determined is discussed further below. This data organization is 1362 illustrated in Figure 11-2. 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 | File | 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 | | 1368 | | 1369 | | 1370 +-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+ 1371 | Block 1 | Block 2 | --- | Block n | 1372 +-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+ 1373 / \ 1374 / \ 1375 / \ 1376 / \ 1377 / \ 1378 / \ 1379 / \ 1380 +-+-+-+-+-+-+ +-+-+-+ 1381 |DTU1 |DTU2 | --- |DTUn | 1382 +-+-+-+-+-+-+ +-+-+-+ 1384 Figure 11-2 1385 Organization of Transmitted Data 1387 The Server transmits the file data in "passes". That is, the entire 1388 file is sent initially (i.e. pass 1). If any DTU retransmissions are 1389 required, the Server then makes another pass (i.e. pass 2) through the 1390 file, but sends only those DTUs that were reported as missed by the 1391 Clients. Additional passes may be required to successfully deliver all 1392 DTUs to all Clients. 1394 The pass, block, and DTU number of each file fragment is indicated in 1395 the DTU header (see Message Formats below). The block and DTU number 1396 assignment is static for a given MTU size such that the retransmission 1397 of any file fragment will indicate the same block and DTU number. This 1398 allows the receiver to properly insert each fragment into the file 1399 regardless of when the fragment is received. 1401 The Server uses the Status Request message to query the Clients for 1402 their receive status. The Clients send a Status Response message if 1403 they need to request the retransmission of any DTUs. Otherwise, a 1404 Client sends no Status Response to the request. Although Client status 1405 may be requested by the Server at any time, it is normally requested 1406 at the end of each block transmission. The response message contains a 1407 bit map where each bit represents the receive status of an individual 1408 DTU within the block. Hence, the status of an entire block is 1409 contained within a single response message. 1411 The Server does not stop at the end of each block and wait for a 1412 response to the Status Request message nor does it immediately resend 1413 requested DTUs. Rather, the Server simply receives and processes the 1414 responses in order to schedule which DTUs need to be resent on the 1415 next pass. This makes the protocol insensitive (unless the data 1416 product sent is very short) to network delay that can be excessive in 1417 some networks, e.g. satellite. Note that the Status Request message 1418 may be sent at any time rather than at block boundaries, if 1419 information is desired about transmissions before the end of the 1420 block. 1422 After the last block of a pass has been transmitted, the Server sends 1423 a Status Request message for that block and immediately starts the 1424 next pass if there are DTUs that need to be resent. However, if no 1425 responses have been received for any previous block in the file, the 1426 Server stops and waits for responses. The length of time that the 1427 Server waits for a response is specified by the Status Delay parameter 1428 (see Configuration above). Note that the Status Request message may 1429 specify that status is requested for a single block or for a range of 1430 blocks. When the Server sends the Status Request message because no 1431 responses have been received, it specifies all blocks in the file. If 1432 a Client has not responded because it missed a previous individual 1433 block message, this ensures that such responses are solicited. 1435 Each Status Request message specifies the current transmit pass number 1436 and the block for which status is being requested. These values are 1437 echoed by the Client in its response. The Server uses the following 1438 rules for processing Client responses. 1440 1.If the response pass number is equal to the current transmit 1441 pass number, accept the response and schedule the requested 1442 DTUs for retransmission. 1444 2.If the response pass number is not equal to the current 1445 transmit pass number, examine the block number and proceed as 1446 follows: 1448 a. If the response block number is greater than the 1449 current transmit block number, accept the response and 1450 schedule the requested DTUs for retransmission. 1452 b. Else, schedule for retransmission only those DTUs that 1453 have not already been retransmitted on this pass. 1455 The block size is a function of the Status Interval and Transmit Rate 1456 parameters. That is, the application layer user specifies the 1457 frequency at which receive status should be obtained from the Clients. 1458 The Server computes how many DTUs it can send at the Transmit Rate in 1459 the Status Interval and establishes that as the block size. The block 1460 size is computed with the following formula: 1462 block size = Status Interval x (Transmit Rate/(8 x (MTU - protocol 1463 headers))) 1465 There is an upper limit to the block size that the application may set 1466 per Transmit Rate, as determined by the maximum DTU bit map size that 1467 the MTU will allow. 1469 The default block size (used when application does not specify a 1470 Status Interval) maximizes the amount of status information that can 1471 be returned in a single message according to the MTU size. 1473 Retransmissions may continue until all Clients have received the 1474 entire file or until the Delivery Time Limit duration has expired or 1475 until the Status Retry Limit has been exceeded. If the timer expires, 1476 the Server sends an Abort message and terminates the product delivery 1477 unless it is an Open Unlimited group, at which time a Completion 1478 message is sent. It is required to send several Abort messages to 1479 ensure that the Client receives at least one message since there is no 1480 confirmation message from the Client. 1482 The logic flow diagram in Figure 11-3 illustrates the Server's Product 1483 Delivery phase. The completion processing is explained in a following 1484 section. 1486 If a file is being restarted by the Server, the Server must first 1487 determine what part of the file has not yet been received by the 1488 Clients. There are many possible ways this can be done and no specific 1489 way is specified by the protocol. For example, the Server may locally 1490 store the state at the end of an aborted transfer and restore it for a 1491 file restart. Alternatively, the Server may want to query one or more 1492 Clients to determine what parts of the file still need to be 1493 transmitted. Once this initial restart state is determined, subsequent 1494 Server operation is identical to any retransmission pass (i.e. the 1495 Server sends only those DTUs necessary to complete the file transfer). 1496 File restart is allowed for Closed and Open Limited groups, but not 1497 for Open Unlimited groups. 1499 11.2.2 File Delivery - Client 1501 As DTUs are received by the Client, the Client must examine the block 1502 and DTU number in order to store the data in its proper place in the 1503 file. As discussed above, a bit map of each block is maintained that 1504 indicates whether a DTU has yet been received. If a duplicate DTU is 1505 received, it is discarded. 1507 When a Status Request message is received from the Server, the Client 1508 immediately responds with a Status Response message for the indicated 1509 block. File delivery continues until all DTUs in the file have been 1510 received or until the receive timer expires. The receive timer value 1511 is specified by the Server in the Announce message. If the timer 1512 expires, the Client sends a Quit message and returns to idle state. It 1513 is required to send several Quit messages to ensure that the Server 1514 receives at least one message since there is no confirmation message 1515 from the Server. 1517 from Announce +-+-+-+-+-+ 1518 phase | Idle | 1519 | +-+-+-+-+-+ 1520 | ^ 1521 V | 1522 +-+-+-+-+-+-+-+ +-+-+-+-+-+ 1523 +--->|Xmit duration| Yes | Send | 1524 | | expired? |----->| Abort | 1525 | +-+-+-+-+-+-+-+ +-+-+-+-+-+ 1526 | |No 1527 | V 1528 | +-+-+-+-+-+-+-+ 1529 | | Send | 1530 | | DTU | 1531 | +-+-+-+-+-+-+-+ 1532 | | 1533 | V 1534 | +-+-+-+-+-+-+-+ 1535 |No | End of | 1536 |<---| block? | 1537 | +-+-+-+-+-+-+-+ 1538 | | Yes 1539 | V 1540 | +-+-+-+-+-+-+-+ 1541 | | Send Status | 1542 | | Request | 1543 | +-+-+-+-+-+-+-+ 1544 | | 1545 | V 1546 | +-+-+-+-+-+-+-+ 1547 |No | End of | 1548 |<---| pass? | 1549 | +-+-+-+-+-+-+-+ 1550 | | Yes 1551 | V 1552 | +-+-+-+-+-+-+-+ 1553 |Yes | Retrans. |No Completion 1554 +<---| required? |----> processing 1555 +-+-+-+-+-+-+-+ 1557 Figure 11-3 Server Product Delivery 1559 The logic flow diagram in Figure 11-4 illustrates the Client's receive 1560 data processing. The completion processing is explained in a following 1561 section. 1563 11.3 Product Completion 1565 Product Completion is the process of terminating a product transfer. 1566 File product completion for the Client is discussed first, since it is 1567 the Client that normally initiates the completion procedure. 1569 from Announce +-+-+-+-+-+ 1570 phase | Idle | 1571 | +-+-+-+-+-+ 1572 | ^ 1573 V | 1574 +-+-+-+-+-+-+-+ +-+-+-+-+-+ 1575 +--->|Receive timer| Yes | Send | 1576 | | expired? |----->| Quit | 1577 | +-+-+-+-+-+-+-+ +-+-+-+-+-+ 1578 | |No 1579 | V 1580 | +-+-+-+-+-+-+-+ 1581 | | Receive | 1582 | | DTU | 1583 | +-+-+-+-+-+-+-+ 1584 | | 1585 | V 1586 | +-+-+-+-+-+-+-+ 1587 |No | Received | 1588 |<---| Status Req.?| 1589 | +-+-+-+-+-+-+-+ 1590 | | Yes 1591 | V 1592 | +-+-+-+-+-+-+-+ 1593 | | Send Status | 1594 | | Response | 1595 | +-+-+-+-+-+-+-+ 1596 | | 1597 | V 1598 | +-+-+-+-+-+-+-+ 1599 |Yes | Retrans. |No Completion 1600 +<---| required? |----> processing 1601 +-+-+-+-+-+-+-+ 1603 Figure 11-4. Client Product Reception 1605 11.3.1 File Product Completion - Client 1607 As each DTU is received, the Client determines if it has now received 1608 the entire file. If not, data reception continues. Otherwise, for 1609 Closed and Open Limited groups, the Client sends a Done message to the 1610 Server. For Open groups, the Client simply returns to idle state 1611 without sending any message to the Server. 1613 After sending a Done message, the Client waits for receipt of a 1614 Completion message from the Server. Like the Announce message, the 1615 Completion message contains a Host List that specifies each Client 1616 for which a Done message has been received (i.e. it confirms receipt 1617 of the Done message). 1619 If the Client receives a Completion message and it's address is in the 1620 Host List, then the transfer is complete, the Client leaves the data 1621 delivery group (subject to conditions, as discussed above) and returns 1622 to idle state. Otherwise, the Done message is resent. The Done message 1623 is also resent for each Status Request message received from the 1624 Server (a Status Response is not sent). This procedure continues until 1625 the Client's Done message is confirmed or until the receive timer 1626 expires. 1628 The logic flow diagram below illustrates the Client's completion 1629 processing as it applies to a Closed or Open Limited group. 1631 from Delivery 1632 phase 1633 | 1634 V 1635 +-+-+-+-+-+-+-+ 1636 +--->| Send | 1637 | | Done msg. | 1638 | +-+-+-+-+-+-+-+ 1639 | | 1640 | V 1641 | +-+-+-+-+-+-+-+ +-+-+-+-+-+ 1642 | | Done | Yes | Idle | 1643 +-------->| confirmed? |----->| | 1644 | | +-+-+-+-+-+-+-+ +-+-+-+-+-+ 1645 | | |No ^ 1646 | | V | 1647 | | +-+-+-+-+-+-+-+ | 1648 | |Yes | Status Req. | | 1649 | +<---| received? | | 1650 | +-+-+-+-+-+-+-+ | 1651 | |No | 1652 | V | 1653 | +-+-+-+-+-+-+-+ +-+-+-+-+-+ 1654 | No |Receive timer| Yes | Send | 1655 +<--------| expired? |----->| Quit | 1656 +-+-+-+-+-+-+-+ +-+-+-+-+-+ 1658 Figure 11-5 Client Product Completion 1660 11.3.2 File Product Completion - Server 1662 For Closed and Open Limited groups, the receipt of a Done message from 1663 a Client means that the Client has received all of the file 1664 successfully. The Server confirms the receipt of Done messages with 1665 the Completion message. However, a separate message is not sent for 1666 each Done received. Rather, the Host List is used to "batch-confirm" 1667 all Done messages that have been received up to the time that the 1668 Completion message is sent. 1670 The first Completion message is sent as soon as the first Done message 1671 is received, and periodically thereafter at intervals specified by the 1672 Completion Interval parameter. When a Completion message is sent, the 1673 interval timer is started. When the timer expires, the Server updates 1674 the Host List of the message with all Clients that have sent Done 1675 messages and sends the message again. If all Clients have not yet 1676 completed, the timer is restarted. There must be at least one 1677 additional transmission of the Completion message after the last 1678 Client has completed. 1680 Since Clients will experience different network error rates, some 1681 Clients may complete the transfer while other Clients are still 1682 receiving retransmissions. This means that the Completion message may 1683 be sent while the file transfer is still in progress. 1685 Data delivery continues until there are no longer any participating 1686 Clients (all Clients have sent Done or Quit messages), there is no 1687 response from any Client, or until the Delivery Time Limit duration 1688 has expired, whichever occurs first. 1690 When the last Client completion has been confirmed with the Completion 1691 message, the Server considers the transfer complete and sends no 1692 further messages. 1694 If the Server receives no response to a Status Request sent at the end 1695 of a pass, there may no longer be any Clients listening to the Server. 1696 The Status Delay and Status Retry Count parameters limit the length of 1697 time that the Server will attempt to receive a response. When the 1698 Status Request message is sent, the Server starts the Status Delay 1699 timer. If any status responses have been received by the time the 1700 delay timer expires, the Server begins the next pass where it 1701 retransmits the DTUs specified in the responses. If no responses are 1702 received, the Server sends another Status Request message and restarts 1703 the delay timer. This procedure repeats up to the limit set by the 1704 Status Retry Count parameter, or the delivery time limit expires, 1705 whichever occurs first. At that time, the Server sends an Abort 1706 message, terminates the product delivery, and sends four End 1707 messages over the Public Address. End messages are read by 1708 aggregation devices, if present, to determine that the session is 1709 over. 1711 The Server may also use the Abort message to terminate transfer to one 1712 or more Clients at any time due to conditions at the Server or at the 1713 Client. Several Abort messages are sent to insure delivery as no 1714 response to the Abort message is required from the Clients. 1716 For Open Unlimited groups, the Clients do not send Done messages. The 1717 Server simply continues to send retransmissions as long as there are 1718 responses to the Status Request message. When there are no responses, 1719 the Server continues to send Status Request messages up to the Status 1720 Retry Limit (as discussed above) or the Delivery Time Limit expires. 1721 At that time, the Server sends a Completion message (with no Host 1722 List) and considers the transfer complete. There is no response from 1723 the Clients. 1725 For all group types, when the session is over the Server sends an End 1726 message on the same multicast address used for Announce. This message 1727 is sent four times and is used to conveniently notify infrastructure 1728 that may be aggregating that the session is ended. The End message 1729 structure is described in Section 12. 1731 11.4 Flow Control 1733 A first level of flow control may optionally be invoked to make sure 1734 particular parts of the network multicast tree do not become 1735 overloaded and bad receivers do not hold up transmission to the other 1736 members of the group. 1738 The Announce message may optionally contain an error rate threshold 1739 (Note that this should probably be mandatory when MFTP is used in 1740 large heterogeneous networks such as the Internet). This threshold is 1741 used to inform clients that if they measure a DTU loss over the 1742 threshold they abort themselves from the group. By leaving the group, 1743 that leaf of the multicast tree is dissolved, removing congestion in 1744 that part of the network. The Server may then be directed by the 1745 application to set up a new group of aborted clients and create a new 1746 session at a later time at a lower transmission rate to service those 1747 clients. 1749 12. Message Formats 1751 This section defines the format of all MFTP protocol messages. All 1752 messages begin with a common protocol header that is 12 bytes in 1753 length and includes the message type. Additional information, 1754 depending on message type, is included in the message payload area. 1755 The format of the common header is shown in Figure 12-1 below. 1757 0 32 1758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1759 | Protocol version | Message type | 1760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Common 1761 | Message length | Checksum | 1762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header 1763 | Transmission Identifier | 1764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1765 | Optional Parameters and Data | 1766 | |Payload 1767 ~ ~ Area 1768 | | 1769 | | 1770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1772 Figure 12-1 Protocol Header Format 1774 Each header field is an unsigned integer. The fields are described 1775 below. 1777 Protocol Version Number 1779 This field contains an integer that identifies the MFTP protocol 1780 version that is implemented by the sender of this message. This 1781 document describes version 1. 1783 Message Type 1785 This field identifies the MFTP message type, as defined in the 1786 following table. 1788 QUERY GROUP 0x0001 1789 JOIN GROUP 0x0002 1790 LEAVE GROUP 0x0003 1791 ANNOUNCE 0x0004 1792 DATA TRANSFER 0x0005 1793 STATUS REQUEST 0x0006 1794 NAK RESPONSE 0x0007 1795 COMPLETION 0x0008 1796 ABORT 0x0009 1797 REGISTRATION 0x000A 1798 DONE 0x000B 1799 QUIT 0x000C 1800 ECHO 0x000D 1801 ECHO RESPONSE 0x000E 1802 ACK RESPONSE 0x000F 1803 END 0x0011 1805 Message Length 1807 This field contains the length, in bytes, of the entire MFTP message, 1808 beginning with the Protocol Version field. 1810 Checksum 1812 This field contains a checksum that verifies the integrity of the 1813 entire message including the MFTP header. A checksum is computed by 1814 the sender of each message and placed into this field. The receiver 1815 also computes the checksum and compares it with the received value. If 1816 the values do not match, the received message is discarded and treated 1817 as if it were never received. 1819 The checksum is the 16 bit one's complement of the one's complement 1820 sum of all 16 bit words in the header and payload area. While 1821 computing the checksum, the checksum field itself is replaced with 1822 zeros. 1824 The use of this field is optional as the UDP checksum provided within 1825 UDP should be used for this function. If the UDP checksum is used, 1826 this field should be set to zero. 1828 Transmission Identifier 1830 This field contains a number that uniquely identifies this 1831 transmission. A receiver uniquely identifies messages associated with 1832 this transmission by examining the source IP address and this 1833 transmission identifier. The transmission identifier is not 1834 applicable in MCP and is set to zero in MCP messages. 1836 Payload 1838 The information contained in the payload section of each message is 1839 parameterized. This is done for several reasons. First, it facilitates 1840 the addition of new parameter types as the protocol evolves. Second, 1841 it allows for the omission of parameters that do not pertain to a 1842 particular product type. This is particularly important in the 1843 Announce message. 1845 All parameter data fields are a multiple of four bytes (i.e. 32 bits). 1846 When such a field is used to contain an integer, its format is as 1847 shown below. The integer is represented in two's complement notation. 1848 The most and least significant bytes are 0 and 3, respectively. 1850 MSB LSB 1851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1852 | Byte 0 | Byte 1 | Byte 2 | Byte 3 | 1853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1854 <--------------------------- 32 Bits ---------------------------> 1856 Figure 12-2 Basic Field Format 1858 The type-length-value structure is shown below. The minimum parameter 1859 unit length is 64 bits. The Name and Length fields both consist of 1860 two 16 bit fields. The value field is variable length, but is always 1861 a multiple of 32 bits. When the value field contains a character or 1862 octet string that is not a multiple of 32 bits, the field is extended 1863 so that the 32 bit multiple requirement is always met. This means that 1864 1, 2, or 3 pad bytes are added to the end of the string, and the value 1865 of those bytes is set to zero. However, the length field defines the 1866 true length of the value. 1868 |<------------ 32 bits -------->| Variable 1869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -+ 1870 | Type/length | Value | 1871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -+ 1873 Figure 12-3 Type-Length-Value Format 1875 Each item of data that is conveyed in the payload area of the message 1876 is identified as a separate message parameter and structured with the 1877 type-length-value format. Each parameter may be used in one or more 1878 message types. 1880 The following table defines the complete list of parameters and 1881 includes the parameter description, type, and length. 1883 Parameter | Type | Data Length 1884 --------------------------------------------------------------- 1885 Announce Duration 0x0100 4 1886 Announce Options 0x0101 4 1887 Application Reference 0x0102 variable(1-64) 1888 Block Number 0x0103 4 1889 Block Range 0x0104 8 1890 Block Size 0x0105 4 1891 Cancel Reason 0x0106 4 1892 Client Address 0x0107 4 1893 Data Rate 0x0108 4 1894 Data Transfer Duration 0x0109 4 1895 DTU Number 0x010A 4 1896 DTU Range 0x010B 8 1897 DTU Size 0x010C 4 1898 Echo Sequence 0x010D 4 1899 Echo Data 0x010E variable(1-4096) 1900 Error Threshold 0x010F 4 1901 Event Count 0x0110 4 1902 Event Hash 0x0111 16 1903 Event List 0x0112 variable 1904 Host List(complex) 0x0113 variable 1905 Host List(simple) 0x0114 variable 1906 Group Options 0x0115 4 1907 Multicast Address 0x0116 4 1908 Product Data 0x0117 variable 1909 Product Name 0x0118 variable (1-256) 1910 Product Size 0x0119 4 1911 Private Address 0x011A 4 1912 Public Address 0x011B 4 1913 Registration Response 0x011C 4 1914 Response Address 0x011D 4 1915 Response Port 0x011E 4 1916 Serial Number 0x011F 4 1917 Server Address 0x0120 4 1918 Server Port 0x0121 4 1919 Status Type 0x0122 4 1920 User Data 0x0123 variable (1-64) 1922 Figure 12-4 Message Parameters 1924 Each parameter is described in the message definition sections below 1925 so that their use is understood in the context of each message type. 1926 Parameters may be required, optional, or omitted depending on the 1927 message type and data product type. 1929 12.1 MCP Messages 1931 The MCP messages have been listed in the Protocol Description section 1932 above. The format of each message is described below. All messages 1933 begin with the common protocol header (see Protocol Header above). 1935 All subsequent fields are used to convey parameters to the receiving 1936 host, and use the type-length-value format. Each message description 1937 provides a list of the parameters included in that message type and 1938 whether each parameter is required or optional. The parameters may 1939 appear in the message in any order, not necessarily in the order 1940 presented in the list. 1942 12.1.1 Query Group Message 1944 The purpose of the Query Group message is to allow a Client to 1945 determine a Server's public address when only the Server's IP address 1946 is known. The message is sent in unicast mode to the Server. The 1947 response to this message is a Join Group message, also sent in unicast 1948 mode. A separate Join Group is returned for each public address active 1949 at the Server. If there are no public addresses active, then no 1950 response is sent by the Server. The Query Group message contains the 1951 following parameters. 1953 Application Reference String (Mandatory) 1954 Group Options (Mandatory) 1956 Application Reference String 1958 Given that there may be different (i.e. incompatible) application 1959 layer users of MFTP, this parameter serves to identify the application 1960 type operating at the Server and the Clients. 1962 The parameter is an ASCII character string that identifies the 1963 application type. For example, the StarBurst file transfer application 1964 uses the string "StarBurstMFTP". 1966 In a Client message, such as Query Group, the application running at 1967 the Client is identified. Hence, the Server responds to the message 1968 only when an application of the same type is running at the Server. In 1969 a Server message, such as Join Group (see below), this parameter 1970 identifies the application type that is running at the Server. The 1971 Client may then use the information to determine if it will respond to 1972 the Server message. That is, only Clients that have the same type 1973 application layer users should respond to the message. 1975 Group Options 1977 This parameter defines various options associated with group 1978 management and is contained in both the Group Query and Join Group 1979 messages. The parameter is a combination bit and byte field, as 1980 defined below: 1982 Byte Bit Setting 1983 PRODUCT TYPE 1984 0 0-7 'F' = file product 1985 'A' = all product types 1986 COMMON OPTIONS 1987 1 0-7 Unused, set to zero 1988 2 0-7 Unused, set to zero 1989 3 0-7 Unused, set to zero 1991 Each option is explained below: 1993 Product Type This option identifies the product type(s) that a 1994 Client wants to receive (as used in Query Group 1995 message) or that a Server is transmitting(as used 1996 in Join Group message). Only file product is now 1997 defined. 1999 Common Options None currently defined. 2001 12.1.2 Join Group Message 2003 This message may be sent as a response to the Query Group message (see 2004 above), or as an unsolicited message to one or more Clients. In the 2005 former case, it provides the Server's public multicast address to the 2006 Client so that the Client may join the group to receive product 2007 announcements. In the latter case, it may specify the public address, 2008 or any other multicast address that the Server wants the Client(s) to 2009 join. When sent as a response to the Query Group message, it is sent 2010 in unicast mode. Otherwise, the message may be sent in unicast, 2011 broadcast, or multicast modes. The message contains the following 2012 parameters. 2014 Application Reference (mandatory) 2015 Multicast Address (mandatory) 2016 Group Options (mandatory) 2017 Host List (simple) (optional) 2019 Application Reference String 2021 Refer to the Query Group message for a description of this parameter. 2022 The Client joins the indicated group only if the Client has an 2023 application user of the same type indicated in the message. 2025 Multicast Address 2027 This parameter contains the multicast address that the receiving host 2028 should join. Normally, this will be the Server's public address, but 2029 may be any multicast address that the Server wants the Client(s) to 2030 join. 2032 Group Options 2034 Refer to the Query Group message for a description of this parameter. 2036 The Server sets the Product Type field of this parameter to identify 2037 the type of data products that may be received by joining the 2038 indicated public multicast address. 2040 Host List (simple) 2042 This parameter is included when the sender wants to specify specific 2043 hosts that should act on the message. If the message is to apply to 2044 all receiving hosts, this parameter is omitted. 2046 This parameter is an array of host records. Each host record in the 2047 array consists of a single 32 bit field, called the host identifier. 2048 Each host identifier contains the IP address of a host. The address is 2049 stored in network byte order. 2051 There are other messages that may contain the Host List parameter 2052 (e.g. Announce, Abort). Whenever the length of the Host List does not 2053 fit within a single message, the Host List is divided and sent in two 2054 or more copies of the same message type. The multiple messages are 2055 considered a single logical message by the Server. 2057 12.1.3 Leave Group Message 2059 The purpose of the Leave Group message is to direct one or more remote 2060 hosts to leave a multicast group. The message may be sent in unicast, 2061 broadcast, or multicast modes. The message contains the following 2062 parameters. 2064 Multicast Address (mandatory) 2065 Host List(simple) (optional) 2067 Multicast Address 2069 This parameter specifies the multicast group that the Client(s) should 2070 leave. 2072 Host List (simple) 2074 Refer to the Join Group message for a description of this parameter. 2076 12.1.4 Echo Message 2078 The Echo message may be transmitted by any MFTP station. The purpose 2079 of the message is to test the network path, and the reliable transfer 2080 of data over that path, between the source and destination hosts. The 2081 response to this message is the Echo Response message (see next 2082 section). This message is similar in concept to the Echo message of 2083 the Internet Control Message Protocol (RFC792). This message may be 2084 sent in unicast, broadcast, or multicast modes. The message contains 2085 the following parameters. 2087 Echo Sequence (mandatory) 2088 Echo Data (optional) 2089 Host List(simple) (optional) 2091 Echo Sequence 2093 This parameter is a sequence number to aid in matching a response with 2094 a transmitted message. 2096 Echo Data 2098 This optional parameter is an octet string that can be sent with the 2099 Echo message and is returned in the Echo Response message. 2101 Host List (simple) 2103 Refer to the Join Group message for a description of this parameter. 2105 12.1.5 Echo Response Message 2107 The Echo Response message may be transmitted by either a Server or 2108 Client, as a response to a received Echo message. This message is sent 2109 in unicast mode always. 2111 All parameters received in the Echo message, except the host list, are 2112 echoed back to the sender exactly as received. The host list, if 2113 contained in the Echo message, is omitted from the response. Refer to 2114 the Echo Message above. 2116 12.2 MDP Messages 2118 The MDP messages have been listed in the Protocol Description section 2119 described previously. The format of each message is described below. 2120 All messages begin with the common protocol header (see Protocol 2121 Header, Figure 12-1). All subsequent fields are used to convey 2122 parameters to the receiving host, and use the type-name-length-value 2123 format. Each message description provides a list of the parameters 2124 included in that message type and whether each parameter is required 2125 or optional. 2127 Unless otherwise stated, the parameters in messages sent by the Server 2128 may appear in the message in any order, not necessarily in the order 2129 presented in the list. To allow efficiency in aggregating response 2130 messages (when used), most response formats specify that the 2131 parameters must be in the order shown. 2133 12.2.1 Announce Message 2135 The Announce message is sent only by the Server. The purpose of the 2136 message is to allow the Server to announce the impending transmission 2137 of a data product, to describe the data product, and to solicit 2138 Registration message responses from Clients (depending on group type). 2139 The Announce message may be sent in unicast, broadcast, or multicast 2140 mode. In multicast mode, it is sent to the Public address. 2142 The Announce message contains the parameters listed below. An 2143 intermediate network entity that is performing response aggregation 2144 may need to monitor Announce messages in order to obtain parameters 2145 that are needed for aggregation processing, such as the Response 2146 Address. Therefore, the first five parameters (Server Address/Port, 2147 Response Address/Port, and Private Address) must appear at the 2148 beginning of the message payload area and in the order shown. Other 2149 parameters may appear in any order. 2151 Server Address (mandatory) 2152 Server Port (mandatory) 2153 Response Address (mandatory) 2154 Response Port (mandatory) 2155 Private Address (mandatory) 2156 Announce Duration (mandatory) 2157 Announce Options (mandatory) 2158 Application Reference (mandatory) 2159 Block Size (mandatory) 2160 Data Rate (mandatory) 2161 Product Name (mandatory) 2162 Data Transfer Duration (mandatory) 2163 DTU Size (mandatory) 2164 Product Size (mandatory) 2165 Error Threshold (optional) 2166 User Data (optional) 2167 Host List (complex) (optional) 2169 Server Address 2171 This parameter is the IP address, in network byte order, of the 2172 Server. Its purpose is primarily for response aggregation. This 2173 parameter is copied to the response by the Client so that the 2174 aggregating entity knows where to send the aggregated response. 2176 Server Port 2178 This parameter is the receive UDP port number of the Server. Its 2179 purpose is primarily for response aggregation. This parameter is 2180 copied to the response by the Client so that the aggregating entity 2181 knows where to send the aggregated response. 2183 Response Address 2185 This parameter is the address to which Client response messages are to 2186 be sent. This allows responses to be sent to or intercepted by an 2187 intermediate aggregating entity. The address may be a unicast or 2188 multicast address, in network byte order. If response aggregation is 2189 not being performed, this address is the host IP address of the 2190 Server. 2192 Response Port 2194 This parameter is the receive UDP port at the Response Address to 2195 which Client response messages are to be sent. 2197 Private Address 2199 This parameter specifies the network address to which the Server will 2200 transmit the product data. For a multicast transmission, this is a 2201 multicast group address. The Client must join the multicast group to 2202 receive the product data. Otherwise, this parameter specifies a 2203 unicast or broadcast address. 2205 Announce Duration 2207 This parameter is the time, in seconds, remaining before the product 2208 data transmission will begin. It is updated at each Announce message 2209 transmission so that it accurately reflects the remaining time. The 2210 Client does not act on this information. It is provided primarily as 2211 an item of information to the application layer user. The initial 2212 value of this parameter is provided by the Announce Time Limit 2213 configuration parameter (see Configuration above). 2215 Announce Options 2217 This parameter defines various options associated with a product 2218 transmission. The parameter is a combination bit and byte field, as 2219 defined below: 2221 Byte Bit Setting 2222 PRODUCT TYPE 2223 0 0-7 'F' = file product 2224 COMMON OPTIONS 2225 1 0-1 01 = closed group 2226 10 = open limited group 2227 11 = open unlimited group 2228 2 1 = do not leave delivery group 2229 0 = leave delivery group 2230 3-7 Unused, set to zero 2231 FILE OPTIONS 2232 2 0 1 = initial transmission 2233 0 = restart transmission 2234 1 1 = overwrite existing file 2235 0 = preserve existing file 2236 2 1 = late entry allowed 2237 0 = late entry disallowed 2238 3-7 Unused, set to zero 2240 Each option is explained below: 2242 Product Type This option identifies the product type. Only 2243 file product is currently defined. 2245 Common Option 1 This group option defines whether the product 2246 (bit 0-1) may be received by any Client, or only by those 2247 specified in the Host List parameter (refer to 2248 the Group Management section above) 2250 Common Option 2 This option specifies whether the Client should 2251 (bit 2) or should not leave the data delivery group 2252 after the product delivery has completed. If 2253 the Server intends to send more than one 2254 product to the same Client group, then group 2255 setup time can be minimized by keeping Clients 2256 joined to the group. Since this option is 2257 contained in each product announcement, the 2258 final product announcement can direct Clients 2259 to leave the group after the transmission has 2260 completed. 2262 File Option 1 The initial/restart option indicates whether 2263 this is an initial transmission of the file 2264 (i.e. the entire file will be sent) or whether 2265 it is a restart of a file previously sent but 2266 not received completely by all Clients. 2268 File Option 2 The overwrite/preserve option indicates whether 2269 a Client should overwrite or preserve a current 2270 file that has the same name as specified in the 2271 Product Name parameter (see above). If this 2272 option is set to overwrite, then the Client is 2273 allowed to receive the new file and overwrite 2274 the old file. If this option is set to 2275 preserve, then the Client declines to receive 2276 the new file and preserves the existing file at 2277 the host. 2279 File Option 3 The late entry option defines whether a Client 2280 may participate in a file restart if it has not 2281 yet received any of the file. Since the file 2282 will have to be entirely transmitted for the 2283 Client, it will slow down other Clients that 2284 may need only a small portion of the file to 2285 complete their receipt of it. However, it does 2286 allow the Server to transmit the file to 2287 Clients that may have been offline when the 2288 file was originally sent. If the option is set 2289 to allowed, then a Client that has not yet 2290 received any of the file may participate in the 2291 file transfer. If the option is set to 2292 disallowed, then only Clients that have 2293 previously received some portion of the file 2294 may participate. 2296 Application Reference String 2298 Refer to the Join Group message for a description of this parameter. 2299 The Client will not respond to this message unless its application 2300 type matches this value. 2302 Block Size 2304 This parameter is the number of DTUs that will be transmitted in each 2305 block. It allows the Client to initialize and manage its memory 2306 resources used for tracking DTUs that have been received or missed. If 2307 the product is a file, this value is limited by the maximum size of 2308 the bit map form of the Event List that can be carried in a Status 2309 Response message (see Event List below). 2311 Data Rate 2313 This parameter specifies the Server's transmit data rate. The Client 2314 may use this information to decide whether it can successfully 2315 participate in the product transfer. That is, the Client might decline 2316 a product transfer if it knows that the data rate will overrun the 2317 Client. 2319 Data Transfer Duration 2321 This parameter specifies the maximum amount of time, in seconds, that 2322 the Server will devote to the product delivery (not including the 2323 product announcement phase). The Client uses this value as its receive 2324 timeout. This parameter is configured (see Configuration section 2325 above). 2327 DTU Size 2329 This parameter is the maximum number of data bytes that will be 2330 contained in each DTU for a file transfer. The last DTU may contain 2331 less than this number of bytes. This value is computed by MFTP based 2332 on the size of the network Maximum Transmission Unit, the lower level 2333 protocol headers, and the other parameters that must reside in a DTU. 2335 Error Threshold 2337 This parameter defines the percentage of missed DTUs, relative to the 2338 total number of DTUs in the transmission, that can occur at a Client 2339 before the Client voluntarily removes itself from participation in the 2340 product transfer. That is, the Client monitors its own error rate and 2341 initiates its own removal from the transfer if this threshold is 2342 reached. This mechanism helps to prevent a small number of Clients 2343 with high error rates from adversely affecting all other Clients by 2344 requesting a high percentage of retransmissions. It is permissible for 2345 the Client to continue to receive and process DTUs in anticipation of 2346 a file restart, but the Client must not send any message to the 2347 Server. 2349 Product Name 2351 This parameter is an ASCII character string that is the formal name 2352 for the product being announced. If the product is a file, this field 2353 contains the name of the file that should be created on the Client 2354 system to store the product (the filename may be different than the 2355 filename at the Server). 2357 Product Size 2359 This parameter is the total length, in bytes, of a file product. It 2360 allows the Client to determine if there is sufficient disk space to 2361 receive and store the product. 2363 User Data 2365 This parameter is an octet string that is provided by the application 2366 layer user. It is delivered to the application layer user at the 2367 Client. It could be used, for example, to describe the product being 2368 announced. Its use is optional and is limited to 64 octets. 2370 Host List (complex) 2372 This parameter is an array of host records. Each host record in the 2373 array consists of two 32 bit fields. The first field, called the host 2374 identifier, contains the IP address of the remote host, in network 2375 byte order. The second field, called the admin status, contains the 2376 status of the host specified in host identifier field. The format of 2377 the admin status field is defined below. 2379 Byte Bit Setting 2380 0 0-7 'A' = accepted to receive 2381 product 2382 'D' = declined status confirmed 2383 'P' = pending status 2384 1 0-7 Decline reason 2385 2 0-7 Unused, set to zero 2386 3 0-7 Unused, set to zero 2388 The usage of the Host List depends on Group type being used (also see 2389 Group Management, Section 6). For Closed Groups, the Host List is 2390 included in the message and contains the IP address of each Client 2391 that is being invited to participate in the product transfer. The 2392 Admin status is initially set to 'P'. As Clients send Registration 2393 messages, the Server acknowledges receipt of the message by setting 2394 the Admin status in the next Announce message that is transmitted. 2395 When an invited Client indicates that it will be participating in the 2396 product transfer, its Admin status is set to 'A' (accepted). When an 2397 invited Client indicates that it is declining the product, its Admin 2398 status is set to 'D' (declined) and the Decline Reason field is set to 2399 the value received in the Registration message. If an uninvited Client 2400 sends a Registration message for a Closed Group announcement, the 2401 Server simply ignores the registration and sends an Abort to the 2402 client. 2404 For Open Limited Groups, the Host List is initially omitted from the 2405 Announce message. As Clients begin to send Registration messages, the 2406 Server includes the Host List in subsequent Announce messages and adds 2407 an entry for each Client that is accepted to participate in the 2408 product delivery, and the Admin status is set to 'A'. If a host is 2409 rejected by the Server (e.g. the maximum number of hosts that the 2410 Server can handle is reached), its registration is simply ignored and 2411 an entry is not placed in the Announce message. The Host List is never 2412 included for Open Unlimited Groups. 2414 12.2.2 Registration Message 2416 The Registration message is sent only by the Client in order to 2417 respond to a received Announce message. The Registration message is 2418 sent to the Response Address contained in the Announce message. The 2419 message contains the following parameters, which must appear in the 2420 order shown. 2422 Server Address (mandatory) 2423 Server Port (mandatory) 2424 Client Address (mandatory) 2425 Registration Response (mandatory) 2427 This response may be aggregated and relayed by an intermediate entity 2428 to increase scalability. A single response that is not relayed 2429 contains only the parameters shown. A relayed response repeats the 2430 Client Address, Serial Number, and Registration Response parameters 2431 for each Client that is being relayed. 2433 Server Address 2435 This field is echoed by the Client, exactly as received in the 2436 Announce message. It may be used by an intermediate network entity 2437 during the aggregation/relaying process. 2439 Server Port 2441 This field is echoed by the Client, exactly as received in the 2442 Announce message. It may be used by an intermediate network entity 2443 during the aggregation/relaying process. 2445 Client Address 2447 This field identifies the Client that is sending the response, and 2448 identifies individual Clients in an aggregated/relayed response. The 2449 address is in network byte order. 2451 Registration Response 2453 This parameter indicates the Client's intention to participate or not 2454 participate in the transmission of a product announced by a Server. If 2455 the Client accepts the offer to participate in the transmission, the 2456 reason for decline field has no meaning and is set to the value zero. 2457 This parameter is a byte array with the following definition. Refer to 2458 Section 13 for a list of the decline reasons. 2460 Byte Bit Setting 2461 0 0-7 'A' = accept 2462 'D' = decline 2463 1 0-7 Decline reason 2464 2 0-7 Unused, set to zero 2465 3 0-7 Unused, set to zero 2467 12.2.3 Data Transfer Message 2469 The Data Transfer message is transmitted only by the Server in order 2470 to transfer the data product to the Clients. There is no response by 2471 the Client to this message. This message may be sent in unicast, 2472 broadcast, or multicast mode. In multicast mode, this message is sent 2473 to the Private address. The message contains the following parameters. 2475 Pass Number (mandatory) 2476 Block Number (mandatory) 2477 DTU Number (mandatory) 2478 Product Data (mandatory) 2480 Pass Number 2482 This parameter contains the current pass number. The first pass is 2483 numbered 1, and increments for each additional pass. This parameter 2484 allows the Client to unambiguously determine the current pass number. 2485 This is primarily useful for reporting reception status to an 2486 application layer user. 2488 Block Number 2490 This parameter contains the sequence number of the current block, 2491 within the current pass, starting at 1. 2493 DTU Number 2495 This parameter contains the sequence number of the current DTU, within 2496 the current block, starting at 1. 2498 Product Data 2500 This parameter is the actual file data bytes being delivered to the 2501 Client. 2503 12.2.4 Status Request Message 2505 The Status Request message is sent only by the Server in order to 2506 query the Client for its reception status. The Client responds with an 2507 ACK or NAK Response message, depending on the type of status requested 2508 (only NAKs are normally used). The Status Request message may be sent 2509 in unicast, broadcast, or multicast mode. In multicast mode, it is 2510 sent to the Private address. The message contains the following 2511 parameters. 2513 Pass Number (mandatory) 2514 Block Range (mandatory) 2515 DTU Range (mandatory) 2516 Status Type (mandatory) 2517 Host List (simple) (optional) 2519 Pass Number 2521 This parameter identifies the pass for which the Server is requesting 2522 status. If there is no applicable pass number (e.g. the Server is 2523 querying for status prior to a file restart), then this parameter 2524 value is set to zero. 2526 Block Range 2528 This parameter identifies the range of blocks for which the Server is 2529 requesting status. The parameter consists of two 32-bit fields. The 2530 first field contains the number of the first block in the range, and 2531 the second field contains the number of the last block in the range. 2532 If status is being requested for a single block, both fields are set 2533 to the same block number. 2535 DTU Range 2537 This parameter identifies the range of DTUs within a block for which 2538 the Server is requesting status. The parameter consists of two 32-bit 2539 fields. The first field contains the number of the first DTU in the 2540 range, and the second field contains the number of the last DTU in the 2541 range. The range cannot span multiple blocks. If status is being 2542 requested for a single block, then this parameter may specify a subset 2543 of all DTUs in the block. When status for multiple blocks is being 2544 requested, this parameter is set to the first and last DTU numbers of 2545 the entire block. That is, a DTU subset request is invalid when the 2546 Server is requesting status for multiple blocks. 2548 Status Type 2550 This parameter is an integer that identifies the type of status 2551 response that is being requested by the Server. The values are shown 2552 below: 2554 1 = NAK responses only - The Client responds only if it recognizes 2555 that it has not received one or more DTUs 2556 in the block(s) specified by the Server. 2557 It sends a NAK response message. 2558 Otherwise, it sends no response at all. 2559 This is the preferred mode of operation. 2560 2 = ALL responses - The Client always responds regardless of 2561 its reception status. If it has received 2562 all DTUs in the indicated block, it sends 2563 an ACK response message. Otherwise, it 2564 sends a NAK response message. 2566 Host List (simple) 2568 Refer to the Join Group message for a description of this parameter. 2569 It is included when the sender wants to specify Clients that should 2570 respond to the message. If the message is to apply to all receiving 2571 Clients, this parameter is omitted. 2573 12.2.5 NAK Response Message 2575 The NAK Response message is sent only by the Client when queried by 2576 the Server via the Status Request message. The Client sends this 2577 response if the Status Request message specifies either the ALL or NAK 2578 response status type and the Client needs to request the 2579 retransmission of one or more DTUs in the indicated block. The NAK 2580 Response message is sent to the Response Address as specified in the 2581 Announce message. The response message contains the following 2582 parameters, which must appear in the order shown. 2584 Server Address (mandatory) 2585 Server Port (mandatory) 2586 Client Address (mandatory) 2587 Pass Number (mandatory) 2588 Block Number (mandatory) 2589 Event Count (mandatory) 2590 Event Hash (mandatory) 2591 Event List (mandatory) 2593 Server Address 2595 This field is echoed by the Client, exactly as received in the 2596 Announce message. 2598 Server Port 2600 This field is echoed by the Client, exactly as received in the 2601 Announce message. 2603 Client Address 2605 This field identifies the Client that is sending the response. The 2606 address is in network byte order. 2608 Pass Number 2610 This parameter is as specified for the Status Request message above. 2611 That is, the received value is echoed in the response message. 2613 Block Number 2615 The value of this parameter is set to the block number that is being 2616 reported. If the Server requests status for a single block, then this 2617 parameter contains the same number. If the Server requests status for 2618 a range of blocks, then a separate response message is returned for 2619 each block in the range and this parameter is set to the block number 2620 that is being reported in each message. 2622 Event Count 2624 This parameter indicates the total number of NAKed DTUs that are being 2625 reported in this message. In other words, this is the number of bits 2626 that are set in the Event List parameter. 2628 Event Hash 2630 This parameter is the result of a hash function being applied to the 2631 Event List parameter. The purpose is for the receiver to be able to 2632 easily determine if the Event List for any two or more Clients is 2633 identical. The MD4 hash function (RFC 1320) is used. This is useful 2634 for aggregation/relaying, when used. 2636 Event List 2638 This parameter identifies the DTUs that the Client has not received 2639 for the block in the Block Number field. It is a bit map, where each 2640 bit in the map represents a single DTU in the block. A bit set to '1' 2641 means that the DTU has not been received and a bit set to '0' means 2642 the DTU has been successfully received by the Client. Note that the 2643 Server may request the status for a subset of the DTUs in a block via 2644 the DTU Range parameter in the Status Request message. The Client 2645 still sends a complete bit map, but sets the bits for all DTUs outside 2646 the range to '0' (successfully received). Also note that the DTU Range 2647 parameter is not echoed in the response message. 2649 12.2.6 ACK Response Message 2651 The ACK Response message is sent only by the Client when queried by 2652 the Server via the Status Request message. The Client sends this 2653 response if the Status Request message specifies the ALL response 2654 status type and the Client has successfully received all of the DTUs 2655 in the indicated block (Note that this is not the preferred mode of 2656 operation). The ACK Response message is sent to the Response Address 2657 as specified in the Announce message. The response message contains 2658 the following parameters, which must appear in the order shown. 2660 Server Address (mandatory) 2661 Server Port (mandatory) 2662 Pass Number (mandatory) 2663 Block Range (mandatory) 2664 Client Address (mandatory) 2666 Server Address 2668 This field is echoed by the Client, exactly as received in the 2669 Announce message. 2671 Server Port 2673 This field is echoed by the Client, exactly as received in the 2674 Announce message. 2676 Pass Number 2678 This parameter is as specified for the Status Request message above, 2679 i.e. the received value is echoed in the response message. 2681 Block Range 2683 This parameter identifies the range of blocks for which the Client is 2684 reporting ACK status. The parameter consists of two 32-bit fields. The 2685 first field contains the number of the first block in the range, and 2686 the second field contains the number of the last block in the range. 2687 If status is being reported for a single block, both fields are set to 2688 the same block number. 2690 Note that the Server may request the status of a range of blocks, and 2691 the Client may return both ACK and NAK responses, according to the 2692 status of each block. While NAK responses are sent individually for 2693 each block being reported by the Client, the ACK response may report 2694 the successful reception of a range of blocks. 2696 Client Address 2698 This field identifies the Client that is sending the response, and 2699 identifies individual Clients in an aggregated response. The address 2700 is in network byte order. 2702 12.2.7 Done Message 2704 The Done message is sent only by the Client to the Server to indicate 2705 that a complete product has been received successfully. The message is 2706 sent to the Response Address as specified in the Announce message. The 2707 message contains the following parameters, which must appear in the 2708 order shown. 2710 Server Address (mandatory) 2711 Server Port (mandatory) 2712 Client Address (mandatory) 2713 Event Count (mandatory) 2714 Data Transfer Duration (mandatory) 2716 Server Address 2718 This field is echoed by the Client, exactly as received in the 2719 Announce message. 2721 Server Port 2723 This field is echoed by the Client, exactly as received in the 2724 Announce message. 2726 Client Address 2728 This field identifies the Client that is sending the response. The 2729 address is in network byte order. 2731 Event Count 2733 This parameter reports the total number of DTUs that the Client 2734 reported as missed during reception of the product. In other words, 2735 the field contains the total of all DTUs reported in NAK Response 2736 messages sent to the Server during reception of the product. 2738 Data Transfer Duration 2740 This parameter reports the actual time, in seconds, that was required 2741 for the Client to receive the product. 2743 12.2.8 Completion Message 2745 The Completion message is sent only by the Server in order to confirm 2746 receipt of Done messages from Clients. When Clients are not sending 2747 Done messages (i.e. Open-unlimited groups), the message announces the 2748 end of a transmission. This message may be sent in unicast, broadcast, 2749 or multicast mode. In multicast mode, this message is sent to the 2750 Private address. The message contains the following parameter. 2752 Host List (simple) (optional) 2754 Host List 2756 This parameter is included only when the Clients are sending Done 2757 messages. The inclusion of a Client address in the list confirms 2758 receipt of the Client's Done message. 2760 12.2.9 Abort Message 2762 The Abort message is sent only by the Server in order to cancel a 2763 product announcement or product delivery that is currently in progress 2764 or to abort a specific Client or Clients. There is no response to 2765 this message by the Client, so multiple Abort messages should be sent 2766 to increase the probability of success. The message may be sent in 2767 unicast, broadcast, or multicast mode. In multicast mode, the message 2768 is sent to the Private address. The message contains the following 2769 parameters. 2771 Cancel Reason (mandatory) 2772 Host List (simple) (optional) 2774 Cancel Reason 2776 This parameter indicates the reason that the Server is aborting a 2777 product transmission. Refer to Section 13 for the value list. 2779 Host List (simple) 2781 Refer to the Join Group message for a description of this parameter. 2782 This parameter is included when the Server wants to Abort a subset 2783 of the Client population. If the parameter is omitted, then all 2784 receiving Clients are affected. 2786 12.2.10 Quit Message 2788 The Quit message is sent only by the Client in order to terminate its 2789 participation in the current product transfer. There is no response to 2790 this message by the Server, so multiple messages should be sent to 2791 increase the probability of success. The message is sent to the 2792 Response Address as specified in the Announce message. It includes the 2793 following parameters. 2795 Cancel Reason (mandatory) 2797 Cancel Reason 2799 This parameter indicates the reason that a Client is terminating 2800 reception of a product transmission. Refer to Section 11 for the 2801 value list. 2803 12.2.11 End Message 2805 The End message is sent only by the Server in order to conveniently 2806 indicate to aggregating entities in the network, if present, that the 2807 session is over. End messages are sent four times after the Server 2808 has determined the session is over on the Public Address. There are no 2809 response messages back to the End message. 2811 The End message includes the following parameters. 2813 Server Address (mandatory) 2814 Server Port (mandatory) 2815 Response Address (mandatory) 2816 Response Port (mandatory) 2818 13.Reason Codes 2820 The various "reason" codes used in PDUs are listed below. Refer to 2821 previous sections for a description of the message types and 2822 configuration parameters mentioned here. 2824 Client Registration Message - decline reasons 2826 1001 insufficient disk space 2827 1002 insufficient memory 2828 1003 system error (disk, I/O, etc) 2829 1004 already have file. The Server has indicated in the Announce 2830 message that the Client should preserve any existing copy of 2831 the file. Therefore, the Client is confirming that it already 2832 has the file and will not be participating in the current 2833 transfer. Refer to the overwrite/preserve file option in the 2834 Announce message. 2835 1005 no file to restart. The Server has indicated that this is a 2836 file restart. However, the Client does not currently have any 2837 portion of the file and the sender wants to restrict the 2838 transfer to only those Clients that already have a portion of 2839 the file. Refer to the initial/restart and late entry file 2840 options in the Announce message. 2841 1006 unknown application type (ARS). The Announce message specifies 2842 an ARS that does not match the ARS set by the application 2843 layer user. Refer to the Application Reference String 2844 parameter in the Announce message. 2845 1007 no interest in sender. The application layer user has not 2846 specified this Server as one of the Servers that it wishes to 2847 receive data products from. 2848 1008 no interest in product type. The application layer user has 2849 not specified this product type as one of the types that it 2850 wishes to receive. Currently, only file product is supported 2851 but this provides expansion capability for the future. Refer 2852 to the product type specification in the Announce message. 2854 Client Quit Message - cancel reasons 2856 2001 application action. The user application has terminated 2857 this product transfer 2858 2002 transfer timeout. The maximum time duration specified for the 2859 transfer of this product has expired. Refer to the Data 2860 Transfer Duration parameter in the Announce message. 2861 2003 system error. An unrecoverable host error has occurred. 2862 2004 error threshold. The error threshold has been reached for this 2863 Client. Refer to the Error Threshold parameter in the Announce 2864 message. 2866 Server Abort Message - cancel reasons 2868 3001 application action. The user application has terminated this 2869 product transfer. 2870 3002 transfer timeout. The maximum time duration specified for the 2871 transfer of this product has expired. Refer to the Delivery 2872 Time Limit configuration parameter. 2873 3003 status timeout. The maximum time duration specified for status 2874 acquisition has expired. Refer to the Status Retry Timer and 2875 Status Retry Count configuration parameters. 2876 3004 system error. An unrecoverable host error has occurred. 2878 14. Future Extensions 2880 Work is ongoing to provide improvements to the basic MFTP protocol. 2881 Some of the improvements under consideration are: 2883 1. More comprehensive flow control. As currently defined, MFTP 2884 handles flow control simply by having client receivers with 2885 excessive DTU error rates (excessive as defined by the server) 2886 remove themselves from the group. 2887 2. More generalized host lists. Currently, host lists include 2888 the IP addresses of the hosts included in the list. It has 2889 been suggested that the host lists contain the host names 2890 rather than the IP address; however, these will occupy larger 2891 fields than the 32 bit address field. 2892 3. Addition of Security (see Section 15). 2893 4. Interfaces to the mmusic protocols. 2894 5. Interfacing to RSVP. 2896 15. Security Considerations 2898 This version of the protocol does not include any distinct message 2899 types or additional fields for existing messages that will be needed 2900 to support security. Security is currently under study and the 2901 specification will be updated at a future time to address the security 2902 requirements based on the work performed in the IPSEC IETF Working 2903 Group. 2905 16. Acknowledgments 2907 The authors would like to thank Scott Bradner (Harvard University), 2908 Ken Cates (StarBurst Communications), and Tony Speakman (Cisco 2909 Systems) for their comments and suggestions on various aspects of 2910 this document. 2912 References 2914 [1] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, 2915 August 1989. 2917 [2] Postel, J., Reynolds, J. "File Transfer Protocol (FTP)", RFC 2918 959, October 1985. 2920 [3] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., 2921 "RTP: A Transport Protocol for Real-Time Applications", RFC 2922 1889, January 1996. 2924 [4] Schulzrinne, H.,"RTP Profile on Audio and Video Conferences 2925 with Minimal Control", RFC 1890, January 1996. 2927 Author's Addresses 2929 Kenneth Miller Phone: +1 (508) 287-5560 2930 StarBurst Communications, Inc. Email: miller@starburstcom.com 2931 150 Baker Ave. 2932 Concord, MA 01742 2934 Kary Robertson Phone: +1 (508) 287-5560 2935 StarBurst Communications, Inc. Email: krobertson@starburstcom.com 2936 150 Baker Ave. 2937 Concord, MA 01742 2939 Alex Tweedly Phone: +1 (408) 526-8114 2940 Cisco Systems, Inc. Email: agt@cisco.com 2941 170 West Tasman Drive 2942 San Jose, CA 95134 2944 Marc White Phone: +1 (508) 287-5560 2945 StarBurst Communications, Inc. Email: mwhite@starburstcom.com 2946 150 Baker Ave. 2947 Concord, MA 01742