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 ", "Media port , "Media NLayer " and "Media Format " 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 " and "Media port " fields together provide the base address and port for media . 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" field represent the number of layers for media . 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 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 > 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 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 " 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 " 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 '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 size" and "Criteria" 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" and "PublicPort" 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 size" and "Keyword" 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 " 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