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