Internet DRAFT - draft-helal-macp
draft-helal-macp
Internet Draft J.N. Helal
Document: draft-helal-macp-00.txt Quadrille Ingenierie
Expires: December 2002 August 2002
Multicast Announce and Control Protocol (MACP)
1 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.
2 Abstract
This memo describes the message and procedure related to the
Multicast Announce and Control Protocol (MACP). This protocol is
considered as one "building blocks" of a reliable multicast
transport framework.
The Multicast Announce and Control Protocol (MACP) organizes the
process by which a multicast sender node (Msender) manages
transmissions to dynamic groups of receivers (Mreceivers) in the
"one-to-many" model. The prime objective of MACP is to work in
conjunction with various data transport protocols in order to meet
various network requirements. One other main objective is to provide
a unified announce transport mechanism for both bulk data transfer
and streamed data.
MACP allows Mreceivers configuration and automated correlated error
loss detection from special Mreceivers acting as "nack probes"
whenever the NORM transport provides this capability (see EMCON mode
in [5]).
MACP is primarily designed for "flat" data transfer. In the future
MACP will provide a mechanism for aggregating the back traffic
trough a hierarchical network. However how a tree capable NORM
Helal Expires January 2003 1
Multicast Announce and Control Protocol July 2002
transport could be used along with MACP has not been studied for
now.
From this release of the draft, the following change has been made:
o The address list was inserted directly into the announce message.
This results in a simplified implementation but less efficiency in
the targeted group size for a given MTU.
o Add listen/unlisten message for receiver configuration and
automatic correlated error detection support.
o The announce and control message has been split into a announce
message and a command message. In this way only the command message
holds back channel data. This allows announce message to hold
larger content and group descriptions. Accordingly the REGISTER bit
into the old announce and control message has been replaced by a
query into the command message.
o Authentication field have been moved from the common header to the
payload of the announce and listen messages.
o Encryption fields have been defined into the common header.
o Command queries (initially into the announce and control message)
are now into the command message. Accordingly Delay and connexionTo
fields have been moved into this message (announce do not hold back
channel info anymore).
o Content descriptor is now described into the announce message
extension. Media description for real time streaming now supports
multiple encoded layers.
The MACP protocol is under experiment and current version is 1. It
has been partially implemented for bulk data only as part of the
multicast software product "M-Linked". ôM-Linkedö is a registered
trademark of quadrille ingenierie.
Helal Expires January 2003 2
Multicast Announce and Control Protocol July 2002
3 Table of Contents
1 Status of this Memo................................................1
2 Abstract...........................................................1
3 Table of Contents..................................................3
4 Definitions........................................................5
4.1 Glossary of terms.............................................5
4.2 Building block background.....................................5
4.3 Architecture..................................................6
4.4 Network channels..............................................7
4.5 Maximum Transmission Unit.....................................8
5 General Description................................................8
5.1 Transmission management.......................................8
5.2 Configuration................................................10
5.3 Back-traffic management......................................10
5.4 Multiple retransmissions for bulk data.......................10
5.5 Context managements..........................................11
5.6 Group Address Description....................................12
5.7 Content Description..........................................12
5.8 Registering..................................................12
5.9 Confidentiality..............................................12
5.10 Authentication..............................................13
6 Message description...............................................13
6.1 Common Header................................................13
6.2 Announce message.............................................15
6.3 Command message..............................................19
6.4 Status Message...............................................22
6.5 Listen Message...............................................25
6.6 Listen Status Message........................................27
6.7 Group Descriptor extension...................................29
6.8 Content Descriptor extension.................................30
6.9 Back Channel extension.......................................31
7 Dynamics..........................................................32
7.1 Emission Rate................................................32
7.2 Sender cycles................................................32
7.2.1 Announcing transmission....................................33
7.2.2 Sending transmission commands..............................33
7.2.3 Splitting large group descriptors..........................33
7.2.4 Registering................................................34
7.3 Receiver cycles..............................................34
7.3.1 Transmissions..............................................34
7.3.2 System.....................................................35
Not applicable (master/slave operation)..........................35
7.4 Time outs....................................................35
8 Security..........................................................35
9 Ipv6..............................................................36
10 Discussion......................................................36
Helal Expires January 2003 3
Multicast Announce and Control Protocol July 2002
10.1 SAP similarity.............................................36
10.2 Dialup.....................................................36
10.3 Public keys vs. symmetric algorithm for announce session keys36
10.4 Automated Error Correlation................................37
10.5 Proxy......................................................37
11 References.....................................................37
12 Annex : MACP Interface.........................................38
12.1 Sender side................................................39
12.2 Receiver side..............................................45
12.3 Error codes................................................49
12.4 Control codes..............................................49
13 Author's address...............................................49
Helal Expires January 2003 4
Multicast Announce and Control Protocol July 2002
4 Definitions
4.1 Glossary of terms
o Mnetwork: a network with multicast capacity on the downstream path
at least
o Msender: a node sending content through the Mnetwork
o Mreceiver: a node receiving content from the Mnetwork
o Channel: a unicast network path to a host defined as a unicast IP
address and a logical port (either udp or tcp).
o Mchannel: a network path to a host group defined as a class D IP
address and a logical udp port.
o TID: unique Transmission Identifier in a one to many transmission
o Stream: A physical transmission.
o LUID: The Logical Unique Identifier, a 32 bits value uniquely
identifying the node.
o Announce Filtering: Process by which a Mreceiver accepts a new
transmission that it is interested in.
o Unknown announce: An incoming announce corresponding to a LUID:TID
value unknown to the Mreceiver.
o New announce: An incoming announce corresponding to a known
LUID:TID but with a modified payload.
o SD: Dession Description.
o MTU: Maximum Transmit Unit of the underlying network layer. For IP
over Ethernet, the MTU is 1500.
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].
4.2 Building block background
It has been proposed to describe Reliable Multicast Transport
Frameworks in terms of "building blocks" [1]. This approach is
believed to help the design of multicast enabled software for the
internet. Building blocks approach could lead to layered protocol
implementations with the ability to meet various network
requirements. According to building blocks taxonomy [1], MACP is
related to the following components:
o Group Membership
Helal Expires January 2003 5
Multicast Announce and Control Protocol July 2002
o Data Reliability
o Security
MACP allows the Msender to send content by using an appropriate
transport protocol. Accordingly an external Negative acknowledgement
(Nack) Oriented Reliable Multicast (NORM) transport [3] is assumed.
NORM transport is primarily defined for bulk data (static RAM of
file). However [3,5] also supports infinite object collections. As
far as streaming transport protocols are concerned, they are
considered as NORM protocols. MACP provides an explicit ACK
mechanism and in this sense, it is concerned with the Data
Reliability component.
MACP provides dynamic group and content descriptions through the
announce message. This information is used upon reception in order
to accept or ignore new transmissions. However MACP is not concerned
with the process by which a Msender "advertises" for sessions
indicating start times and connexion information. Rather this is
supposed to be done at a higher software application level (see the
discussion on SAP similarity).
MACP is not directly concerned with the Congestion Control
component. Rather, MACP traffic is considered to be "out-of-band".
MACP traffic exists along with the transport traffic. Whenever the
transport building block provides support for maximum rate bound
control (even when congestion control is available), it is assumed
here that a small amount of the bandwidth is implicitly available
for MACP.
MACP is not concerned with the process by which the Msender manages
priorities among multiple streams. This may be implemented in an
upper software layer. In this respect MACP simply allows the Msender
to suspend the transmission and announce a partial retransmission.
Accordingly the NORM transport protocol must provide entry points
for suspending a transmission and restarting a pending transmission.
MACP supports Msender authentication and announce payload
encryption. In this way transport Mchannel and session keys are
securely conveyed through MACP. Whenever the NORM transport has the
capability to scramble data content, data confidentiality is
provided. Some provisions are made for changing the session key on
the fly.
4.3 Architecture
The only other building block to be considered here is the NORM
transport protocol. Other components like "scheduler" related to the
congestion control component and "address manager" related to the
session announcement component according to [1] are considered to be
in the core component.
Helal Expires January 2003 6
Multicast Announce and Control Protocol July 2002
+-----------------------------------------------------+
| core component |
+-----------------------------------------------------+
^ ^
| |
v v
+-------------------+ +-------------------+
| | | |
| MACP instance | | NORM instance |
| | | |
+-------------------+ +-------------------+
^ ^
| |
v v
=======================================================
Network
Figure 1: framework architecture
The "core component" is assumed to alternatively call MACP and NORM
instances and to be notified in turn. As a result the present draft
specification requirements concern either MACP instance and the way
the core component should use it.
The annex in this memo provides you with one possible MACP
application program interface (API). An API corresponding the nack
oriented protocol MDPv2 is described in [5].
4.4 Network channels
A Mchannel is defined as an IP group (multicast) address and udp
port [7]. A Channel is defined as an IP (unicast) address and udp
port or alternatively an IP address and tcp port.
MSender MReceiver
+-------+ +------+ +-------+ +------+
| | | | | | | |
| MACP | | NORM | | NORM | | MACP |
| | | | | | | |
+-------+ +------+ +-------+ +------+
| ^ ^ ^ | ^
| | | | | |
v | v v v |
=======================================================
| | | | | |
| | +-(private)--<->-----+ | |
| +----------(private)--<-<---------------+ |
+--------------(public)--->->------------------+
Figure 2: network channels
Helal Expires January 2003 7
Multicast Announce and Control Protocol July 2002
MACP uses Mchannels and Channels separated to those used by the NORM
transport. The MACP announce Mchannel is said "public" since, as the
first one used into the transmission, it has to be known "a priori"
by Mreceivers. Therefore MACP public Mchannels may be assigned at
the upper layer for both Msender and Mreceivers. Other Mchannels and
channels are said private since they are not known to Mreceivers
prior to the transmission. Because private Mchannels are related to
session (and even network configuration) they are assigned at the
Msender upper layer.
In the many-to-many model Mchannels generally hold the back traffic
because every node has an interface to the Mnetwork. In the one-to-
many model, a unicast channel holding the back traffic is preferred
because non-reciprocal multicast routing model is likely to be more
feasible for large-scale networks [13]. This is the case of DVB
satellite and cable broadband services. In general, multicast
protocols supporting the one-to-many model provide support for an
alternate unicast back channel.
Msender announce message conveys private Mchannels to be used by the
NORM transport. It is assume that possible transport alternate
unicast back channel is conveyed by the NORM transport itself.
MACP command message conveys the Mchannel or channels to be used for
sending status message back to the Msender (explicit acking). MACP
Msender implementation uses an aggregation mechanism because status
messages contains information specific to each Mreceiver (i.e. the
LUID, ack status code).
4.5 Maximum Transmission Unit
The underlying network protocol IP determines the Maximum
Transmition Unit (MTU). An implementation SHOULD allow the
application layer to set the protocol message maximum size. It is
recommended here to choose this value less or equal to the MTU in
order to avoid IP fragmentation. For this reason, MACP allows the
address descriptor extension into the announce message to be spanned
over multiple announces (see 6.7 and 7.2.3).
5 General Description
5.1 Transmission management
The Msender proactively sending announce messages initiates a MACP
controlled transmission. This is called the pure announce phase. The
Msender Local Unique Identifier (LUID) along with the Msender
assigned Transmission Identifier (TID) uniquely identifies the
transmission. It is not studied here how globally unique LUID:TID
identifiers are actually assigned by multiples Msenders. Upon
reception of an unknown LUID:TID announce, Mreceiver checks if it is
concerned with the announced transmission. If so, it creates a
LUID:TID context and launch an appropriate reception transport
protocol. This process is called the "announce filtering" and it may
Helal Expires January 2003 8
Multicast Announce and Control Protocol July 2002
be implemented in terms of targeted group description, content
description, and authentication.
During the data transport, Msender keep on sending the announce
message allowing additional Mreceivers to lately join the
transmission. New announces are defined as announces with the same
LUID:TID but modified payload. The "version number" field into the
message header indicates that the payload has been modified. This
allows Mreceiver to take into account only new announce messages.
Mreceiver MUST silently discard subsequent announces with the same
version number.
New announce may indicate that the ongoing transmission would be
lately joined (see the LATE bit into the option field). The time
when the transport cannot be joined anymore SHOULD be notified by
the Msender transport instance to the core component. Alternatively
it MAY be statically determined from the transport known behavior.
For instance some transport protocol sender implementations are
unable to send repair packets before a certain time window in the
past [6]. From that point Msender MUST stop sending announce message
(but may continue to send command messages, see hereafter) entering
into the pure transport phase.
Mreceiver maintains the current transmission status according to
transport notifications and possible timeout. At the end of the
transport (this arise generally when the Msender transport notify
that a predefined number of pass has been reached), Msender sends an
ECHO command query(see the command message) for Mreceivers final
status. The reason why MACP is used to get the final status is that
transport is supposed to be NORM. This means that the transport
sender implementation do not know how many receivers actually
received the content nor their individual address or identifier.
This MACP level acknowledge mechanism is denoted as explicit acking.
Msender may send command queries at any time during the
transmission. Commands may control Mreceiver protocol behavior (for
instance ask for a status message) or may correspond to external
process/commands to be invoked by the Mreceiver to process the
incoming data. Depending on the command, content may be processed
during transport of after the end of transport. In both cases,
Mreceiver MUST store and execute new commands corresponding to a
known LUID:TID context and silently discard unknown LUID:TID
command. In addition an implementation MAY allow more than one
command to be taken into account in a single transmission. In this
case Mreceiver MUST store new commands (that is a known LUID:TID
command with an increased value in the version number field) along
with the context. Mreceivers will execute command as soon as
transported incoming data allows it. Despite we allow multiple
commands in a single transmission, it is not studied how multiple
commands could process a given content changing its current content
type.
Helal Expires January 2003 9
Multicast Announce and Control Protocol July 2002
5.2 Configuration
MACP allows Msender to control public Mchannels that Mreceivers are
listening to. Msender initiates a configuration cycle by proactively
sending the listen message. This message holds a listen query, group
address descriptor and back channel informations. Listen messages
are thus assigned to dynamic groups defined by their individual
identifier or IP address.
Upon reception of a listen message corresponding to an unknown
LUID:TID, Mreceiver compares the address enumeration to its own
local addresses. If there is a match Mreceiver joins the provided
public Mchannel and start to apply provided content and address
descriptor criteria. A status may be sent in response at the Msender
option (see BACKCHANNEL bit into the listen option field).
This is useful for network configuration. For instance, at network
launch time, every Mreceiver is configured to listen to common
public Mchannel. Then depending on the applications, Msender may use
this Mchannel in order to tell to dynamic groups of Mreceivers to
join other public Mchannels.
5.3 Back-traffic management
With back channel, Mreceivers may send status message back to the
Msender in response to command query or listen query. This is done
at the Msender option (see BACKCHANNEL bit into option fields). The
command or listen message version number is copied into the status
message version number. When multiple commands are used, this allows
Msender to map responses to commands.
Because many Mreceivers may send explicit ack back to the Msender,
it is necessary to avoid Msender implosion. This is done through
Mreceiver random delay mechanism and Msender ack aggregation. Upon
reception of a new query message requiring a back status, Mreceivers
starts a timer for a random time between 0 and the "delay" field
value found into the command message. When the timer expires
Mreceiver sends the status message to the back address provided
within the command message. Msender aggregates explicit acks during
the overall time window. Please note that contrary to the NORM
transport, there is no place for a suppression mechanism here
because each explicit ack contains information specific to the
corresponding Mreceiver.
5.4 Multiple retransmissions for bulk data
MACP allows multiple retransmissions of the same bulk content
(multiple transmissions are not applicable to stream contents). Each
transmission / retransmission is considered as one transport "pass"
over the whole (or missing) content. For any NORM transport it is
needed to define a "end of pass" criteria. Actually NORM sender has
to keep on sending the content as long as it is experiencing some
nack coming back. Therefore a single non-working Mreceiver is
Helal Expires January 2003 10
Multicast Announce and Control Protocol July 2002
potentially able to slowdown dramatically the group transmission. We
assume here that the NORM sender implementation defines the "end of
pass" in some way. This used to be done by a threshold on the
overall sent information [15]. One can see from [3, 5] that there is
a natural way to define the end of transport as when the Msender do
not experiencing anymore nack coming back after a at least a
predefined number of round trip time (i.e. a predefined number of
FLUSH commands). We believe that the end pass criteria in NORM will
have to mix these two ideas.
In a single transmission, the unique transport "pass" is initiated
with an announce message where the LAST bit is set into the option
field. The Msender transport is invoked once. Please note that there
may be multiple transport "passes" herein but this is out of the
scope of this document.
In a multiple transmission, each transport "pass" is initiated with
an announce message where the bit LAST is unset into the option
field except for the last one. The Msender transport is re-invoked
many times with the same internal session ID making sure that it
actually reuse partially received data during subsequent passes. As
soon as the content is fully received (even if in a non last pass),
it is presented to the application layer. In case of pure push
transmission over DVB satellite asymetric networks (no back
channel), multiple retransmissions with a large delay in between may
be used against transmission weather blackouts.
In both case, forward error correction may be used whenever it is
available in the NORM transport implementation.
5.5 Context managements
Data transport and network configuration contexts are managed
differently:
Each time an announce message with an unknown LUID:TID identifier is
received the Mreceiver creates a context that rely on the LUID:TID
value. The expected maximal session duration is provided into the
"Life Time" field. The Mreceiver stores this value along with the
context. This allows some garbage collector process to destroy old
contexts. This means that as long as the context exists (i.e. during
the lifetime), Msender may query the current status at any time
through the ECHO command query. After the lifetime, the context is
destroyed and LUID:TID value may be reused by the Msender. Since the
lifetime may be larger that the transmission time, it is possible
for the Msender to send commands after the end of the transmission.
This allows the sender upper application layer to trigger processing
of the incoming contents by receivers upper application layer.
During lifetime, Mreceiver maintain a status code according to
protocol current operation.
Each time a listen message with an unknown LUID:TID identifier is
received the Mreceiver processes the listen query immediately. This
Helal Expires January 2003 11
Multicast Announce and Control Protocol July 2002
means that there is no corresponding context to be stored at the
Mreceiver except the LUID:TID value itself.
5.6 Group Address Description
Msender enumerates Mreceiver identifiers concerned with the
transmission into the announce message and listen messages as
initially proposed in [15]. This enumeration allows Msender to
manage dynamic groups of receivers since Mreceiver may apply filter
to the address descriptor based on its own local identifier or
address prior to accept the transmission.
In case of large dynamic groups of receivers, Msender implementation
MUST span the enumeration over multiple announce messages. Msender
uses this possibility in order to avoid announce message to become
larger than the underlying MTU causing IP to fragment.
Note: In a previous release of the draft this enumeration was
provided into a separate message thus increasing the number of
identifiers held into a single message. However this resulted in an
increased complexity of the code detecting new announce at the
Mreceiver.
5.7 Content Description
Msender provides the content description as a session description
(SD) [4] and up to five ASCII keywords. Media use AV profiles (audio
video) or experimental profiles (bulk data). These new profiles are
defined for bulk static data, bulk file data, and stream ordered
data. Parameters values are defined in binary formatted messages in
section 6 for filtering efficiency. SD Attributes are defined in
ASCII in order to allow MACP to convey values opaque to it as in
[4].
5.8 Registering
MACP allows Mreceivers to register when joining the transmission at
the Msender option. This is done by intermixing announce and ECHO
command query during the pure announce phase. As far as very long-
term transmissions are concerned, this allows Msender to wait for a
given amount of receivers registered before to actually start the
transport. The late joining option may be used accordingly whenever
the transport supports it. On the opposite, when many small contents
are distributed at a time, MACP allows to not register in order to
speed up the pure announce phase.
5.9 Confidentiality
MACP provides data confidentiality through encryption mechanism into
the MACP messages common header. This is done according to OpenPGP
[8]:
Helal Expires January 2003 12
Multicast Announce and Control Protocol July 2002
o Msender generates an announce session key as a random number for
each new message to be sent (Announce, Command and listen message)
o Msender encrypts the announce session key with a symetric key
derived from a shared secret between Msender and Mreceivers
o Msender builds the common header providing the encrypted announce
session key
o Msender encrypts the payload by using the announce session key and
happens it to the common header.
A symmetric key encryption is preferred here to a public key
algorithm since it may not be desirable for many Mreceiver to share
a "so-called" Msender private key.
It is considered to be sufficient for an implementation to use
encryption only for messages flowing from the Msender to Mreceivers
(that is announce, command and listen messages). Announce message
holds an optional transport session key that may be passed to the
(NORM) transport protocol. Whenever the transport has the capacity
to scramble data confidentiality is provided. In addition MACP
provides support for changing the transport session key dynamically.
5.10 Authentication
MACP defines authentication data into announce and listen messages.
This allows the application layer to filter incoming announce from
trusted Msender only. This is done according to OpenPGP [8]:
o Msender generates a hash from the message payload
o Msender happens a signature of the hash code
Again authentication data are provided only into messages flowing
from the Msender to Mreceivers. This time a public key mechanism is
preferred since a private key holders are Msenders.
6 Message description
6.1 Common Header
All MACP message contain the following common Header.
0 7 15 31
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type | |KeySize| VersNum | MsgNum |
+-------------------------------------------------------------+
| Source Local Unique Identifier |
+-------------------------------------------------------------+
| Transmission Identifier |
+-------------------------------------------------------------+
Helal Expires January 2003 13
Multicast Announce and Control Protocol July 2002
| EncryptedSessionKey |
+-------------------------------------------------------------+
| Payload |
+-------------------------------------------------------------+
Protocol Header Format
The "Version" field indicates the protocol version. It is intended to
distinguish upgrades in the protocol which may be non interoperable.
A MACP implementation MUST check this field to know if it supports
the protocol version and ignore the message if it does not. In
present experimental release this field should be set to 1.
The "Type" field indicates the nature of the information in the
payload. It takes one of the following values corresponding to
messages described later:
ANNOUNCE 0
COMMAND 1
STATUS 2
LISTEN 3
UNLISTEN 4
The "KeySize" field indicates the encrypted key size. For now, this
bit is always set to 0 (no encryption).
The "VersNum" field is incremented by the Msender each time the
content in the payload changes. This may arise within a transmission
where multiple suspend resume cycles occur or when the Msender send
commands to Mreceivers. This may also arise when a large list of
Mreceivers has to be span over more than one message (see the address
descriptor extension). When responding to a command query, Mreceiver
MUST recopy this field into the VersNum field of the status message
header.
The "MsgNum" field is incremented by the Msender each time a new copy
of the message is sent. Msender and Mreceiver must use this field
only when redundantly sending a given message over UDP for
robustness. Otherwise this field must be ignored (back traffic over
TCP).
The "Source Local Unique Identifier (LUID)" field is the source node
Logical Unique Identifier of the host sending the message.
The "Transmission ID (TID)" field uniquely identifies the
transmission for the Msender scope. It is not studied here how
multiple Msenders have to coordinate in order to avoid TID collision
in the many to many model. Rather LUID:TID is assumed to be globally
unique.
The "EncryptedSessionKey" field contains the session key that is
needed to decrypt the payload content. It has to be decrypted from a
Helal Expires January 2003 14
Multicast Announce and Control Protocol July 2002
shared secret and a symmetric algorithm. For now this field is not
implemented, as the corresponding size is 0.
The "payload" field corresponds to messages described hereafter.
6.2 Announce message
This message initially flows from the Msender to Mreceivers through
the public Mchannel. If the LUID:TID do not correspond to a known
context and if there is chance to receive a full content (see
PARTIAL and LASTDIFF bits in the option field hereafter), Mreceivers
MUST create a new LUID:TID context that rely on the LUID and TID
combination.
0 7 15 31
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | SignSize |
+-------------------------------------------------------------+
| Authentication |
+-------------------------------------------------------------+
| Trp |Nmedia | Lifetime | KeyBaseIndex |
+-------------------------------------------------------------+
| Media Address 1 |
+-------------------------------------------------------------+
| Media Port1 |NLay1|I|DKsize | Format1 |
+-------------------------------------------------------------+
| Data Key 1 |
+-------------------------------------------------------------+
| Media Address 2 |
+-------------------------------------------------------------+
| Media Port2 |NLay2|I|DKsize | Format2 |
+-------------------------------------------------------------+
| Data Key 2 |
+-------------------------------------------------------------+
| ... |
+-------------------------------------------------------------+
| Media Address n |
+-------------------------------------------------------------+
| Media Portn |Nlayn|I|DKsize | Formatn |
+-------------------------------------------------------------+
| Data Key n |
+-------------------------------------------------------------+
| Group Descriptor extension (see 6.7) |
+-------------------------------------------------------------+
| Content Descriptor extension (see 6.7) |
+---------------+---------------------------------------------+
|TrpAttSet sise | TrpAttSet |
+---------------+ |
| ... |
+-------------------------------------------------------------+
The "Option" field is a bit field indicating the following:
Helal Expires January 2003 15
Multicast Announce and Control Protocol July 2002
PARTIAL 0x001
LASTDIFF 0x002
BACKCHANNEL 0x004
LIVE 0x008
OVERWRITE 0x010
TRANSPORT 0x020
LATE 0x040
CNTEXT 0x080
GRPSEXT 0x100
SPANLIST0x200
PARTIAL: When LIVE bit is 0, this bit indicates that the Msender will
provide only a portion of the content. Msender MUST set this bit when
issuing new announce for a previously suspended transmission. When
LASTDIFF is also set, Mreceiver MUST accept the announce only for a
known LUID:TID. Upon reception of a new announce for a previously
suspended transmission, Mreceiver MUST restart the life time count
and re-enable transport timeout notification actions. When LIVE bit
is 1 Msender MUST set this bit to 0 and Mreceiver MUST ignore it.
LASTDIFF: When LIVE bit is 0, this bit indicates that the Msender
will provide the last diffusion of the content. Msender MUST set this
bit during the last transmission of the content (see PARTIAL for
Mreceiver behavior). When LIVE bit is 1 Msender MUST set this bit to
0 and Mreceiver MUST ignore it.
BACKCHANNEL: Indicates to Mreceivers that they may be queried for
this transmission through subsequent command message. Msender MUST
set this bit to the same value in every announce messages in the
transmission. Upon reception of an unknown LUID:TID announce, and if
transmission is accepted, Mreceivers MUST launch the appropriate
receiver transport protocol with the back channel activated. Then
Mreceivers MUST maintain the current transmission status as known
from their receiver transport and/or possible processed external
commands. In particular when a Mreceiver decline to participate to
the transmission for some reason, it has to store this reason in case
of further status query received from the Msender.
LIVE: Indicates to Mreceiver that the content is continuously
available during transport and that it is no longer available after.
This means that as soon as the transport is launched, the Mreceiver
application upper layer may use the content. Msender MUST set this
bit when announcing a streamed content (i.e. real time data or
ordered object collection) and unset this bit when announcing bulk
data content (i.e. file or static RAM data). This information is to
be transmitted at the Mreceiver application layer. For instance in
case of real time streamed content through RTP [9], the Msender will
set the LIVE bit. Mreceivers upper layer application may create a
temporary RTSP redirection file [11] immediately after the transport
launch time (this temporary file would exist during transmission
only). On the opposite, in case of a bulk data content, Msender unset
Helal Expires January 2003 16
Multicast Announce and Control Protocol July 2002
the LIVE bit. Mreceiver upper layer may use the received file or
static RAM in its final destination only after the end of transport.
OVERWRITE: When the LIVE bit is 0, this bit indicates to MReceivers
that the content has to be overwritten. Upon reception of an unknown
LUID:TID announce with OVERWRITE, Mreceiver MUST remember to
overwrite the existing file or static RAM as soon as the content is
fully received by the transport. If OVERWRITE is set and Mreceiver
has no privilege on the remote host computer (file system or locked
RAM), or if OVERWRITE is not set and the object already exists (same
RAM handle, same destination file name), Mreceiver MUST decline the
transmission. If the BACKCHANNEL bit is set too, Mreceiver MUST store
the associate reason code (see status message). If LIVE bit is set
Msender MUST set this bit to 0 and Mreceiver MUST ignore it.
TRANSPORT: When set this bit indicates to Mreceivers that the
transport is running (the "pure" announce phase has ended). During
each transmission, Msender must initially set this bit to 0 during
the pure announce phase. Then as soon as the transport has been
launched, it must send new announce for the same LUID:TID with this
bit set (and modified VersNum in the header). Upon reception of an
announce with this bit unset (either unknown or new valid case of a
subsequent re transmission or RESUME announce), the Mreceiver MUST
synchronize to the transmission. Upon reception of a new announce
with this bit set, Mreceiver MUST synchronize to the transmission
only if the LATE bit is set too and decline otherwise. If the
BACKCHANNEL bit is set, the corresponding (TOOLATE) reason code must
be stored.
LATE: When set this bit indicates that Mreceivers are allowed to
lately join the transmission. Msender MUST set this bit only for
transport having the late join capacity and only during the
appropriated time window. Since only a few late joiners could slow
down the transmission, Msender may use this bit to forbid late
joining from some point. The point from which Msender must change the
LATE bit state to 0 is ideally notified by the NORM transport. Please
note that whenever the NORM transport uses an estimated round trip
time (RTT), it should notify MACP one half RTT before.
GRPEXT: when set this bit indicates that a group descriptor extension
field is present into the announce message.
CNTEXT: when set this bit indicates that a content descriptor
extension field is present into the announce message.
The "SignSize" field provides the size of the "Authentication" field.
For now, this field is always set to 0.
The "Authentication" field contains a digital signature as defined in
[8]. For now, this field is not used as SignSize is equal to 0.
The "Trp" field indicates the transport name. A common transport name
is provided for every following media descriptions in the announce
Helal Expires January 2003 17
Multicast Announce and Control Protocol July 2002
message. Multiple media are allowed only for the RTP transport. This
correspond to the audio video profiles according to [9] where Trp
take the "RTP/AV" value. For now the possible values for the "Trp"
field are listed in the following table. Other values may be added in
the future. New values SHOULD include version information in order to
ensure transport protocol compatibility.
VFDPV2/BLK 0x0101 File transfer
MDPV2/BLK 0x0201 File or Static RAM transfer
NORM/BLK 0x0301 File or Static RAM transfer
MDPV2/STREAM 0x0202 Ordered collection
NORM/STREAM 0x0302 Ordered collection
RTP/AV 0x0403 Real-Time audio video
The "NMedia" field indicates the number of media conveyed
simultaneously. Each media corresponds to a NORM transport instance
working on a single Mchannel. For bulk data and ordered collection
transfers Msender implementation MUST use NMedia = 1. For real time
streaming (Trp = RTP/AV) Msender implementation MAY use a value
greater than 1 when multiple audio video have to be transported
simultaneously. Subsequent media description fields are denoted as
"Media Address <n>", "Media port <n>, "Media NLayer <n>" and "Media
Format <n>" hereafter.
The "Lifetime" field provides the maximum time in hours the
transmission will last. Msender must set this field to the estimated
remaining transmission time upper bound (that is the overall
transmission time including possible suspend resume cycles).
Initially Msender set the lifetime to the expected final transmission
time. Then when a transport is launched or resumed, Msender SHOULD
provide new estimated transmitted time upper bound in subsequent new
announces. Upon reception of a new announce, Mreceiver computes the
transmission final time from this field and stores it along with the
LUID:TRID context. Some garbage collector process at the Mreceiver
destroys expired transmission contexts. In case of infinite
transmission (streaming), Msender MUST periodically send new
announces to setup the time upper bound.
The KeyBaseIndex is intended for future NORM transports having the
capability to change the encryption key on the fly. It contains an
increasing 16 bits index from which the provided data keys are
applicable. Msender MUST provide a new index value and send a new
announce message prior to use new data key. Upon reception of a new
announce with a modified data key, Mreceiver MUST pass the new key
and inform the NORM transport to use it from the index in some way.
Note that the index value has a signification to the NORM transport
only. It is assumed that 16 bit are sufficient. For instance in the
case of NORM [3] the KeyBaseIndex MIGHT be calculated as the 16 bits
least significant part of the segment number. For now this value MUST
be set to 0.
The "Media address <n>" and "Media port <n>" fields together provide
the base address and port for media <n>. For all transport types
Helal Expires January 2003 18
Multicast Announce and Control Protocol July 2002
except RTP/AV there exists only one media description (i.e. the
Mchannel). For RTP/AVP profile, there may be multiple media
description. In case of hierarchical encoding, these two fields
represent the base address/port for multiple layers.
The "NLay<n>" field represent the number of layers for media <n>.
According to the RTP/AV profile in [9] each layer correspond to an
RTP/RTCP pair of UDP ports. The ports are implicitly incremented by
two for each layer. According to [9] it is possible to assign layers
to different multicast addresses rather than to different even ports
for filtering unnecessary traffic purpose (see the "I" bit
hereafter). Contrary to [9] there is no media name for each media.
Nlay<n> is encoded by 3 bits for 8 layers at most.
The "I" bit is to be considered only when multiples layers are used
for this media (Nlay<n> > 1). When set it indicates that subsequent
layers channels are found by increasing by one the base media
address. When unset it indicates that subsequent layers are found by
increasing by two the base Media port (each layer corresponding to a
RTP/RTCP port pair).
The DKsize <n> represent the size for the Data Key field for media n.
This value is expressed in bytes from 0 to 3 allowing up to 32 bits
keys for data content. For now, this field must be set to 0.
The "Format <n>" field represent the format according to [12] for the
RTP/AV transport. For others transport types, this value MUST be set
to 0.
The "Data Key <n>" is the session key to be used for content
encryption. This key is 32 bits at most . Contrary to SD [4] it is
not obtained from a pass phrase at the Mreceiver side. For know, it
SHOULD be set to 0.
The "Group descriptor extension" is described in subsequent paragraph
6.7. This field exists for filtering purpose only when the GRPEXT bit
is set into the OPTION field.
The "Content descriptor extension" is described in subsequent
paragraph 6.7.This field exists for filtering purpose only when the
CNTEXT bit is set into the OPTION field.
The "TrpAttSet size" and "TrpAttSet" fields are receiver transport
specific parameter that has to be passed at launch time. This may
concern for instance receiver cache buffer size, or rtpmap attribute
as define in [9] . For each parameter, syntax must be in ASCII text
of the form "Param=Value" terminated with a CRLF sequence (allowing
to set multiple parameters for each media. The overall size MUST be
equal to TrpAttSet size.
6.3 Command message
Helal Expires January 2003 19
Multicast Announce and Control Protocol July 2002
This message flows from the Msender to Mreceivers through the public
Mchannel. Msender MAY issue it along with the announce message. This
message holds a command query destined to every Mreceiver
participating to the transmission and back channel information. If
the LUID:TID correspond to a known context Mreceiver MUST execute
the command, or silently discard it otherwise.
0 7 15 31
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Cmd | Fmt | SignSize |
+-------------------------------------------------------------+
| Authentication |
+-------------------------------------------------------------+
| Back Channel extension (see 6.9) |
+-------------------------------------------------------------+
The "Options" field indicates the following:
BACKCHANNEL 0x01
TCP 0x02
BACKEXT 0x04
BACKCHANNEL: When set this bit indicates that Msender asks for a
status message in response to the query.
TCP: This bit indicates that Mreceivers must send status messages
back to the return address through TCP/IP. In this case a single
message MUST be sent in response to each command (MsgNum field is set
to 0 into the header). When Msender unset this bit, Mreceivers must
send status message back through UDP either in multicast or unicast
depending on the return address and port fields provided. Mreceiver
MUST redundantly send a given number of status messages with the same
payload and with the MsgNum field increased by one in each of them.
Generally Msender will use the TCP along with transport protocol
using TCP over the back channel.
BACKEXT: This bit indicates that the message contains a back channel
descriptor as described in 6.9.
The "SignSize" field provides the size of the "Authentication" field.
For now, this field is always set to 0.
The "Authentication" field contains a digital signature as defined in
[8]. For now, this field is not used as SignSize is equal to 0.
The "Cmd" field holds the command query. The command applies to the
LUID:TID context. The Msender MAY set this field to one of the
following values as soon as the transport has been launched.
ABORT 1
SUSPEND 2
ECHO 3
Helal Expires January 2003 20
Multicast Announce and Control Protocol July 2002
PLAY 4
SYNCPLAY5
KILL 6
ABORT: Msender tells Mreceivers to abort the transmission. Upon
reception of a ABORT command corresponding to a new LUID:TID context,
Mreceiver MUST ignore the announce. Upon reception of a new command
with ABORT, Mreceiver MUST stop the running transports and possible
running MIME associated application (see PLAY and SYNCPLAY commands).
Mreceiver MUST keep track of the LUID:TID context in order to avoid
that possible subsequent announce message (udp) re-creates the
context. If the BACKCHANNEL bit is set, Mreceiver MUST send back an
ABORT status message to one of the provided addresses (see below). If
the transport notified the end of content reception first, Mreceiver
MUST send a ACK status message instead.
SUSPEND: Msender tells Mreceivers to suspend the transmission.
Msender MAY issue this command only for transports having the
capacity to suspend transmission. This is the case for [3,5] and [14]
implementations. Upon reception of a SUSPEND command corresponding to
a new LUID:TID context, Mreceiver MUST ignore the command. Upon
reception of a SUSPEND command corresponding to a known LUID:TID,
Mreceiver must stop the life time timer and ignore subsequent
transport time out notification. If the BACKCHANNEL bit is set,
Mreceiver MUST send back a SUSPEND status message. If the transport
notified the end of content reception first, Mreceiver MUST send a
ACK status message instead. If the transport do not have the capacity
to suspend reception, Mreceiver MUST send a NACK status message with
the ERROR reason code.
ECHO: Msender tells Mreceivers to echo their status. Upon reception
of such a message corresponding to a new LUID:TID context, Mreceiver
MUST ignore the command. Upon reception of a new announce with ECHO
and if the BACKCHANNEL bit is set into the option field, Mreceiver
retrieves the current reception status and echo it into a status
message. Msender MAY use the ECHO command query prior to launch the
transport. In that case, Mreceiver may receive or decline the
transmission.
PLAY: Msender tells Mreceivers to run the MIME associated application
with the content as input. If the LIVE bit is set into the option
field, Mreceiver MUST execute the application upon reception of the
message and set the transmission status code to EXECUTE with reason
code OxFFFF. If the BACKCHANNEL bit is set, Mreceiver MUST send back
a EXECUTE status message. One example of PLAY command is a Msender
controlling launch of appropriate content players on Mreceiver (for
instance real player or microsoft power point for remote automated
presentation).
SYNCPLAY: Msender tells Mreceivers to run MIME associated application
with the content as input and wait for the process termination, the
status code being set to EXECUTE. At the end of the process,
Mreceiver must retrieve the process return code and place it into the
Helal Expires January 2003 21
Multicast Announce and Control Protocol July 2002
reason code. If BACKCHANNEL bit is set, Mreceiver MUST return the
EXECUTE status code or if the MIME associated application is not
found the SYSTEM status code. One example of SYNCPLAY command is a
Msender controlling decompression of an archived content (for
instance with the gzip utility)
KILL: Msender tells Mreceivers to destroy possible MIME associated
application running. Mreceiver MUST keep track of the LUID:TID
context in order to avoid that possible subsequent announce message
re creates the context. If the BACKCHANNEL bit is set, Mreceiver MUST
send back a KILL status message. If the transport notified the end of
content reception first and no PLAY command have been received, or if
a MIME associated application has terminated before, Mreceiver MUST
send ACK EXECUTE status message instead respectively.
The "Fmt" field gives the representation of each host address. It
takes one of the following values (see 6.7):
LUID 0x0001
INET 0x0002
6.4 Status Message
This message flows back from Mreceivers to Mserver through the
upstream private channel. Mreceiver MUST send it in response to a
command message where the BACKCHANNEL option bit is set.
0 7 15 31
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code | Reason | delay |
+-------------------------------------------------------------+
| delay0 | NbHosts |
+-------------------------------------------------------------+
| PacketSize |
+-------------------------------------------------------------+
| TotalPackets |
+-------------------------------------------------------------+
| NackedPackets |
+-------------------------------------------------------------+
| UnusedPackets |
+-------------------------------------------------------------+
| HostList |
+-------------------------------------------------------------+
The "Status Code" field may take one of the following values:
DECLINE
RECEIVE
ACK
NACK
EXECUTE
ABORT
Helal Expires January 2003 22
Multicast Announce and Control Protocol July 2002
DECLINE: this status code indicates the Mreceiver do not participate
to the announced transmission. Mreceiver MUST return this status
code to an ECHO query when it decline the transmission (see reason
codes for possible situations).
RECEIVE: this status code indicates that the Mreceiver is currently
waiting or receiving the content. Mreceiver must return this status
code to an ECHO query during transport. The "Reason" field MUST be
set to 0
ACK: this status code indicates that the Mreceiver correctly
received the content. Mreceiver must return this status code to an
ECHO query after the end of transport under normal condition. The
"Reason" field MUST be set to 0
NAK: this status code indicates that the Mreceiver did not receive
the content after the end of transport. Mreceiver must return this
status code to a ECHO query after the end of an uncompleted
reception. The "Reason" field provides additional information.
EXECUTE: this status code indicates that the Mreceiver is currently
executing the MIME associated application. The reason field provides
the return code of the MIME associated application or 0xFF if it is
still running.
ABORT: this status code indicates Mreceiver aborted the
transmission. Mreceiver MUST return this status code to an ABORT
query.
The "Reason" field may take one of the following values. It is set
to a non 0 value when Status = DECLINE, NACK or EXECUTE:
if Status = DECLINE
PRIVILEGE
LACK
TOOLATE
EXIST
MEMORY
SYSTEM
ERROR
if Status = NACK
PRIVILEGE
TOOLATE
TIMEOUT
MEMORY
TRANSPORT
SYSTEM
ERROR
Helal Expires January 2003 23
Multicast Announce and Control Protocol July 2002
if Status = EXECUTE
SYSTEM
ERROR
<Mime associated application return code>
'FF'
PRIVILEGE: Mreceiver has no administrative rights for overwriting or
moving the file in its final destination, or unlock ram storage
location.
PARTIAL: Mreceiver is unable to recreate the content from the
partial & last retransmission because it lacks cached data.
TOOLATE: Mreceiver is not authorised to receive data because the
pure transport phase has began.
EXIST: Mreceiver is unable to create the file or ram content because
the filename exists into the local file system or the ram identifier
exists and the OVERWRITE option is not set.
MEMORY: Mreceiver is unable to create the file or ram content
because there is not enough available storage resource.
SYSTEM: Mreceiver detected a system failure (file error, MIME
associated application not found).
ERROR: Mreceiver detected a protocol error.
TIMEOUT: Mreceiver transport detected time out condition before the
end of end of transport.
TRANSPORT: Mreceiver detected end of transport without complete
content reception.
The "delay" field is a copy of the value into the corresponding
announce. This field is intended for possible future explicite ack
aggregation done at a different host than the Msender. It allows
such an host to predict the overall aggregation time windows upon
reception of the first ack (see also delay0).
The "delay0" field is the actual random value choosen by the
Mreceiver before to send the message. This field may be used to
predict the aggregation time window (see also delay).
The "NbHosts ", "HostList" field is used to provide the identifiers
of the Mreceivers. For now NbHosts is always 1. The host list
possibility is intended for future hierarchical aggregation process.
The ôPacketSizeö Field is the packet size used by the transport. It
is provided into the status message for future proxy aggretation.
Helal Expires January 2003 24
Multicast Announce and Control Protocol July 2002
The ôTotalPacketö Field is the expected number of packets without
loss.
The "LossPacket" field provides the number of packets nacked by that
host. In case of NACK status, this value is not considered. In case
of perfect reception, this value is 0. Mreceiver retrieves this
value from the transport protocol instance upon termination whenever
possible. Otherwise it MUST be set to 0.
The "UnusedPacket" field provides the number of packets
retransmitted by the Msender but not nacked by that host. In case
that no unnecessary retransmission detected this value is set to 0.
Mreceiver retrieves this value from the transport protocol instance
upon termination whenever possible. Otherwise it MUST be set to 0.
Note that when the transport uses forward error correction, the
minimum value for this field corresponds to the proactive ratio.
The ôHostListö field is used to provide the identifier of receivers.
For now NbHosts is always 1. The host list possibility is intended
for future hierarchical aggregation process.
6.5 Listen Message
This message is intended to let Msender inform Mreceivers to operate
on a new public Mchannel. Targeted Mreceivers are described by a
never spanned HostList. If the LUID:TID do not correspond to a known
context Mreceivers MUST take the message into account. That is joint
the provided Mchannel and set filter criteria. Otherwise Mreceiver
MUST ignore it. Mreceiver MUST respond to this message with a Listen
status message according to the ôOption fieldö (see BACKCHANNEL
bit).
0 7 15 31
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Query | | SignSize |
+-------------------------------------------------------------+
| Authentication |
+-------------------------------------------------------------+
| Group Descriptor extension (see 6.7) |
+-------------------------------------------------------------+
| RxInterface |
+-------------------------------------------------------------+
| TxInterface |
+-------------------------------------------------------------+
| Public Address |
+-------------------------------------------------------------+
| Public port | NKeyWordCriteria |
+-------------------------------------------------------------+
|Criteria1 size | Criterium 1 |
+---------------+ |
| ... |
+-------------------------------------------------------------+
Helal Expires January 2003 25
Multicast Announce and Control Protocol July 2002
|Criteria2 size | Criterium 2 |
+---------------+ |
| ... |
+-------------------------------------------------------------+
| ... |
+-------------------------------------------------------------+
|Criteria5 size | Criterium 5 |
+---------------+ |
| ... |
+-------------------------------------------------------------+
| Back Channel Extension (see 6.9) |
+-------------------------------------------------------------+
The "Option" field is a bit field indicating the following:
BACKCHANNEL
TCP
GRPSEXT
BACKCHANNEL: Indicates to Mreceivers that they have to send a listen
status message back to the Msender.
GRPEXT: when set this bit indicates that a group descriptor extension
field is present into the listen message. When unset this bit
indicates that any Mreceiver MUST take the message into account.
TCP: This bit indicates that Mreceivers must send status messages
back to the return address through TCP/IP (see 6.3).
The "Queryö field takes one of the following values
LISTEN
UNLISTEN
PING
LISTEN: tells Mreceivers to join the new public Mchannel and set the
provided content filter criteria. If the BACKCHANNEL bit is set into
the option field, Mreceiver MUST return a listen status message back
to the Msender. If the Mchannel was not already listened too,
Mreceiver MUST set the status code to NEW. If it was, Mreceiver MUST
ask the upper layer to re-apply the provided content descriptor
criteria and set the status code to REPLACE if successful. Otherwise,
the status code MUST be set to NOK, the reason code providing
appropriate additional information (see hereafter).
UNLISTEN: tells Mreceivers to leave the public Mchannel. If the
BACKCHANNEL bit is set into the option field, Mreceiver MUST return a
listen status message back to the Msender. If the Mchannel was
listened too, Mreceiver MUST set the status code to OK, otherwise it
MUST set the status code to NULL. If the provided network interface
do not exist, Mreceiver MUST set the status code to NOK with the
appropriate reason code.
Helal Expires January 2003 26
Multicast Announce and Control Protocol July 2002
PING: tells Mreceiver to return a listen status message only (if the
BackChannel bit is set into the option field). This operation is
intended for Mnetwork exploration purpose.
The "SignSize" field provides the size of the "Authentication". For
now, this field is always set to 0.
The "Authentication" field contains a digital signature as defined in
[8]. For now, this field is not used as SignSize is equal to 0.
The "Group descriptor extension" is described in paragraph 6.7. This
field exists for filtering purpose only when the GRPEXT bit is set
into the OPTION field. The group descriptor extension is never
spanned over multiple Listen messages.
The "RxInterface" field is the IP V4 network interface to be used for
joining Mchannel. The ô0.0.0.0ö value may be used in order to
indicate any interface.
The "TxInterface" field is the IP V4 network interface to be used for
back traffic. The ô0.0.0.0ö value may be used to indicate any
interface.
The "Public Address" and "Public port" are the Mchannel to ear for.
The ôNKeyWordCriteriaö is the number of keywords criteria to be set
for content filtering. When there will be no content filtering for
the new Mchannel, Msender MUST set this field to 0. The maximum value
is 5.
The "Criteria<n> size" and "Criteria<n>" fields are ASCII string to
be used by the Mreceiver upper layer for setting content filters.
Please note that the syntax for setting this criteria is unknown to
the MACP protocol. Mreceiver implementation SHOULD use some call back
mechanism for passing incoming new content description to the upper
layer for filtering unknown announce. Each criteria string size MUST
be less or equal to 100.
The ôBack Channel extensionö field is described in 6.9
6.6 Listen Status Message
This message flows back from Mreceivers to Mserver over the upstream
private channel. Mreceiver MUST send it in response to a listen
message where the BACKCHANNEL option bit is set.
0 7 15 31
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code | Reason | delay |
+-------------------------------------------------------------+
| delay0 | NbHosts |
+-------------------------------------------------------------+
Helal Expires January 2003 27
Multicast Announce and Control Protocol July 2002
| HostIdentifier1 |
+-------------------------------------------------------------+
| NumberOfChannels1 | PublicPort11 |
+-------------------------------------------------------------+
| PublicAddress11 |
+-------------------------------------------------------------+
| PublicPort12 | PublicAddress12 |
+-------------------------------------------------------------+
| (continuation) | PublicPort3 |
+-------------------------------------------------------------+
| . . . . |
+-------------------------------------------------------------+
| PublicPort1n | PublicAddress1n |
+-------------------------------------------------------------+
| (continuation) |
+-------------------------------+ |
The "Status Code" field may take one of the following values:
NEW
REPLACE
NOK
OK
NEW: this status code indicates that the Mreceiver now have joined
the Mchannel and placed content descriptor filter criteria in
response to a LISTEN query.
REPLACE: this status code indicates that the Mreceiver replaced the
descriptor filter criteria on a previously listened Mchannel in
response to a LISTEN query.
NOK: This status code indicates that the Mreceiver was unable
execute the LISTEN query. If the host was unable to join the
Mchannel on the provided RxInterface, the reason code MUST be set to
ERRJOIN. If the upper layer informed that it was not able to check
the provided content criteria reason code MUST be set to ERRFILTER.
If the RxInterface do not exist reason code MUST be set to
ERRINTERFACE.
OK: This status code indicates that the Mreceiver executed the
UNLISTEN query.
NULL: This status code indicates that the Mreceiver did have to
execute the UNLISTEN query because the Mchannel was not joined.
The "Reason" field may take one of the following values. It is set
to a non 0 value when Status = NOK:
ERRJOIN
ERRINTERFACE
ERRCRITERIA
Helal Expires January 2003 28
Multicast Announce and Control Protocol July 2002
ERRJOIN: Mreceiver is unable to join the provided Mchannel on the
provided network interface.
ERRINTERFACE: The provided interface do not exist.
ERRFILTER: The upper layer is not able to apply the provided content
descriptor criteria.
The "delay" and ôdelay0ö fields have the same meaning as for the
transmission status message
The "NbHosts " provides the number of Mreceivers concerned with the
listen status message. For now NbHosts is always 1. High values
possibility is intended for future hierarchical aggregation process.
The "NumberOfChannel1" field provides the number of Mchannels
listened to by the Mreceiver sending the Listen message. Mreceiver
MUST set this field only in response to a PING query.
The "PublicAddress<n>" and "PublicPort<n>" provides the Mchannel "n"
for Mreceiver. This fields MUST be set by Mreceiver only for a PING
query.
6.7 Group Descriptor extension
This extension holds the list of addresses or identifiers of
Mreceivers that are concerned with the announced transmission. Upon
reception of an unknown LUID:TID announce with this extension,
Mrreceiver MUST check if its local address matches one element of
the list.
If the address list is such that the announce message is larger
larger than one MTU, Msender upper layer SHOULD span the address
list over multiple announce messages, changing the VersNum into the
announce message header. But Msender upper layer MAY also use an
announce message larger than the MTU allowing the IP layer to
fragment. However this is discouraged in the case of UDP/IP
0 7 15 31
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAddress | Format | BaseIndex |
+---------------+---------------------------------------------+
| Host Address |
+-------------------------------------------------------------+
| Host Address |
+-------------------------------------------------------------+
| ... |
+-------------------------------------------------------------+
Helal Expires January 2003 29
Multicast Announce and Control Protocol July 2002
The "NAddress" field is the number of following Host Address. Note
that if more than 256 hosts are targeted, Msender MUST span the
address list over multiple announces.
The "Format" field gives the representation of each host address. It
takes one of the following values:
LUID 0x01
INET 0x02
LUID indicates that each host address is provided as a (32 bits)
LUID.
INET indicates that each host address is provided as a (32 bits) IPv4
address.
The "BaseIndex" field provides the first index of the provided Host
list portion. Msender MUST set this value the to index value of the
first Host Address when the host list is spanned over multiple
announce messages. Mreceiver do not use this field.
Each "Host Address" field represents one host address of the targeted
group. Upon reception of a new announce message with EXTADDRESS bit
set in the option field, Mreceiver must check if the local Address
match one of these host addresses. The address filter is applied on
the LUID or on the local IP interface address depending on the Format
field value. With INET format and for multi-homed hosts, Mreceiver
SHOULD compare each Host address field value to every local IP
interface addresses.
6.8 Content Descriptor extension
0 7 15 31
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NkeyWord | reserved | |
+-------------------------------+ |
| Content Size (48 bits) |
+-------------------------------------------------------------+
| Type size | MimeType |
+---------------+ |
| ... |
+-------------------------------------------------------------+
| SubT size | Mime Subtype |
+---------------+ |
| ... |
+-------------------------------------------------------------+
| Name size | Destination name (option) |
+---------------+ |
| ... |
+-------------------------------------------------------------+
| Path size | Destination path (option) |
+---------------+ |
Helal Expires January 2003 30
Multicast Announce and Control Protocol July 2002
| ... |
+-------------------------------------------------------------+
| Kw1 size | Key Word 1 |
+---------------+ |
| ... |
+-------------------------------------------------------------+
| Kw2 size | Key Word 2 |
+---------------+ |
| ... |
+-------------------------------------------------------------+
| Kwn size | Key Word n |
+-------------------------------------------------------------+
The "NKeyWord" field gives the number of subsequent keywords. The
maximum value SHOULD not be greater than 5.
The "Content size" field is intended to allow Mreceiver to known
about the amount of required storage for bulk data content only
(option field LIVE bit is 0). It is provided for information or
future content selection only because the NORM transport protocol
manages the size announcement and provides storage reservation
mechanisms itself. Mreceiver SHOULD use this field to inform the
upper layer or for filtering purpose. Please note it SHOULD not be
necessary for the Mreceiver to check and lock the available disk or
RAM space from the Content Size retrieved value. Rather, the
transport protocol MUST do this job.
The "Type size" and "Mime type" provides the content MIME type. MIME
Type MAY be used to automatically start the MIME associated
application on the host system. Mime type size must be less or equal
to 19.
The "Subtype size" and "Mime subtype" provides the content MIME
subtype. MIME Subtype may be used to automatically start the MIME
associated application on the host system. Mime type size must be
less or equal to 19.
The "Name size" and "Name" are the content name. In case of file
content this is the file name. In case of ram content, this MAY be an
identifier. In case of real time content, this field stands for a
common name for all media. The name size must be less or equal to 19.
The "PathName size" and "PathName" are the content pathname in the
case of a file only. File pathname size must be less or equal to 255.
The "Keyword<n> size" and "Keyword<n>" fields are keywords. Upon
reception of an unknown LUID:TID announce, Mreceiver MUST check if at
least one of the incoming keywords fits the upper layer fixed keyword
CRITERIA prior to launch the transport. Each keyword size MUST be
less or equal to 19.
6.9 Back Channel extension
Helal Expires January 2003 31
Multicast Announce and Control Protocol July 2002
0 7 15 31
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Naddress | | Delay |
+-------------------------------------------------------------+
| Port | Connexion Timeout |
+-------------------------------------------------------------+
| Back Address 1 |
+-------------------------------------------------------------+
| back Address 2 |
+-------------------------------------------------------------+
| ... |
+-------------------------------------------------------------+
| back Address n |
+-------------------------------------------------------------+
The "NAddress" field is the number of following back addresses. When
Msender provides more than one address, Mreceiver MUST randomly
choose one of the provided addresses. For now Msender must set this
field to 1.
The "delay" field is the maximum time delay in second to be wait by
Mreceivers before to send back status message. When a status message
has to be sent, Mreceiver randomly choose a delay value between 0 and
"delay" to be wait prior to send the message.
The "Port" fields provide the udp or tcp logical port to be used
along with the back address.
The "Connexion Time out" field provides the maximum connexion time
allowed by the Msender. Mreceiver using a slow (dialup) connection
back to the server MUST abort sending of the status message if
ConnexionTo is reached before the connection is established.
The "Back Address <n>" fields provide possible return addresses to be
used. Mreceiver MUST randomly choose one of them.
7 Dynamics
7.1 Emission Rate
The announce rate is considered out of band compared to the data
transport rate. It is given as a time parameter between two
successive announce messages. The announce is active during all
transmission except when command query are issued. In this case
command message are sent with the same rate as announce message with
the same LUID:TID. As soon as commands end, announce restarts. In
this way the rate is always maintained to the same value.
7.2 Sender cycles
Helal Expires January 2003 32
Multicast Announce and Control Protocol July 2002
The cycle begins with the announce message initiating the pure
announce phase. From this point Mreceivers creates a LUID:TID
context.
7.2.1 Announcing transmission
-------- ---- ---------------
/ \ / \ / \
Announce -----+ -- -- -----------------
| -- -- -----------------
| / \ / \ /
Command ---------------+ ---- ---------------
| | |
| | -------------------------------
| | / | \
Transport ----+------------------- | -
| | | | |
| | --------- | |
| | / \ | |
LATE bit -----+------------------- ----- |
| | | | |
<-(pure announce)-> <-(Late->
| <-(Transport)------------------>
|
<---------------(Control)----------------->
Figure 3: Msender cycle
Msender initiates transmission cycle with the announce message. From
some point Msender then start the data transport. The announce
message is still active but with the LATE bit set into the option
field whenever possible for the transport instance.
As soon as the Msender do not want new receiver to join the
transmission, it clears the LATE bit into the announce message.
Announce may still be used for monitoring purpose.
Then Msender transport ends and there is still place for the command
message until the context implicit time out expires.
7.2.2 Sending transmission commands
Msender MAY send command messages at any time. During that time the
announce stops. For instance the ECHO command query may be used may
be used from time to time to check if a significant number or
receivers has joined the transmission.
7.2.3 Splitting large group descriptors
When large group descriptors are spanned over multiple announces,
Msender MUST change the portion list into each announce message
changing the VersNum field as well as MsgNum field into the header.
This is intended to to speed up the joint process because each
Helal Expires January 2003 33
Multicast Announce and Control Protocol July 2002
successive message will hold a portion of the list allowing the all
list to be distributed faster. However this also loads the Mreceiver
because each successive message will be thought as a new announce.
7.2.4 Registering
When registering, Msender MUST start announcing and then send an
echo query from time to time. During this process, Msender MUST
aggregate back status until a threshold is reached. Then transport
MAY be lauched.
7.3 Receiver cycles
7.3.1 Transmissions
Mreceiver maintains a state machine associated to each LUID:TID
context.
|<-- Unknown
+------+ |
| v v
| +-----------+
New -->| | RECEIVE |
| +-----------+
| | | | |
+-----+ | | |
| | |
Trp ok && !Process -->| | |---------------------+
|| | | |
Trp error | |<-- Trp ok & Process |
| | |
+------+ | +-------+ |
| v v | |
| +-----------+ | |
| | EXECUTE | | <-- New |
Abort -->| +-----------+ | |
| | | | | |
| | | +------+ |
| | +-----------------+ |
+-----+ |<-- Process end || | |
| | Abort | |
+----+ | | | |
| v v | | |
| +-----------+ | |
New -->| | FINAL | | |
| +-----------+ | |
| | | | |
+----+ +----------------------+-----+
|
|<-- Life time
Figure 4: Mreceiver "event / state" diagram
Helal Expires January 2003 34
Multicast Announce and Control Protocol July 2002
The possible states are the following:
RECEIVE: transport running
EXECUTE: external command running
FINAL: waiting for end of life
The possible events are the following:
Unknown: First announce accepted
New: new announce / command(ECHO, PLAY, SYNCPLAY)
Trp ok: transport completed
Trp error: transport Nok, Error or Time out
Process:a PLAY/SYNCPLAY command stored
Process_end: External command termination
Abort: Abort query received from Msender
Life time: garbage collector
7.3.2 System
Mreceiver acts in slave responding to Msender Master.
Not applicable (master/slave operation)
7.4 Time outs
An implementation MUST time out Msender after the expected life
time. If SUSPEND/RESUME cycles exist, Msender MUST provide a new
estimation of the Life Time at along with new (RESUME) announce.
When Msender time out, a new announce with ABORT MUST be sent to
Mreceivers.
Depending on transport, a Msender implementation MIGHT ignore
transport notified time out. This may arise with low capacity
physical path to data (memory, network) inducing some slew rate. It
is up to implementations to decide whether or not accept slew rates.
But in this case the life time must be re predicted periodically and
provided to Mreceivers.
An implementation MUST time out Mreceivers after the last available
predicted life time. The transport instance is destroyed and status
code set to NACK with reason code = Time Out.
Depending on transport implementation, Mreceiver MAY detect
transport notified time outs and set status code to NACK with reason
code set to TIMEOUT.
8 Security
We decided to keep some fields outside the encrypted payload in
order to simplify Mreceiver implementation. Therefore there is a
possibility for malicious Msender to create multiple dummy LUID:TID
contexts creating corresponding sessions on the Mreceiver.
Helal Expires January 2003 35
Multicast Announce and Control Protocol July 2002
The session key for data encryption is distributed by MACP. The
factor preventing a malicious user to retrieve the private data key
from the announce message is the announce encryption algorithm (128
bits). Given this confidentiality level, we decided to limit
transport session key to 32 bits in order to not to overload
Mreceiver CPU.
One interest in having an encrypted announce mechanism is that
payload encryption is not required at the session announcement level
over a globally unique or administrative scope multicast addresses.
9 Ipv6
With IP V6, group address descriptors will always use the LUID
format preventing 128 bit addresses to reduce the host list size
size.
In the future MACP will consider Mchannel and channel fields size of
128 bits whenever necessary. In the present release of the draft,
please note that illustration always use 32 bits.
10 Discussion
10.1 SAP similarity
The MACP protocol shows some similarity with the SAP protocol [2].
However the MACP protocol is not intended to provide a full SD [4].
In particular there is no announcement of the session predicted
absolute time. This is because reliable content transport duration
cannot be predicted. This results in SAP similarity and some SD
equivalent message description in MACP. The main differences are:
o MACP provides a group address descriptor as an address list of
identifiers
o MACP uses binary format as much as possible for Mreceiver
filtering efficiency
10.2 Dialup
In the case of asymetric network with a terrestrial return path, it
may be desirable that Mreceivers send out information (ack/nack)
only at the end of the transport phase in order to reduce
terrestrial network cost. With MACP, one could see that Msender
query Mreceivers for their status after the transport end. However
in the case of a NORM transport protocol sending nacks "on the fly",
it will be desirable that the nack bitmap image at the end of each
"pass" could be returned through the MACP status message. This has
not been studied for now.
10.3 Public keys vs. symmetric algorithm for announce session keys
Helal Expires January 2003 36
Multicast Announce and Control Protocol July 2002
We stated that symmetric algorithm for announce session key was
preferred in in order to not to share a so called "private key"
among Mreceivers. However for some applications, if a web based
downloading service is the upper MACP layer, public key algorithm is
applicable because private key can dynamically generated by some
purchasing center.
10.4 Automated Error Correlation
NORM transports have capacity to mix Mreceivers working with and
without a back channel. In this way some Mreceivers may act as nack
probes for other pure push receivers. Each time a nack probe detects
missing data, it sends nack back to the Msender, which in turn
provides the necessary repair packets [5]. This process is called
error correlation because it is able to correct errors that are
correlated to the nack probe errors. In other words for Mreceivers
located near to the nack probe, these repair packets are likely to
complete some missing data.
Multicast addresses are mapped to MAC multicast addresses [7].
Therefore since any IP adapter as a limited set of MAC filters, a
single nack probe cannot correlate all transmissions from a many
Msenders. It is possible to build an automated error correlated
system. Knowing that a nack probe has a limited number of multicast
MAC address filters, a system public address (referred to as monitor
in some related specifications) may be used by each Msender to tell
all associated nack probes what public address to listen to. Then
Msender have to consider public addresses as limited resources
preventing nack probes to have to ear more than what their hardware
can.
10.5 Proxy
MACP holds back channel information into command and listen message.
It is possible for an application to set this back channel to a
different address than the Msender address. Here are the possible
applications:
o Firewall support: Msender uses some gateway to a Mnetwork and is
likely to be NATed to Mnetwork hosts. In this case back channel
should be set to the firewall public address rather than actual
Msender address.
o Hierarchic aggregation: As far as hierarchic network tree will be
concerned in the future, it might be desirable that a MACP
aggregator collects explicit ack a each tree head.
11 References
[1] Whetten, Vicisano, Kermode, Handley, Floyd and Luby, "Reliable
Multicast Transport Building Blocks for One-to-Many Bulk-Data
Transfer", RFC3048, January 2001.
Helal Expires January 2003 37
Multicast Announce and Control Protocol July 2002
[2] Handley, Perkins and Whelan, "Session Announcement Protocol",
RFC2974, October 2000.
[3] Adamson, Borman, Handley and Macker, "NACK-Oriented Reliable
Multicast Protocol (NORM)", draft-ietf-rmt-pi-norm-03.txt,
November 2001, work in progress.
[4] Handley and Jacobson "SDP: Session Description Protocol",
RFC2327, April 1998.
[5] Adamson and Macker "Multicast Dissemination Protocol (MDP)
Developer's Guide", http://manimac.itd.nrl.navy.mil/MDP/
MdpDevGuide.html
[6] Speakman, Crowcroft, Gemmell, Farinacci, Lin, Leshchiner, Luby,
Montgomery, Rizzo, Tweedly, Bhaskar, Edmonstone, Sumanasekera
and Vicisano, " PGM Reliable Transport Protocol Specification",
RFC3208, December 2001.
[7] Deering "Host Extensions for IP Multicasting", RFC1112, August
1989.
[8] Callas, Donnerhacke, Finney and Thayer "OpenPGP Message Format",
RFC2440, November 1998
[9] Schulzrinne, Casner, Frederick and Jacobson "RTP: A Transport
Protocol for Real-Time Applications", RFC 1889, January 1996.
[10] Handley and Jacobson "Session Announcement Protocol", RFC2974,
October 2000.
[11] Schulzrinne, Rao and Lanphier "Real Time Streaming Protocol
(RTSP)", RFC 2326, April 1998.
[12] Schulzrinne ôProfile for Audio and Video Conferences with
Minimal Control", RFC 1890, January 1996
[13] Holbrook and Cheriton ôIP multicast channels: express support
for large-scale Single Source Applications", in proceedings of
SIGCOMM 1999.
[14] Richon, Chanteau and Babonneau "Versatile File Delivery
Protocol, a Nack-based reliable multicast file transfer Protocol
Instantiation", draft-richon-vfdp-protocol-00.txt, December 2001,
work in progress.
[15] Miller, Robertson, Twedly and White "StarBurst Multicast File
Transfer Protocol (MFTP) Specification",draft-miller-mftp-spec-
03.txt, April 1998, work in progress.
12 Annex : MACP Interface
Helal Expires January 2003 38
Multicast Announce and Control Protocol July 2002
This section defines an example of interface to a MACP
implementation. It consists in entry points and data structures.
Entry points with the same name as data structure may be seen as
object constructors.
12.1 Sender side
Entry: GroupDescriptor
Allows the core component to fill a GroupDescriptor data
structure to be passed to the AnnounceTransmission service.
in: NumberOfHosts, the number of following hosts
in: IP/LUID, a constant indicating host identifier format
in: HostList[] the enumeration
out: GroupDescriptor, a data structure
out: error code
Entry: MediaDescriptor
Allows the core component to fill a MediaDescriptor data
structure.
in: MediaBaseAddress, an IPv4 address
in: MediaPort, a value between 1000 and 65535
in: MumberOfLayers, a value between 1 and 8
in: IncreaseByAddresses, true if layers a found by
increasing the base address
in: Format, a 16 bit encoding format
out: MediaDescriptor, a data structure
out: error code
Entry: LiveContentDescriptor
Allows the core component to fill content descriptor data
structure for a live transmission (stream)
in: DestinationName, the destination content common name to
every media
in: NumberOfMedia
in: MediaDescriptor [], data structures describing
individual medias
in: NumberOfKeyWords, from 0 to 5.
in: KeyWords [], null terminated ASCII strings corresponding
to keywords.
in: ContentSize64, content size on 64 bits
in: MimeType
in: MimeSubType
out: LiveContentDescriptor, a data structure
Helal Expires January 2003 39
Multicast Announce and Control Protocol July 2002
out: error code
Entry: FileContentDescriptor
Allows the core component to fill content descriptor data
structure for a file transmission.
in: DestinationFileName, the destination file name.
in: DestinationPathFileName, the destination content path
name
in: MediaDescriptor, a data structure describing the file
media
in: NumberOfKeyWords
in: KeyWords []
in: ContentSize64, content size on 64 bits
in: MimeType
in: MimeSubType
out: FileContentDescriptor
out: error code
Entry: RamContentDescriptor
Allows the core component to fill a content descriptor data
structure for a memory transmission
in: DestinationIdentifier, the destination ram identifier if
any.
in: MediaDescriptor, a data structure describing the media
in: NumberOfKeyWords
in: KeyWords []
in: ContentSize64, content size on unsigned 64 bits
in: MimeType
in: MimeSubType
out: RamContentdescriptor
out: error code
Entry: SetContentDescriptorAttribute
Allows the core component to set SD opaque attributes into a
ContentDescriptor data structure.
in: ContentDescriptor
in: AttributeName
in: AttributeValue
out: error code
Entry: AnnounceTransmission
Allows the core component to fill an AnnounceTransmission data
structure
Helal Expires January 2003 40
Multicast Announce and Control Protocol July 2002
in: Tid32, a unique 32 bit value.
in: TypeOfTransport, see Trp field
in: TimeIntervalInSec the time between 2 MACP messages in
second (correspond to MACP rate)
in: overwrite, true if content is to be overwritten at the
Mreceiver side (for live content, this value is not
taken into account).
in: GroupDescriptor
in: ContentDescriptor a LiveContentDescriptor,
RamContentDescriptor or FileContentDescriptor
in: DataRate,
out: LifeTime, the predicted time the transmission will last
(given DataRate)
out: AnnounceTransmission
out: error code
Entry: Announce
Allows the core component to start announce or to modify
announce flags. From that point any subsequent call to a
Command entry point replace the announce stream by a finite
command message stream. After the end of command stream,
announce stream take place again.
in: AnnounceTransmission
in: Partial, true if resume
in: Last, true if last transmission
in: Back, true if Msender will use subsequent queries with
back status
in: LifeTime, expected time to be announced
out: error code
Entry: Stop
Allows the core component to stop sending announce for a
transmission.
in: TransmissionDescriptor
out: error code:
Entry: BackChannelDescriptor
Allows the core component to fill a BackChannelDescriptor data
structure to be passed to the Command and System entry points.
in: IpRxInterface, null for the same address as for sending,
in: IpRxPort, integer value between 1000 and 65535
Helal Expires January 2003 41
Multicast Announce and Control Protocol July 2002
in: Delay, Time window in second
in: ConnexionTimeOut, maximum time accepted for dialup
connexion or 0.
out: BackChannelDescriptor, a data structure
out: error code
Entry: Command
Allows the core component to send a command query in a
transmission and be notified at the end of status messages
reception. This call replaces the announce stream by a time
limited command stream before the announce stream to take place
again.
in: AnnounceTransmission
in: Query
in: NumberOfMessage
in: NumberOfBackAddresses, pass always 1
in: BackChannelDescriptor[]
in: NotifyStatus, a pointer to a local callback function.
This function will be notified after aggregation of
every responses from Mreceivers during the time window.
The callback provides a status data structure from which
subsequent entry points may retrieve informations.
out: error code
Callback: NotifyStatus
Allows the MACP implementation to inform the core component
that a status in response to a command is available.
in: Status, a data structure from which the core component
may retrieve fields
out: control code, a value indicating to MACP what to do on
notification return.
Entry: GetStatusSize
Allows the core component to retrieve the number of Mreceivers
described into a Status data structure.
in: Status
out: Size, number of hosts
out: error code
Entry: GetItemStatusField
Helal Expires January 2003 42
Multicast Announce and Control Protocol July 2002
Allows the core component to retrieve one of the fields into
the Status data structure.
in: Status
in: HostIndex, the index of the host the core component is
interested in.
in: FieldType, a constant indicating what field to retrieve.
0: status Code, 1, reason code, 2: Fmt (LUID/IP), 3:
Host identifier.
out: Code, a integer value corresponding to the field of that
Mreceiver
out: error code.
Entry: ListenDescriptor
Allows the core component to fill a listen descriptor data
structure to be used along with the System entry point.
in: RxInterface, the receive network interface to be used by
Mreceivers.
in: TxInterface, the transmit network interface to be used
by Mreceivers.
in: IpPublicAddress, the multicast address to listen to
in: PublicPort, the multicast port address to listen to
in: Ncriteria, the number of criteria
in: Criteria[], a string table containing content descriptor
criteria.
out: ListenDescriptor, a data structure
out: error code
Entry: SystemTransmission
Allows the core component to fill a data structure to be used
along with the System entry point.
in: Tid32, a unique 32 bit value.
in: TimeIntervalInSec the time between 2 MACP messages in
second (correspond to MACP rate)
out: error code
Entry: System
Allows the core component to send a listen query and be
notified at the end of listen status messages reception. This
call starts a time limited command stream.
in: SystemTransmission
in: Query, LISTEN, UNLISTEN, PING
in: ListenDescriptor
in: NumberOfMessages
Helal Expires January 2003 43
Multicast Announce and Control Protocol July 2002
in: NumberOfBackAddresses, pass always 1
in: BackChannelDescriptor[]
in: NotifyListenStatus, a pointer to a local callback
function. This function will be notified after
aggregation of all responses from Mreceivers during the
time window. The callback provides a ListenStatus data
structure from which subsequent entry points may
retrieve informations.
out: error code
Callback: NotifyListenStatus
Allows the MACP implementation to inform the core component
that a listen status in response to a listen message is
available.
in: ListenStatus, a data structure from which the core
component may retrieve status fields
out: control code, a value indicating to MACP what to do on
notification return.
Entry: GetListenStatusSize
Allows the core component to retrieve the number of Mreceivers
described into a ListenStatus data structure.
in: ListenStatus
out: Size, number of hosts
out: error code
Entry: GetItemStatusField
Allows the core component to retrieve one of the fields into
the Status data structure for one host.
in: ListenStatus
in: HostIndex, the index of the host the core component is
interested in.
in: FieldType, a constant indicating what field to retrieve.
0: status Code, 1, reason code, 2: Fmt (LUID/IP), 3:
Host identifier.
out: Code, a integer value corresponding to the field of that
Mreceiver
out: error code.
Entry: GetChannelListItem
Helal Expires January 2003 44
Multicast Announce and Control Protocol July 2002
Allows the core component to retrieve the list of listen
channels for a given host (in response to a PING listen query
only)
in: ListenStatus
in: HostIndex, the index of the host the core component is
interested in.
out: NumberOfChannels
out: ChannelList, a string table containing every Mchannels
for that host
out: error code.
12.2 Receiver side
Entry: Listen
Allows the core component to listen to a Mchannel. As soon as a
new announce, command or Configuration message is detected,
message is received a callback function is called. There is
only one notify per announce version field.
in: IpRxInterface, network interface to listen on
in: MPort, a value between 1000 and 65535
in: MAddress, an IPv4 class D address to join
in: MPort, a value between 1000 and 65535
in: NotifyNew, a pointer to a local callback function. This
function will be notified each time an unknown or new
message is received. It may provide a Announced or
Command, or Configuration data structure. See services
allowing retrieving announced information from these
values.
out: error code
NotifyNew
Allows the MACP implementation to inform the core component
that a new announce, command, system info has been received.
The core component MUST tell what to do on, return.
in: UNKNOWN / NEW, indicates if the received message
concernes a new LUID:TID.
in: Backchannel, indicates if a status is requested by
Msender
in: Type, indicates announce, command, or System message
in: Announce, or System data structure depending on
TypeOfMessage (for the command message there is no data
structure)
in: BackAddressDescriptor, information for sending answer
out: control code, a value indicating to MACP what to do with
unknown LUID:TID: 0: ignore, 1 accept. Upon reception of
Helal Expires January 2003 45
Multicast Announce and Control Protocol July 2002
an unknown LUID:TID announce, the core component may
call the upper layer to check content descriptor
criteria.
GetIDs
Retrieve the LUID and TID from an Announce or System data
structure. The core component uses this call inside the
NotifyView callback.
in: Announce or System data structure
out: LUID
out: TID
out: LifeTime, in hours
out: error code.
GetTransportType
Retrieve the NORM transport type from an Announce data
structure. Core component uses this call inside the Listen
service notification callback in order to launch appropriate
transport on new announce detection.
in: Announce, data structure
out: TypeOfTransport, NORM transport name
out: Live (unused)
out: error code.
GetAnnouncedContentDescriptor
Retrieve the ContentDescriptor object from an Announce data
structure.
in: Announce, data structure
out: ContentDescriptor
out: error code.
GetNumberOfMedia
Retrieve number of media into a ContentDescriptor data
structure.
in: ContentDescriptor
out: NumberOfMedia
out: error code.
GetName
Retrieve name from the ContentDescriptor.
Helal Expires January 2003 46
Multicast Announce and Control Protocol July 2002
in: ContentDescriptor
out: Name
out: error code.
GetPathName
Retrieve the pathname from the ContentDescriptor (file only).
in: ContentDescriptor
out: File name (or null for live data)
out: error code
GetMediaItemInfo
Retrieves one media informations from a ContentDescriptor
in: ContentDescriptor
out: MediaIndex
out: BaseAddress, multicast private address
out: port, multicast private port
out: NumberOfLayers
out: I bit
out: Format
out: error code
GetPublicChannel
Retrieves a public channel concerned with a system query from
the System data structure.
in: System
out: IpAddress
out: Port
out: error code
GetCriteria
Retrieves criteria strings from a System data structure.
in: System
out: NumberOfCriteria
out: Criteria[], a string table
out: error code
RandomizeBackChannel
Helal Expires January 2003 47
Multicast Announce and Control Protocol July 2002
Randomly choose a back channel and a delay from the
BackChannelDescriptor data structure.
in: BackChannel
out: Delay, in ms
out: IpAdress
out: Port
out: error code
AckCommandQuery
Allows the MACP implementation to answer to a command query.
This call is done by the core component within the NotifyNew
function. After action, receiver status code and reason are
determined. A reference to the Announce data structure serves
as context. MACP implementation manages the requested delay
between the call and starting emission point.
in: Announce, identifies the transmission
in: status, the current status code
in: reason, the current reason code
in: NumberOfMessages, note TCP/UDP is received from
protocole but not the number of messages (to be
corrected)
in: Delay
in: IpAddress
in: Port
out: error code
AckSystemQuery
Allows the MACP implementation to answer to a configure query.
This call is done by the core component within the notification
callbacks. A reference to the System data structure serves as
context. MACP implementation manages the requested delay
between the call and starting emission point.
in: System, identifies the transmission
in: status, the current status code
in: reason, the current reason code
in: NumberOfChannels
in: PublicAddresses[]
in: PublicPort[]
in: NumberOfMessages, note TCP/UDP is received from
protocole but not the number of messages (to be
corrected)
in: Delay
in: IpAddress
in: Port
out: error code
Helal Expires January 2003 48
Multicast Announce and Control Protocol July 2002
12.3 Error codes
(TBD)
12.4 Control codes
(TBD)
13 Author's address
Jean-Noel Helal
Quadrille Ing‰nierie
13/15 rue Buffon
75005 Paris
+33 (0) 158 100 305
jean-noel.helal@quadrille.fr
Helal Expires January 2003 49
