RMT Working Group T. Richon Internet Draft G. Chanteau Document: draft-richon-vfdp-protocol-00.txt G. Babonneau Expires: July 2002 France Telecom R&D 6 December, 2001 Versatile File Delivery Protocol, a Nack-based reliable multicast file transfer Protocol Instantiation Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. 2. Abstract The aim of the Versatile File Delivery Protocol is to deliver files from few octets up to few hundred gigaoctets over multicast networks. It works over UDP and uses IP multicast addresses. VFDP transmissions have been designed to be as reliable as possible according to various and strong network constraints, either by retransmitting the whole file or by sending only the missing packets depending of a return channel existence. In the latter case, the Thomas Richon Draft - Expires July 2002 [Page 1/32] Internet Draft Versatile File Delivery Protocol July 2002 receiver's feedback requires particular precautions. For instance, asymmetric networks based on an multicast satellite link can reach without any difficulties a very important number of users (up to several millions). Therefore it is necessary to define efficient means to aggregate packets sent by receivers to the source in order to avoid network congestion and requests implosion. Through this draft, VFDP authors tried to bring few answers. 3. Table of Contents 1. Copyright Notice................................................1 2. Abstract........................................................1 3. Table of Contents...............................................2 4. Overview........................................................3 5. Terminology.....................................................4 6. Conventions used in this document...............................4 7. Applicability Statement.........................................5 7.1. Target application space.....................................5 7.2. Target scale.................................................5 7.3. Intended environment.........................................5 7.4. Weaknesses and known failure modes...........................5 7.5. Compliance with building block applicability statements......5 7.5.1. NACK-based Reliability....................................6 7.5.2. FEC coding................................................6 7.5.3. Congestion control........................................6 7.5.4. Tree configuration........................................6 7.5.5. Data security.............................................6 8. Protocol Definitions............................................6 8.1. Multicast channel............................................6 8.2. Sender node..................................................6 8.3. Receiver node................................................7 8.4. Aggregator node..............................................7 8.5. Session......................................................8 8.6. Data segment................................................10 8.7. Segment losses..............................................10 8.8. Selective addressing issues.................................10 8.8.1. Recipients list..........................................10 8.8.2. Recommended solution.....................................11 9. Protocol Mechanisms............................................13 9.1. Operational overview........................................13 9.2. Send & Receive mechanism....................................13 9.3. Late-join mechanism.........................................14 9.4. Overlapping transmissions mechanism.........................15 9.5. Abort mechanism.............................................16 9.6. Suspend & Resume mechanism..................................16 9.7. Negative acknowledgement mechanism..........................17 Thomas Richon Draft - Expires July 2002 [Page 2/32 Internet Draft Versatile File Delivery Protocol July 2002 9.8. Multicast Nack suppression mechanism........................18 9.9. Completion mechanism........................................18 9.10. Aggregation mechanism......................................19 9.11. Additional Protocol Mechanisms.............................20 9.11.1. Group status request....................................20 9.11.2. Dynamic group registration session......................20 10. Detailed nodes functions......................................20 10.1. Sender node................................................20 10.2. Receiver node..............................................20 10.3. Aggregator node............................................20 11. Packet Formats................................................20 11.1. Overview...................................................20 11.1.1. VFDP_ANNOUNCE...........................................20 11.1.2. VFDP_TRANSPORT..........................................21 11.1.3. VFDP_REQUEST............................................21 11.1.4. VFDP_RESULT.............................................22 11.2. Common Header..............................................22 11.3. Packets description........................................23 11.4. IPv6 message parts.........................................31 11.5. IPSEC support..............................................31 12. References....................................................31 13. Author's Addresses............................................31 14. Full Copyright Statement......................................31 4. Overview The VFDP protocol has been built around the following multicast reliability definition : "One hundred percents of the listening receivers MUST receive one hundred percents of the carried content with a maximum efficiency, by optimising the amount of byte the sender needs to send, without introduce heavy network perturbations". From this point, VFDP can achieve two levels of multicast reliability : statistical (VFDP version 1) or deterministic (VFDP version 2). Statistical multicast reliability is intended to receiver groups which majority has not a backchannel, while deterministic multicast reliability is essentially intended to receivers having a unicast or multicast, permanent or switched, backchannel. To give a general view of the VFDP reliability strategy, in the first case reliability is statistically guaranteed by resending N time the complete content. N depends on the link BER, the number of receivers and the time between two transmissions. In the second case, reliability is ensured by retransmitting only the missing pieces in order to save time and bandwidth. This strategy is also known as selective negative acknowledgments (NACK). By combining these two solutions we obtain a good compromise between bandwidth efficiency, short content delivery time and reliability degree. Thomas Richon Draft - Expires July 2002 [Page 3/32 Internet Draft Versatile File Delivery Protocol July 2002 In its future form (version 3), VFDP will provide a new ôadaptiveö multicast reliability strategy based on packet-level forward error coding techniques. The idea is to dynamically adjust the amount of redundant FEC packets from the real time network BER knowledge deduced of the NACK analysis. Finally, it is necessary to emphasize that VFDP works perfectly for reliable multicast transfer over satellite network environments, therefore VFDP is well suited to asymmetric networks. If you have any comments about VFDP please direct its to the RMT mailing list. 5. Terminology This document uses terms defined and explained in the RFC 2887 and RFC 3048 (see References). Others VFDP specific terms are explained subsequently : o Backchannel : an IP connection allowing to reach the sender or an aggregator node. A backchannel can be permanent (dedicated line) or switched (modem). In this draft we consider that permanent backchannels have an insignificant connection establishment time while commuted backchannels may have potentially very long connection establishment time (several tens of seconds). o Transmission : be careful in reading this document because this term may have two meanings. In a general context, transmission means a simple file transfer but in a VFDP session context it could also mean one of the "passes" or partial retransmissions required for achieving a reliable file transfer. o Node : a node is a general term to define network elements. It can be a sender, a receiver, a router or an aggregator. o Aggregator : an aggregator is an OPTIONAL VFDP network node allowing to decentralize identical packet aggregation process usually done by senders. 6. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. The outline of this draft has been freely adapted from the protocol instantiation draft outline proposed in [3] by the RMT working group. Thomas Richon Draft - Expires July 2002 [Page 4/32 Internet Draft Versatile File Delivery Protocol July 2002 7. Applicability Statement 7.1. Target application space The main VFDP target application space is one-to-many bulk file transfers concerning very large heterogeneous multicast groups. It concerns mainly applications which requires huge file replications over an IP multicast network with an high level of reliability such as Digital Cinema applications, cache mirroring, ftp mirroring, database replication and so on. More generally VFDP target application space is focused on services providing common interest information. 7.2. Target scale VFDP intends to achieve the better level of reliability for multicast groups involving : o Receivers without any backchannel, o Receivers with a unicast commuted backchannel, o Receivers with a unicast permanent backchannel, o Receivers with a multicast commuted backchannel, o Receivers with a multicast permanent backchannel, o Or a mix of all these kinds of receiver. 7.3. Intended environment VFDP suits perfectly to multicast networks, involving an undefined number of receivers being or being not interconnected. It SHOULD be used when your multicast network is sensitive to unpredictable isolated or consecutive data losses. More generally VFDP may be used in an environment which lends itself to multicast applications. Satellite environments and radio relay system are good examples. 7.4. Weaknesses and known failure modes (To be done) o Privacy, if not associated with an encryption file algorithm or an IP stream scrambler, o Reliability, in case of extremely long losses, (about few minutes) o Security, possible IP or VFDP identifier spoofing, o Security, possible DoS attack on a sender or aggregator node. 7.5. Compliance with building block applicability statements Thomas Richon Draft - Expires July 2002 [Page 5/32 Internet Draft Versatile File Delivery Protocol July 2002 7.5.1. NACK-based Reliability VFDP provides unicast and multicast negative acknowledgment mechanism. 7.5.2. FEC coding In this version, VFDP do not use any packet-level FEC coding at the source to repair data from isolated losses. 7.5.3. Congestion control VFDP uses a time-based mechanism and OPTIONAL decentralized aggregator hosts to avoid backchannel congestion control. In order to control congestion at the source, VFDP provides a Suspend & Resume session feature. o Generic router support VFDP do not need any specific router support. It is fully compatible with generic multicast-enabled routers. 7.5.4. Tree configuration The multicast network is viewed as flat, there is no hierarchical relationship between receivers. 7.5.5. Data security (To be done) 8. Protocol Definitions 8.1. Multicast channel A VFDP multicast channel is defined by a couple (ClassD @,Port). We MUST distingues two types of channel : public ones and private ones. A ôpublic channelö is initialized by a sender to communicate with receivers; its (ClassD @,Port) couple is statically configured once. The public channel is an entry point into the VFDP multicast network while the ôprivate channelö is only used to transfer data. For each transmissions a private channel SHOULD dynamically and temporary be instanced by a sender to carry data. In this document, we also use the terminology "Announcement channel" and "Transport channel" to describe public and private channels. 8.2. Sender node A sender node holds all the files to send. Generally speaking, it rules and manages all transmissions. For example, if a new transmission has an higher priority than all current running Thomas Richon Draft - Expires July 2002 [Page 6/32 Internet Draft Versatile File Delivery Protocol July 2002 sessions, the sender SHOULD have to temporarily suspend few other ones in order to free enough bandwidth. Then it MUST resume and finish all suspended transmissions. A VFDP sender node can be broken down into several components : o A "Sessions manager" allowing to manage current and scheduled sessions, o A "Channels manager" allowing to manage and distribute available multicast private and public channels. o A "Bandwidth and QoS manager" allowing to manage several session transmissions with criterions such as priority, maximum allocated rate, et cetera. o A "Reports manager" providing in real time network statistics available from sessions in progress and providing after each transmission a complete delivery report (duration, list of OK/NOK/Mute receivers, and so forth). It also may be used to monitor private and publics channels, o A "Congestion control manager" allowing to manage available aggregator nodes and backchannels congestions by distributing sessions over several appropriate aggregators. 8.3. Receiver node A receiver node MUST be able to recover a session from any VFDP packets received in a public multicast channel, even if it missed the beginning of the session. It can be broken down into four main components : o A "Contexts manager" allowing receivers to handle multiple file transfers in parallel, o A "Public channels manager" managing current public channels which receiver is currently listening to, o A "Filters manager" managing the current filters that should have to be applied before opening a context. For instance, this manager handles a personal identifiers matching list used to filter recipients list fields. o A "NACK suppression manager" when a multicast backchannel is used, 8.4. Aggregator node An aggregator node is an OPTIONAL network element but it is RECOMMENDED when receivers group size starts to grow faster than your network bandwidth capacity. This element is intended to reduce network congestion at the source by collecting and aggregating packets having the same session identifier. First of all, an aggregator node SHOULD, from a set of packets, recognize all datagrams with the same ômessage typeö and concatenate in one recipient list, all receiver identifiers of these packets. Then, in case of Nack packets it SHOULD also aggregate, without any redundancy, all the missing segments requested in one Nack list. Finaly it MUST return to the source a unique representative packet for each message types received from the group. Thomas Richon Draft - Expires July 2002 [Page 7/32 Internet Draft Versatile File Delivery Protocol July 2002 Two functionnals modes are possible : automatic or slave. In the first mode an aggregator triggers a collection process just when it receives a packet with a new session identifier. Then it will stop this process at the end of its own fixed time-window. With the ôslaveö mode, the sender asks aggregators to trigger a collection process for a specific session and during a precise time window. All the packets coming before and after this time-window SHOULD be rejected. 8.5. Session Of course senders and receivers can naturally handle more than one file transfer at a time, each of them is "encapsulated" in a VFDP "session". This session rules a specific file transfer from the beginning to the end in an autonomous and independent way. We RECOMMEND to people who would like to implement VFDP is to start by building a VFDP session manager. The first thing to do before sending a file with VFDP is to instantiate a new session. For each new session a unique 32 bits identifier MUST be used by the sender. Afterwards this session identifier will be kept all along session lifetime. A sender MUST make sure that two different sessions don't use the same identifier. For instance, it MAY be possible that the (N+1)th transmission of a session doesn't use the same multicast private channel than the Nth transmission of the same session, in that case we understand that the session identifier will be the only way for receivers to retrace their existing contexts. In this draft, we will often use the word "context" to describe the receiver knowledge state of a particular session. On one hand, we could say that a sender knows the "full context" of a particular session. On the other hand receivers are aware of "a" context which can be very different from one to another. In the next of this memo, sometimes the word ôjobö may be employed instead of the right protocol terminology ôsessionö. As we will see further in the abstract program interface paragraph, a VFDP session can be seen, from an object oriented point of view, as an object offering method and attributes. A VFDP session can initiate, as much as it will be necessary complete or partial re-transmission to guarantee file delivery. The basic idea is, before running a session, you SHOULD have to provide a set of parameters such as : o VFDP_Session_ID : An unique 32 bits identifier, o VFDP_Session_SrcFileName : file name of the file to send, o VFDP_Session_SrcPathName : the source pathname where the file is stored (it can be a UNC path), o VFDP_Session_SegmentSize : the payload size carried by VFDP data packets, Thomas Richon Draft - Expires July 2002 [Page 8/32 Internet Draft Versatile File Delivery Protocol July 2002 o VFDP_Session_AnnounceProtocol : It MUST be VFDP, o VFDP_Session_TransportProtocol : A VFDP session have been designed to be opened to other announce or transport protocols. At this time three transport protocols are available. This field MAY hold VFDPv1, VFDPv2 or MDPv2 statements. o VFDP_Session_RecipientList : A list of all the recipients (see the 1.4 paragraph), o VFDP_Session_SourceID : An unique 32 bits identifier, o VFDP_Session_PublicChannel : an IP multicast class D address and a UDP port, o VFDP_Session_PrivateChannel : an IP multicast class D address and a UDP port, o VFDP_Session_CompleteTransmissionMax : maximum authorized complete transmission. o VFDP_Session_PartialTransmissionMax : maximum authorized partial transmission. o VFDP_Session_ReliabilityStrategy : it MAY be statistical (VFDPv1) or deterministic (VFDPv2). In the first case the return channel won't be used for this session, in the second it will. o VFDP_Session_DestinationDirectory : An absolute pathname from the root reception directory, o VFDP_Session_Overwrite : it MAY be YES or NO, in case of an existing session context or file. o VFDP_Session_BackChannelList : it MUST be an unicast or multicast IP address associated to a TCP or a UDP port, IP@:Port. It also SHOULD be a list of unicast and multicast IP address associated to TCP or UDP port. In this last case receivers will pick randomly one of the return channels listed according to their possibilities (unicast or multicast). o VFDP_Session_ResponseTimeWindow : in case of a deterministic reliability strategy, a sender MUST provide a time window used by all receivers to split up randomly. It SHOULD be a reasonable figure taking into account the multicast group size. o It exists few others VFDP adjustment parameters that can be deducted from packets description (see Packets Format). All these parameters are sufficient to build a simple VFDP session manager, in addition, if there is a need for building to build a dynamic bandwidth manager and a congestion control manager the following parameters would be required : Thomas Richon Draft - Expires July 2002 [Page 9/32 Internet Draft Versatile File Delivery Protocol July 2002 o VFDP_SessionRate : This parameter SHOULD be the payload rate whished, o VFDP_SessionPriority : This parameter SHOULD be an integer representing the priority degree allocated to the session. 8.6. Data segment A VFDP segment is the smallest data unit carried on the multicast network. We RECOMMEND to keep the VFDP segment size compatible with the MTU (Maximum Transfer Unit) of your multicast network. For instance, the default MTU value for satellite and terrestrial Ethernet networks is 1500 octets. Beyond this value, IP packets will be fragmented and reassembled by the operating system, this may imply severe performance degradations. Therefore, the default VFDP segment size is fixed to 1460 octets (knowing that IP, UDP and VFDP headers sum makes 40 octets). In a session, every data segment is numbered (32 bits word) in a increasing way in order to let receivers progressively build a segment bitmap. By starting to one, it is possible to send 2^32-1 segments in a unique VFDP session, so, with a 1460 octets segment size, VFDP is theoretically able to carry 5.7 Teraoctets files. If you are dealing with bigger files, a larger MTU should help. 8.7. Segment losses When a receiver wants to request segments to the sender, it MUST create a missing segments list, also called "NackList". In this list, segment losses can be described explicitly, by adding the exact segment number, or implicitly by adding a segment range. All segments within a range (bounds included) are considered as requested. Obviously a NackList can mix the two descriptions in order to be as small as possible. 8.8. Selective addressing issues 8.8.1. Recipients list A multicast group is defined by a class D IP address and by the following assumption : ôall receivers who have joined a specific multicast group receive the same information at the same timeö. According to this point, VFDP provides a selective mechanism intended to allow or deny a receiver to recover a session content. Even if a receiver listens to a public multicast channel it will only recover the content if it has been explicitly or implicitly named in the session ôrecipients listö. Each packet sent into a public multicast channel MUST contain the ôrecipients listö field. At the other side all the receivers have a personal "matching list" that they use to filter packets. Thomas Richon Draft - Expires July 2002 [Page 10/32 Internet Draft Versatile File Delivery Protocol July 2002 8.8.2. Recommended solution The following paragraph describes one possible solution to fill in the ôrecipients listö field and can be considered as OPTIONAL but RECOMMENDED in order to implement VFDP. You MAY notice this field is free of use and could be different from one VFDP implementation to another. This solution combines multiple possibilities, such as : o Broadcast delivery, o IPv4 address, o VFDP identifier (statically configured once), o VFDP group identifier (possible dynamic registration). Ipv6 address management will be studied in the next version of VFDP. 8.8.2.1. VFDP virtual tree Although the receiver network is viewed as a ôflatö network, it is possible to build a ôvirtual treeö representing the selective addressing issues offered to a sender node. You MUST note that, in this version, there isnÆt any hierarchical relationship between receiver nodes. You could verify it on the schema below; all the receivers are located in the level 2. Nevertheless, an open "virtual node" is declared on the level 2 allowing to build from this point a ôvirtual hierarchical group treeö. With this method a sender has three possibilities to select recipients : o Put the IP version 4 address of the receiver in the recipients list, o Put the VFDP identifier of the receiver in the recipients list. This is useful when the host address of the receiver can change dynamically (DHCP), o Put a VFDP group identifier previously registered by the receiver. VFDP multicast virtual tree example Broadcast Node (10) Level 1 --O---------------- / /|\ \ \ -- / | \ -- \ / / | \ \ \ / / | \ \ --- / / | \ \ \ Level 2 O O O O O O Rcvr Rcvr Rcvr /|\ VirtualNode Root 10_1 10_3 10_N / | \ 10_0(fixedvalue) 10.92.15.1 10.92.1.3 10.92.1.N / | \ / | \ / | \ Level 3 O O O Group1 Group2 |\ Group3 10_0_1 10_0_2 | \10_0_3 | \ Thomas Richon Draft - Expires July 2002 [Page 11/32 Internet Draft Versatile File Delivery Protocol July 2002 | \ | \ Level 4 O O Group4 Group5 10_0_3_1 10_0_3_2 Through this ôvirtual hierarchical group treeö, a sender could manage its own private multicast groups. This functionality is intended for users who would like to dispatch precisely their contents. It is easy to imagine a suitable use of groups identifier in a corporate environment of which structure is hierarchical by nature. Another advantage of group identifier is to permit to drastically reduce the recipients list size without losing fine selective addressing in case of very large multicast groups. In the same way, shorter implies faster, the time used by receivers to match their own and registered group identifiers (from their personal matching list) against these provided by the sender, will be appreciably reduced. In concrete terms, if a sender node put a "group identifier" into a recipients list field, every receiver registered to this group will retrieve the session and by definition every receiver registered to the subgroups will also retrieve it. In addition, VFDP proposes an OPTIONAL dynamic groups registration and un-registration solution. 8.8.2.2. Recipients list examples o Broadcast An empty recipients list is considered as broadcast. o Broadcast all nodes of the VFDP Sub Network 10 "Recipients list" = 10; All the receivers which belong to the sub network 10 (10_1, 10_2 ...) and all the receivers registered to groups and subgroups of this network SHOULD recover this session. o VFDP identifiers "Recipients list" = 10_1;10_2;20_1;20_30; Only the 10_1, 10_2, 20_1, and 20_30 VFDP hosts are allowed to recover the session. o VFDP group identifier "Recipients list" = 10_0_1;20_0_2_1; Receivers registered to parent groups 10_0_1 and 20_0_2_1 will recover this session, in the same way receivers registered to child groups will also be involved. DO NOT forget that the group virtual tree is hierarchical. A receiver is registered to a group when it owns the group identifier in its match list. o IP address "Recipients list" = 10.1.2.3;10.3.2.1; Only the 10.1.2.3 and 10.3.2.1 hosts are allowed to recover the session. o IP mask "Recipients list" = 10.1.2.255; All the receivers in the sub networks 10.1.2.0 will receive the file. Thomas Richon Draft - Expires July 2002 [Page 12/32 Internet Draft Versatile File Delivery Protocol July 2002 o Mix "Recipients list" = 10_1;10_2;10.1.1.255;10.1.2.3;10_0_1;10_0_2_3; 9. Protocol Mechanisms 9.1. Operational overview The following operational overview diagram describes a simplified VFDP network architecture. First of all, the VFDP network architecture is based on a packet mode network where IP datagram is the basic unit. This architecture REQUIRES a multicast connection between sender and receiver nodes but it doesn't matter much whether the network is symmetric or not. +------------------+ | Application Y | +------------------+ | ^ Orders| |Reports & | |Network statistics V | +---------------+ TCP -------> | Senders | <------- UDP or / +---------------+ \ or UDP / ^ | \ TCP V | F| V +-----------------+ TCP|N I| +---------------+ | Aggregators | or |A L| | Aggregators | +-----------------+ UDP|C E|U +---------------+ ^ |K S|D ^ \ | |P / \ NACK | V NACK / UDP or UDP or \ +---------------+ / TCP TCP ------- | Receivers | ------- +---------------+ | |Files |delivered V +------------------+ | Application X | +------------------+ 9.2. Send & Receive mechanism To send a file, a sender MUST start by sending a burst of "FirstAnnounce" packets in a public multicast channel. For example a phase of 20 "FirstAnnounce" packets, spaced out about 1 s or 10 s, will offer more safety than a single FirstAnnounce packet immediately followed by data. All the necessary inform to recover Thomas Richon Draft - Expires July 2002 [Page 13/32 Internet Draft Versatile File Delivery Protocol July 2002 data is provided in this packet (see the Packets description paragraph for more information) especially the multicast private channel chosen. Then the sender can start to send data segments in the multicast private channel, including in each header the same session identifier than the one provided in FirstAnnounce packets. Nevertheless, it is strongly RECOMMENDED to introduce between the announce phase and data transmission phase an adjustable timer to let receivers initialize a new context and listen the private multicast channel. Once all segments have been sent, a busrt of EndOfData packet MUST be sent to inform receivers that they can stop to listen the private channel. Public Private Channel Channel | FirstAnnounce x20 | | | | | T | | | | | Segment1 x1 | | | | Segment2 x1 | | | | Segment3 x1 | | | | Segment4 x1 | | | | Segment5 x1 | | | | EndOfData x20 | T : ajustable Timer xNN : number of packet repetition 9.3. Late-join mechanism Note that even if we send a burst of FirstAnnounce packets, receivers MAY still miss the file. For example, if a receiver joins the public channel just after the announcement phase. This problem is known as ôlate-joinö. In order to let receivers retrieve as mush as segments as they can, it MAY be useful to go on sending FirstAnnounce in the public channel during the data phase. Public Private Channel Channel | FirstAnnounce x20 | | | | | T | | | | | Segment1 x1 | | FirstAnnounce x5 | | Segment2 x1 | | | | Segment3 x1 | | FirstAnnounce x5 | | Segment4 x1 | | | | Segment5 x1 | | | | EndOfData x20 | T : ajustable Timer xNN : number of packet repetition Thomas Richon Draft - Expires July 2002 [Page 14/32 Internet Draft Versatile File Delivery Protocol July 2002 But all of these FirstAnnounce packets burst during data transmission has a cost that MUST be charged on the allocated payload rate. It is your concern to choose how much percent you want to allocate to the late-join mechanism. But we recommend you to keep at least 5% of the session bandwidth. Keep in mind that it MAY take much more time and bandwidth to resend the whole file only for few late receivers. 9.4. Overlapping transmissions mechanism Now letÆs assume that some receivers missed, for any reason, some parts of the file. For example segments 2,3 and 5. Moreover suppose that receivers havenÆt got any backchannel. Then it would be necessary to use the statistical reliability strategy and the overlapping transmissions mechanism. After the sender finished the first transmission, it will go on by doing one or more "restart" phases (see the schema below). Then receivers SHALL take advantage of these retransmission, if necessary, by overlapping all segments to recover the entire file. In this case it would be necessary to add an adjustable timer between each ôRestartAnnounceö phases. This value depends on your multicast link reliability and the number of retransmission you planned. For example, in a satellite environment a 15 minutes wait could efficiently guaranteed file delivery even during heavy weather conditions (estimated to 10 minutes on average). Public Private Channel Channel | FirstAnnounce x20 | | | | | T | | | | | Segment1 x1 | | FirstAnnounce x5 | | Segment2 x1 | | | | Segment3 x1 | | FirstAnnounce x5 | | Segment4 x1 | | | | Segment5 x1 | | | | EndOfData x20 | | Restart x5 | | | | | T | | | | | Segment1 x1 | | Restart x5 | | Segment2 x1 | | | | Segment3 x1 | | Restart x5 | | Segment4 x1 | | | | Segment5 x1 | | | | EndOfData x20 | | Restart x5 | | | | | T | | | | | Segment1 x1 | | Restart x20 | | Segment2 x1 | | | | Segment3 x1 | | Restart x20 | | Segment4 x1 | | | | Segment5 x1 | Thomas Richon Draft - Expires July 2002 [Page 15/32 Internet Draft Versatile File Delivery Protocol July 2002 | | | EndOfData x20 | 9.5. Abort mechanism Senders MUST be able to abort a session at any time. If some data are currently being sent, a burst of ôAbortTransportö packets has to be sent on the private channel. Public Private Channel Channel | FirstAnnounce x20 | | | | | T | | | | | Segment1 x1 | | FirstAnnounce x20 | | Segment2 x1 | | | | Abort x20 | While if the session is not finished but in an idle state, a burst of ôAbortAnnounceö packet SHOULD be sent on the public channel. Public Private Channel Channel | FirstAnnounce x20 | | | | | T | | | | | Segment1 x1 | | FirstAnnounce x20 | | Segment2 x1 | | | | Segment3 x1 | | FirstAnnounce x20 | | Segment4 x1 | | | | Segment5 x1 | | | | EndOfData x20 | | Abort x20 | | | After receiving this packet receivers SHALL close the private channel, if it's still relevant, and delete their contexts. 9.6. Suspend & Resume mechanism If a sender estimates it is necessary to suspend a running session, it has to stop segments transmission and send a burst of "SuspendTransport" packets in the private channel. Then receivers will know that they have to close the multicast private channel and wait for a "ResumeAnnounce" in the public channel. Once they will receive it they could carry on as before. Public Private Channel Channel | FirstAnnounce x20 | | | | | T | | Thomas Richon Draft - Expires July 2002 [Page 16/32 Internet Draft Versatile File Delivery Protocol July 2002 | | | Segment1 x1 | | FirstAnnounce x20 | | Segment2 x1 | | | | Segment3 x1 | | | | Suspend x20 | | | U | | |ResumeAnnounce x20 | | | | | T | Segment4 x1 | | | | Suspend x20 | | | U | | |ResumeAnnounce x20 | | | | | T | Segment5 x1 | | | | EndOfData x20 | T : ajustable Timer xNN : number of packet repetition U : undefined time 9.7. Negative acknowledgement mechanism The negative acknowledgement mechanism provides to the sender a deterministic feedback. It will be able to repair only the missing part of all the receiver contexts. Of course in this case receivers MUST have a backchannel. At the end of each transmission the sender SHOULD send a burst of "AskForNACK" packets. Then receivers will pick up randomly, and according to their own capacity, one of the available backchannels in this session. Once this operation done, they SHOULD pick up a random response time in the time window allowed by the sender. At this precise time, receivers SHALL send their NACK packets in the backchannel (see the NACK packet description to know how to build a NackList). The sender node MUST take into account in its session collection timer an extra time for receivers having a switched backchannel. After analyzing results the sender proceeds to a partial "Restart" transmission where only necessary segments are sent. In the following example, three receivers have sent a list of NACK after the first transmission. Then one receiver has sent another NACK after the second partial transmission. After the third transmission no more receivers have requested any segment. At this point it MAY be possible to continue session with the "completion mechanism". Public Private Back Channel Channel Channel | FirstAnnounce x20 | | | | | | | T | | | | | | | Segment1 x1 | | | | FirstAnnounce x20 | | Segment2 x1 | | | | | | Segment3 x1 | | | | | | Segment4 x1 | | | | | | Segment5 x1 | | | | | | EndOfData x20 | | | | | T | | | | Thomas Richon Draft - Expires July 2002 [Page 17/32 Internet Draft Versatile File Delivery Protocol July 2002 | AskForNACK x20 | | | | | | | T | | | | | | | | | NACK x1 | | | | | | NACK x1 | | | | | | NACK x1 | | Restart x20 | | | | | | | | Segment2 x1 | | | | | | Segment3 x1 | | | | | | Segment5 x1 | | | | | | EndOfData x20 | | | | | T | | | | | AskForNACK x20 | | | | | | | | | | NACK x1 | | | | | | | | Restart x20 | | | | | | | | Segment2 x1 | | | | | | EndOfData x20 | | | | | T | | | | 9.8. Multicast Nack suppression mechanism When the receiver uses a multicast backchannel, it acts almost like the unicast way. The difference stays in the fact receivers MUST listen to the multicast backchannel from the beginning of the time-window. >From this point, a receiver SHALL adapt in real time (by doing suppressions), its NACK list according to the other NACK requests done before. When its turn will come, it SHALL send in the multicast backchannel, a "NackResult" packet with its current Nack list. For instance if a receiver needs segment 4 to complete its bitmap and another receiver also required this segment earlier in the multicast backchannel, the first receiver wouldn't have to ask for it anymore. 9.9. Completion mechanism Before ending a session, it is RECOMMENDED, but OPTIONAL, to initiate a completion phase in order to know exactly : o who are the receivers that have successfully received the file, o who are the receivers that haven't received the file and what are the reasons, o who are the receivers that have not responded to any requests (by deduction from the two previous point). Assuming that no more receiver answered to an "AskforNack" datagram, then the sender will send a burst of "AskforCompletion" packets in the multicast public channel. Every receiver having a backchannel MUST answer to this request by a positive (file received) or a negative (file not received) completion result. At the end of the session, the sender will be able to provide a complete session report. In the following example three receivers have answered to the completion request. Two of them have received the entire file (COMP Thomas Richon Draft - Expires July 2002 [Page 18/32 Internet Draft Versatile File Delivery Protocol July 2002 +) and the last one indicates that it couldn't succeed to recover the whole file (COMP -) (See the CompletionResult packet description for information). Public Private Back Channel Channel Channel | FirstAnnounce x20 | | | | | | | T | | | | | | | Segment1 x1 | | | | FirstAnnounce x20 | | Segment2 x1 | | | | | | Segment3 x1 | | | | | | Segment4 x1 | | | | | | Segment5 x1 | | | | | | EndOfData x20 | | | | | T | | | | | AskForNACK x20 | | | | | | | T | | | | | AskForCOMP x20 | | | | | | | | | | COMP + x1 | | | | | | COMP û x1 | | | | | | COMP + x1 | 9.10. Aggregation mechanism We saw that an aggregator can have two different functional modes : automatic or slave. When a user doesn't want to let the aggregator handle automatically its collection time-window (automatic mode), it MAY send an "AskForNACKAggreg" or an "AskForCompAggreg" packet to each aggregator involved in a session, just before doing an "AskForNACK" or "AskForCompletion" request (slave mode). In this way, the sender can control, among few others things (port, list of receivers ...), the collection time-window for a specific session (See Packets description for more information). -------------- | Sender | ------ -------------- | ^ ^ | AskForNAckAggreg(session) Nack1+2/ \Nack3 | / \ | / \ v -------------- -------------- | Aggregator | | Aggregator | | (Automatic) | | (Slave) | -------------- --------------- ^ ^ ^ / \ | / Nack1 \ Nack2 |Nack3 / \ | --------------- --------------- --------------- | Receiver | | Receiver | | Receiver | Thomas Richon Draft - Expires July 2002 [Page 19/32 Internet Draft Versatile File Delivery Protocol July 2002 --------------- --------------- --------------- For example, if an aggregator receives 5 NACK packets from 5 different receivers (10.1.1.2, 10.1.1.4, 10_2, 10_5, 10.1.1.10) asking respectively : (seg1->seg15;seg23;seg34) , (seg7;seg9; seg32;seg34->seg37), (seg1->3;seg77), (seg8;seg45;seg78),(seg12- >20); The aggregator will produce only one Nack packet towards the sender with : RecipientList = 10.1.1.2, 10.1.1.4, 10_2, 10_5, 10.1.1.10; NackList = seg1->seg20;seg23;seg32;seg34->seg37;seg45;seg77;seg78; 9.11. Additional Protocol Mechanisms 9.11.1. Group status request (To be done) 9.11.2. Dynamic group registration session (To be done) 9.11.3 Bandwith manager (To be done) 10. Detailed nodes functions 10.1. Sender node (To be done) 10.2. Receiver node (To be done) 10.3. Aggregator node (To be done) 11. Packet Formats 11.1. Overview Every message used in a file transfer session can fall into four categories : VFDP_ANNOUNCE, VFDP_TRANSPORT, VFDP_REQUEST, VFDP_RESULT. 11.1.1. VFDP_ANNOUNCE Thomas Richon Draft - Expires July 2002 [Page 20/32 Internet Draft Versatile File Delivery Protocol July 2002 The "FirstAnnounce" message is sent on a public channel by a sender to initialize a file transfer session. From this message receivers will be able to build a reception "context". The "RestartAnnounce" message is sent on a public channel by a sender to warn receiver of an impending partial or complete retransmission. Session information gave in the FirstAnnounce are always present to provide the receivers who missed the FirstAnnounce (LateJoin) another chance to get the session. The "ResumeAnnounce" message is sent on a public channel by a sender if only the session has been suspended before (see "SuspendTransport" message). The "AbortAnnounce" message is sent on a public channel by a sender who wants to cancel a session. This message SHOULD be used only when a sender wants to abort a session which is in a waiting state. Otherwise, if data is being sent on the private channel the sender MUST use the "AbortTransport" message. When receivers received this message they know that they MUST abort and discard the context built for this session. 11.1.2. VFDP_TRANSPORT The "AbortTransportö packet is sent on a multicast private channel by a sender in order to immediately cancel a session. All information already collected by receivers MUST be discarded. The "EndOfData" packet is sent on a multicast private channel by a sender to inform receivers that no more VFDP data segments will be delivered in this transmission. This doesn't mean that no more data will be carried by this session (complete or partial retransmission are always possible). The "SuspendTransport" message is sent on a multicast private channel when sender decides to temporarily suspend this session, with the intent to free bandwidth, in order to start one or more concurrent sessions. Suspend and Resume messages easily allow to build, at the application level, a bandwidth manager based on priority, rate criteria and consequently handling congestion control at the source. 11.1.3. VFDP_REQUEST The "AskForNACK" message is sent on a multicast public channel when the sender wants, or needs to know if receivers missed segments, receiver's identity and what exactly is the missing segments list for each of them. The frequency of this message is not specified but considerably influences the reliability. The "AskForCompletion" packet is sent on a multicast public channel when the sender wants to provide a transmission report to a third party. The "AskForNACKAggreg" packet is only sent to aggregators through a unicast TCP or UDP connection when the sender wants to use the Nack aggregation slave mode. Thomas Richon Draft - Expires July 2002 [Page 21/32 Internet Draft Versatile File Delivery Protocol July 2002 The "AskForCOMPAggreg" packet is only sent to aggregators through a unicast TCP or UDP connection when the sender wants to use the completion aggregation slave mode. 11.1.4. VFDP_RESULT The "NackResult" packet is sent in a unicast TCP or UDP backchannel or in a multicast backchannel by a receiver requesting missing data segments. The "CompletionResult" packet is sent in a unicast TCP or UDP backchannel or in a multicast backchannel by a receiver. This packet informs the sender of receivers session state once they are finished. 11.2. Common Header Every VFDP message MUST start with the following header : 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message type | Message length | +---------------+---------------+-------------------------------+ | Session identifier | +---------------------------------------------------------------+ o The ôVersionö field is used to identify the VFDP version. In order to keep ascending compatibility, this field MUST be set to æVFDPv1Æ (0x01) for all the VFDP_ANNOUNCE and VFDP_TRANSPORT messages and to æVFDPv2Æ (0x02) for all the VFDP_REQUEST and VFDP_RESULT messages. Then VFDPv1 receivers could work with VFDPv2 senders and vice versa. o The ôMessage typeö field identify the VFDP packets, here is a list of all of them : Message Type Value Channel Version FirstAnnounce 0x01 Public v1 RestartAnnounce 0x02 Public v1 ResumeAnnnouce 0x03 Public v1 AbortAnnounce 0x04 Public v1 AskForCompletion 0x11 Public v2 CompletionResult 0x12 or 0x13 Back v2 AskForCompAggreg 0x14 Back v2 AskForNACK 0x21 Public v2 NackResult 0x22 Back v2 AskForNACKAggreg 0x23 Back v2 DataSegment 0x31 Private v1 EndOfData 0x40 Private v1 SuspendTranport 0x41 Private v1 AbortTransport 0x42 Private v1 Thomas Richon Draft - Expires July 2002 [Page 22/32 Internet Draft Versatile File Delivery Protocol July 2002 Others OPTIONAL message types exists in version 2 and are useful to manage receivers groups : Message Type Value Channel Version AskForFlush 0x51 Public v2 AskForStatus 0x52 Public v2 StatusResult 0x53 Back v2 AskForRegistration 0x55 Public v2 RegisterResult 0x56 Back v2 11.3. Packets description o First/Restart/Resume announce packet description 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source identifier | +-------------------------------+-------------------------------+ | Private multicast address | +-------------------------------+---------------+---------------+ | Private UDP port | Indice | Transmi.indice| +-------------------------------+---------------+---------------+ | Flags | SubChannel | Transport type| +-------------------------------+---------------+---------------+ | Segment size | File size (48 bits) | +-------------------------------+-------------------------------+ | File size | +---------------+---------------+-------------------------------+ | Order Number | Filename size | Filename | +---------------+---------------+ + | (variable) | +---------------------------------------------------------------+ | Destination directory size | Absolute destination | +-------------------------------+ + | directory path name (variable) | +-------------------------------+-------------------------------+ | recipient list field size | Recipient list | +-------------------------------+ + | (variable) | +-------------------------------+-------------------------------+ | Custom field size | custom field | +-------------------------------+ + | (variable) | +---------------------------------------------------------------+ The ôSource identifierö field is used to identify the sender node. It MUST be an unique 32 bits integer. Through this field receivers are able to filter session from their origin. Thomas Richon Draft - Expires July 2002 [Page 23/32 Internet Draft Versatile File Delivery Protocol July 2002 ôPrivate Multicast Addressö and ôPrivate UDP portö fields will be used by receivers to recover the session content. As the Firstannounce packet can be sent consecutively N times before and during one transmission in a session (do not forget that it can be a first transmission, a restart or a resume), the ôIndice fieldö indicates the current number. For example you can choose to send 20 ResumeAnnounce packets before starting to resume a session, and 1 ResumeAnnounce packet for 100 segments sent during the transmission. In this case, if 1000 segments have been sent in the private channel, 30 packets SHOULD have been sent in the public channel. The ôTransmission Indiceö indicates the current transmission running number and consequently how many transmission have been done till now. For example, if a sender has already performed 2 complete and 4 partial transmissions in one session, then it will indicate Transmission Indice = 7 for the potential fifth partial transmission. The ôFlagsö field indicates several session information : Bit Description Value 0 Custom field bit0=0 -> no custom field existence bit0=1 -> a custom field is present at the end of the packet 1 Overwrite If the file already exists, bit1=0 -> it wonÆt be overwritten bit1=1 -> it will be overwritten 2 Last bit2=0 -> Other transmissions MAY be done in transmission this session, bit2=1 -> this is the last transmission of this session. 3 Complete or bit3=0 -> This is a complete transmission Partial bit3=1 -> This is a partial transmission 4 Backchannel bit4=0 -> The backchannel MUST NOT be used bit4=1 -> The backchannel MAY BE used The ôSubchannelö field allows to create several public multicast channels from one couple (ClassD,port). It MAY be useful at the implementation level because only one multicast filter and one socket could be used. The ôTransport typeö field indicates which transport protocol will be used to carry data on the multicast private channel. At present time, it MUST be VFDPv1, VFDPv2 or MDPv2. The ôSegment sizeö field indicates the payload size (in octets) of the data segment, while the ôFile sizeö filed indicates the file size in octets . The ôOrder numberö field indicates how many orders have been done in the session up to now. An order can be a FirstAnnounce, a Thomas Richon Draft - Expires July 2002 [Page 24/32 Internet Draft Versatile File Delivery Protocol July 2002 RestartAnnounce, a ResumeAnnounce, an AskForNACK or an AskForCompletion. For example, if in a session there was 1 transmission but suspended and resumed 10 times, then in the last ResumeAnnounce packets burst ôOrder Numberö = 11 (one FirstAnnounce plus ten ResumeAnnounce). You MUST note that ôFileName sizeö is limited to 255. This means that the ôFilenameö field is variable but can hold at most 255 characters, extension included. In the same way the ôAbsolute destination directory pathö is limited to 255 characters. It is not a relative path, meaning that this field SHOULD NOT contain a hard drive letter. It MAY also be a UNC path. The ôRecipient listö field indicates receivers involved into this session. For more information see the ôVFDP Selective addressing issuesö paragraph. o AbortAnnounce packet description We recall that this message is sent on the public channel only if there is no pending data transmission on the private channel otherwise the AbortTransport packet MUST be used. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Custom field size | +-------------------------------+-------------------------------+ | Custom field (variable) | +---------------------------------------------------------------+ In this message the ôFlagsö field indicate a unique information : Bit Description Value 0 Custom field bit0=0 -> no custom field existence bit0=1 -> a custom field is present at the end of the packet For example, custom field MIGHT be used to indicate why this session has been aborted and what does the application have to perform when this event occurs. o AskForNACK and AskforCompletion packets description 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thomas Richon Draft - Expires July 2002 [Page 25/32 Internet Draft Versatile File Delivery Protocol July 2002 | Flags | Order Number | Backchannel list field size | +---------------+---------------+-------------------------------+ | Backchannel list | | (variable) | +-------------------------------+-------------------------------+ | Response Time-Window | Recipient list field size | +-------------------------------+-------------------------------+ | Recipient list | | (variable) | +-------------------------------+-------------------------------+ | Custom field size | Custom field | +-------------------------------+ + | (variable) | +---------------------------------------------------------------+ The ôFlagsö field indicate several information : Bit Description Value 0 Custom field bit0=0 -> no custom field existence bit0=1 -> a custom field is present at the end of the packet 1 TCP our UDP If a unicast backchannel is used, bit1=0 -> receiver MUST answer using TCP bit1=1 -> receiver MUST answer using UDP 2 Message If a multicast backchannel is used, Suppression bit1=0 -> receivers MUST send each of their request bit2=1 -> receivers can suppress their pending request already requested by another receiver ôOrder Numberö, see the First/Restart/Resume announce packet description. The ôBackchannel listö field represents a list of couple IP@:port. For a simple use of VFDP, this field could only hold one couple including the sender IP address interface, intended for receivers without multicast connection, and another couple including a multicast IP address for receivers having a IP multicast connection. Depending of their return channel capacities receivers will pick up one of the two couples. Henceforth, if a sender has several aggregator nodes at its disposal in the network, it can use them, to decentralize the packet aggregation process and reduce backchannel congestion, by adding a new couple IP@:port to the backchannel list. From this list, unicast receivers could randomly pick up one of the unicast backchannels available. For example, a backchannel list may look like : 10.20.30.40:5000,10.20.30.50:5000,10.20.30.60:5000, 224.10.20.30:5000, where 10.20.30.40 is the sender node interface, 10.20.30.50 and 10.20.30.60 are aggregator node interfaces and 224.10.20.30:5000 is the private backchannel to send multicast NACK. Thomas Richon Draft - Expires July 2002 [Page 26/32 Internet Draft Versatile File Delivery Protocol July 2002 The private multicast channel may be used by multicast receivers when no one has been specified in the backchannel list. The ôResponse Time-Windowö field is used by senders to randomly distribute multicast and unicast receivers requests in a fixed time window. Receivers SHOULD pick up a random time in this window then they will precisely send their requests at this time. In case of unicast receivers this time-based congestion control mechanism is very efficient to save sender or aggregator nodes from collapsing under requests implosions. While in case of multicast receivers this mechanism SHOULD also permit to limit the number of useless identical requests by using the NACK suppression method. Actually, from the moment where a multicast receiver receives this packet from the sender it has to immediately start listening to the private multicast backchannel. Then it could know all the requests that have been done on this channel before its timer expires and adapt intelligently its own request if its still relevant. The ôRecipient listö field indicates which are receivers involved by this session. For more information see the ôVFDP Selective addressing issuesö paragraph. o EndOfData /SuspendTransport/AbortTransport packet description 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Segment number stop | +-------------------------------+-------------------------------+ | Flags | Custom field size | +-------------------------------+-------------------------------+ | Custom field | | (variable) | +---------------------------------------------------------------+ The ôSegment Number Stopö field indicates what is the last segment number sent in this transmission. In case of an EndOfData message type the Segment Number Stop field is equaled to the last segment number of the file. In case of a SuspendTransport message type this field MUST be equal to the next segment number from where the session will be resumed. In case of an AbortTransport this field is not relevant. In this message the ôFlagsö field indicates a unique information : Bit Description Value 0 Custom field bit0=0 -> no custom field existence bit0=1 -> a custom field is present at the end of the packet Thomas Richon Draft - Expires July 2002 [Page 27/32 Internet Draft Versatile File Delivery Protocol July 2002 As for the AbortAnnounce datagram you MIGHT use the custom field to indicate why you have decided to abort this session and what does your application has to perform when this event occurs. o DataSegment packet description 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Segment number | +---------------------------------------------------------------+ | Payload | | (Vfdp_PayLoad Bytes) | +---------------------------------------------------------------+ In order to minimize header overload this packet has been intentionally thought to only carry bare necessities and of course the payload. The global datasegment header size is 40 octets (20*IP +8*UDP + 8*CommonHeader + 4SegmentNumber). The ôSegment numberö field indicates the segment number of the following ôPayloadö field. The payload size MUST fit the equation Vfdp_PayLoad <= Network MTU û (IP + UDP + VFDP) header sum. o NackResult packet description 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Receiver list size field | +-------------------------------+-------------------------------+ | Receivers list | | (variable) | +-------------------------------+-------------------------------+ | NACK list field | NACK list | +-------------------------------+ + | (variable) | +-------------------------------+-------------------------------+ | ACK list field | ACK list | +-------------------------------+ + | (variable) | +-------------------------------+-------------------------------+ | Custom field size | Custom field | +-------------------------------+ + | (variable) | +---------------------------------------------------------------+ The ôFlagsö field indicates several informations about the NACK list : Bit Description Value 0 Custom field Bit0=0 -> no custom field Thomas Richon Draft - Expires July 2002 [Page 28/32 Internet Draft Versatile File Delivery Protocol July 2002 existence Bit0=1 -> a custom field is present at the end of the packet 1 Unused bit Not applicable 2 Last Message Bit2=0 -> this is not the last Nack message Bit2=1 -> this is the last Nack message 3 Nack list Bit3=0 -> The complete file is requested options Bit3=1 -> Only the mentionned segments in the NackList are requested If the Nack list can not fit into one NackResult packet the bit 2 of the ôFlagsö field could be used in order to tell senders or aggregators than others packets will come after this one. Multicast or unicast receivers MUST only fill the ôReceivers listö field with their own and unique identifier. It MAY be an IPv4 address or a VFDP identifier according to the receiver configuration. In this packet, the idea of recipient list is intended to aggregator and sender nodes. Actually when an aggregator receives NackResult packets from receivers with the same session identifier, it will concacenate all the receivers id in the recipients list of a new NackResult packet before to send it to the sender. The ôNackListö field indicates all the missing segments detected by receivers. (See the Segment losses paragraph to know how to fill this field) The "AckList" field is not used in this version. o CompletionResult packet description 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session State | Flags | Receiver list size field | +---------------+---------------+-------------------------------+ | Receivers list | | (variable) | +-------------------------------+-------------------------------+ | Custom field size | Custom field | +-------------------------------+ + | (variable) | +---------------------------------------------------------------+ The "SessionState" field indicates the state of session for all recipients . It MUST be one of the following value : Value Description 0x01 File received successfully 0x02 Abort successful 0x03 File not received Thomas Richon Draft - Expires July 2002 [Page 29/32 Internet Draft Versatile File Delivery Protocol July 2002 0x04 Abort impossible (too late) 0x05 Announce all missed (excepted AskForCompletion) 0x07 Other reason (see the custom field) The "Flags" field indicates the two following information : Bit Description Value 0 Custom field Bit0=0 -> no custom field existence Bit0=1 -> a custom field is present at the end of the packet 1 Unused bit Not applicable 2 Last Message Bit2=0 -> this is not the last Completion message Bit2=1 -> this is the last Completion message Receiver MUST fill the "Receivers list" field of this packet only with its own identifier. Then aggregators or senders SHOULD aggregate all "CompletionResult" packets with the same "SessionState" field into one containing a concatenated receivers list. o AskForFlush packet description 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | FlushFilter size | +-------------------------------+-------------------------------+ | FlushFilter | | (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (To be done) o AskForRegistration packet description (To be done) o AskForStatus packet description (To be done) o RegistrationResult packet description (To be done) o StatusResult packet description (To be done) Thomas Richon Draft - Expires July 2002 [Page 30/32 Internet Draft Versatile File Delivery Protocol July 2002 11.4. IPv6 message parts (To be done) 11.5. IPSEC support (To be done) 12. References [1] : RFC 2887, "The Reliable Multicast Design Space for Bulk Data Transfer", M. Handley, S. Floyd, B. Whetten, R. Kermode, L. Vicisano M. Luby. August 2000. [2] : RFC 3048, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer", M. Handley, S. Floyd, B. Whetten, R. Kermode, L. Vicisano M. Luby. January 2001. [3] : draft-ietf-rmt-author-guidelines-01.txt, "Author Guidelines for RMT Building Blocks and Protocol Instantiation documents", R.Kermode, L.Vicisano. March 2001. 13. Author's Addresses Thomas Richon, France Telecom R&D 35 Rue du General Leclerc Phone: +33 1 45 29 88 35 92794, Issy-Les-Moulineaux, FRANCE Email: thomas.richon@francetelecom.com Gilles Chanteau, France Telecom R&D 35 Rue du General Leclerc Phone: +33 1 45 29 58 67 92794, Issy-Les-Moulineaux, FRANCE Email: gilles.chanteau@francetelecom.com Gerard Babonneau, France Telecom R&D 4 rue du Clos Courtel Phone: +33 2 99 12 40 08 35512 Cesson-sevigne, FRANCE Email: gerard.babonneau@francetelecom.com 14. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, Thomas Richon Draft - Expires July 2002 [Page 31/32 Internet Draft Versatile File Delivery Protocol July 2002 published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Thomas Richon Draft - Expires July 2002 [Page 32/32