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