MMUSIC J. Luoma
Internet-Draft Nokia
Expires: December 29, 2003 June 30, 2003
MUPPET: Internet Media Guide Unidirectional Point-to-Multipoint
Transport
draft-luoma-mmusic-img-muppet-02
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.
This Internet-Draft will expire on December 29, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document defines MUPPET, a unidirectional point-to-multipoint
transport protocol for the delivery of Internet Media Guide metadata.
The MUPPET protocol is based on Asynchronous Layered Coding, a
massively scalable protocol for reliable multicast transport. MUPPET
is intended to be used with the Internet Media Guide framework, and
in addition may be useful with other applications.
Luoma Expires December 29, 2003 [Page 1]
Internet-Draft MUPPET June 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
4. IMG Metadata Delivery Using MUPPET . . . . . . . . . . . . . 8
4.1 Complete Descriptors . . . . . . . . . . . . . . . . . . . . 9
4.2 Delta Descriptors . . . . . . . . . . . . . . . . . . . . . 9
4.3 IMG Pointers . . . . . . . . . . . . . . . . . . . . . . . . 9
4.4 Environmental Considerations . . . . . . . . . . . . . . . . 10
5. The MUPPET Protocol . . . . . . . . . . . . . . . . . . . . 12
5.1 Use of IMG Sessions . . . . . . . . . . . . . . . . . . . . 12
5.2 Use of IMG Channels . . . . . . . . . . . . . . . . . . . . 12
5.3 Protocol Framing . . . . . . . . . . . . . . . . . . . . . . 13
5.4 IMG Delivery Table . . . . . . . . . . . . . . . . . . . . . 18
5.4.1 IDT Instance Header . . . . . . . . . . . . . . . . . . . . 19
5.4.2 IDT Payload Format . . . . . . . . . . . . . . . . . . . . . 20
5.5 Forward Error Correction . . . . . . . . . . . . . . . . . . 22
5.5.1 Carrying FEC Parameters in EXT_FTI . . . . . . . . . . . . . 23
5.5.2 Carrying FEC Parameters in IDT . . . . . . . . . . . . . . . 25
5.6 Payload Segmentation . . . . . . . . . . . . . . . . . . . . 25
5.7 Use of Congestion Control . . . . . . . . . . . . . . . . . 25
5.8 Caching Support in IMG Proxies . . . . . . . . . . . . . . . 26
5.9 Authentication . . . . . . . . . . . . . . . . . . . . . . . 26
5.10 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.11 Initial Discovery of Transport Sessions . . . . . . . . . . 26
6. Security Considerations . . . . . . . . . . . . . . . . . . 27
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
Normative References . . . . . . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . 30
A. Example Usage . . . . . . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . 33
Luoma Expires December 29, 2003 [Page 2]
Internet-Draft MUPPET June 2003
1. Introduction
This document defines MUPPET, a unidirectional point-to-multipoint
transport protocol for the delivery of Internet Media Guide (IMG)
metadata. The protocol defined in this specification is based on
Asynchronous Layered Coding (ALC) [4], a massively scalable transport
protocol defined in Reliable Multicast Transport (RMT) Working Group
of IETF.
MUPPET is a protocol instantiation compliant with the Internet Media
Guide Framework [3]. An Internet Media Guide (IMG) is a set of
metadata describing content such as streaming media and downloadable
files available to receivers. This document considers unidirectional
point-to-multipoint (p-t-m) transmission of IMG metadata and defines
a new transport protocol "MUPPET" for this purpose. The baseline of
an IMG metadata format suited for delivery with MUPPET is defined in
[7].
Luoma Expires December 29, 2003 [Page 3]
Internet-Draft MUPPET June 2003
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Luoma Expires December 29, 2003 [Page 4]
Internet-Draft MUPPET June 2003
3. Terminology
Complete IMG Descriptor
Provides a complete syntax and semantics to describe a set of
metadata, which does not need any additional information from
other IMG Descriptors. It may contain either the full set of
metadata in the sender's IMG database or only a subset thereof.
In addition to actual metadata, a Complete Descriptor may also
include references to parts of metadata that can only be
accessed using some other delivery mechanism than MUPPET.
Congestion Control
Functionality of IMG senders allowing them to control their
transmission rate in a way that is fair to the network. The
lack of a feedback channel from receivers on unidirectional
access networks limits the use of congestion control for
downlink data and practically eliminates the need for
congestion control on the uplink.
Delta IMG Descriptor
Provides only part of a Complete Descriptor, defining the
difference from a previous version of the Complete Descriptor
in question. This descriptor may be used to reduce network
resource usage for instance when small and frequent changes
occur to the Complete Description. Thus, this descriptor itself
cannot represent complete metadata set until it is combined
with the corresponding Complete IMG Descriptor. In addition to
actual metadata, a Delta Descriptor may also include references
to parts of metadata that can only be accessed using some other
delivery mechanism than MUPPET.
Forward Error Correction (FEC)
FEC data is redundant information generated from payload data
and interleaved with it for transmission. The use of FEC allows
receivers to reconstruct payload data segments lost or damaged
due to transmission errors.
IMG Channel
Provides a delivery service for IMG Descriptors. An IMG channel
is one of the following:
1. Full Channel that delivers Complete Descriptors.
Luoma Expires December 29, 2003 [Page 5]
Internet-Draft MUPPET June 2003
2. Update Channel that delivers Delta Descriptors.
3. Notify Channel that delivers IMG Pointers.
IMG Descriptor
A collection of IMG metadata - see [7]. There are the following
subtypes of IMG Descriptors: Complete Descriptor, Delta
Descriptor and IMG Pointer. MUPPET is an instance of a protocol
providing transport service to IMG Descriptors.
IMG Pointer
Consists of one or more references, such as URLs, that the
receiver is able to address specific metadata with. An IMG
pointer may be used to separately obtain Complete or Delta
Descriptors, or perform another IMG management function such as
data expiry and erasure. Although an IMG pointer only includes
references and no IMG metadata as such, references to IMG
metadata may also appear as data fields in Complete or Delta
Descriptors.
IMG Proxy
IMG proxy is an IMG transceiver that can filter from one or
more IMG senders and output to one or more IMG sessions.
Logically a proxy fits in between IMG senders and receivers. A
proxy may also cache IMG metadata and may provide its own
bandwidth control or congestion control schemes on the output.
IMG Receiver
A logical entity that receives media guides from an IMG sender.
IMG Sender
A logical entity that delivers IMG metadata to one or more IMG
receivers. A (multicast) sender shall provide bandwidth control
or congestion control schemes on the output. A sender can
additionally be a receiver - see IMG transceiver.
IMG Session
An IMG session delivers the full or partial metadata of a
single IMG from the sender to any number of receivers. An IMG
session consists of one or more IMG channels.
Luoma Expires December 29, 2003 [Page 6]
Internet-Draft MUPPET June 2003
IMG Transceiver
A combination of an IMG receiver and sender.
Luoma Expires December 29, 2003 [Page 7]
Internet-Draft MUPPET June 2003
4. IMG Metadata Delivery Using MUPPET
The requirements and framework for Internet Media Guides (IMG) are
described in [2] and [3], respectively. The following atomic
operations needed for IMG metadata delivery are identified in [3] and
briefly listed in the following.
o IMG_ANNOUNCE: unsolicited delivery of IMG metadata.
o IMG_QUERY: request to receive a delivery of IMG metadata.
o IMG_RESOLVE: delivery of IMG metadata in response to an IMG_QUERY.
o IMG_SUBSCRIBE: request to receive notifications of changes in IMG.
o IMG_NOTIFY: delivery of a change notification in response to an
IMG_SUBSCRIBE.
The MUPPET protocol implements the IMG_ANNOUNCE functionality,
providing unidirectional transport for IMG Descriptors. Although the
actual syntax and semantics of IMG Descriptors is outside the scope
of this specification, for the purposes of the MUPPET protocol an IMG
Descriptor is one of the following.
o Complete Descriptor: a set of IMG metadata that does not need
additional information from other IMG entities.
o Delta Descriptor: provides a part of a Complete Description,
defining the difference from a previous version of the Complete
Description.
o IMG Pointer: provides a simple identifier or locator, such as a
URL, that the receiver is able to reference specific metadata
with.
MUPPET sender and receiver implementations SHOULD support the use of
Complete Descriptions, and MAY also support the use of Delta
Descriptions and IMG Pointers.
IMG senders SHOULD transmit all IMG Descriptors in carousel-style,
periodically repeating the transmission of IMG Descriptors sent
earlier that are still valid. This provides a level of error
robustness and allows receivers that are switched on later than the
initial transmission to receive the entire transmission - or at least
the parts they are interested in. Determining the time interval
between retransmissions is application specific and outside the scope
of this document.
Luoma Expires December 29, 2003 [Page 8]
Internet-Draft MUPPET June 2003
4.1 Complete Descriptors
A set of an IMG sender's metadata can be delivered to IMG receivers
using a Complete Descriptor, and the bandwidth efficiency may be
further improved by the used Delta Descriptors and/or IMG Pointers. A
Complete Descriptor may contain either the full set of IMG metadata
from a particular sender or a subset thereof.
4.2 Delta Descriptors
The use of Delta Descriptions enables receivers to discover changes
in IMG metadata faster and allows reducing the retransmission rate of
Complete Descriptions. After obtaining a Complete Description, an IMG
receiver can remain up to date with changes in the corresponding IMG
metadata by receiving just IMG Delta Descriptions, if available.
4.3 IMG Pointers
In addition to sending Complete Descriptions, either or both of IMG
Pointers and Delta Descriptions can be transmitted for the same IMG.
Because IMG Pointers only carry references to metadata, IMG receivers
must retrieve the actual metadata they need via other means, for
example by receiving Complete or Delta Descriptors using MUPPET or by
using some other protocol.
In the case of a fully unidirectional IMG announcement system, IMG
receivers that have received the latest Complete Descriptor of a
particular IMG subsequently only need to receive IMG Pointers
referring to changes in the same set of IMG metadata. Based on the
received IMG Pointers, each IMG receiver may decide obtain the Delta
Description or Complete Description carrying the actual changed
metadata.
On an IMG announcement system that provides a return data path from
each IMG receiver to the IMG sender, the following are examples of
cases where IMG Pointers should be transmitted by IMG senders.
o No unidirectional metadata transfer: IMG metadata is never sent
unsolicited to receivers but can be requested using a separate
unicast IMG transport protocol.
o Unidirectional metadata transfer for IMG updates only if
sufficient demand: IMG updates are only sent if enough clients
indicate (via out-of-band means) that they wish to receive the
updates.
o Unidirectional metadata transfer with bandwidth reduction:
Complete Descriptions and Delta Descriptions are sent to clients
Luoma Expires December 29, 2003 [Page 9]
Internet-Draft MUPPET June 2003
much less frequently than IMG Pointers. IMG Pointers inform
receivers that part of their IMG data is no longer valid - IMG
receivers can either wait for an unsolicited delivery of IMG
metadata via MUPPET or request an IMG update via a point-to-point
IMG transport protocol.
4.4 Environmental Considerations
Figure 1 shows an IMG usage scenario where a single IMG sender is
delivering IMG metadata to a number of IMG receivers. IP routing
infrastructure is assumed and not shown.
unidirectional
---------------> +----------+
downlink | IMG |
------------->| Receiver |
/ +----------+
+--------+ / .
| IMG |----------- .
| Sender | \ .
+--------+ \ +----------+
------------->| IMG |
| Receiver |
+----------+
Figure 1: Architecture of an IMG Sender and IMG Receivers
Figure 2 shows an IMG usage scenario involving the optional use of an
IMG proxy between IMG senders and IMG receivers.
Luoma Expires December 29, 2003 [Page 10]
Internet-Draft MUPPET June 2003
+----------+ unidirectional +----------+
| IMG | ---------------> | IMG |
| Sender |---- downlink ---->| Receiver |
+----------+ \ / +----------+
\ /
. \ +-------+ / .
. ---->| IMG |----- .
. ---->| Proxy | \ .
/ +-------+ \
+----------+ / \ +----------+
| IMG | / ---->| IMG |
| Sender |---- | Receiver |
+----------+ +----------+
Figure 2: Architecture of IMG Senders, IMG Receivers and an IMG Proxy
An IMG proxy could be useful in the case that a service provider
wishes to filter or mix IMG metadata originating from different
sources, or needs to change the bandwidth allocation for IMG metadata
between different network domains.
Luoma Expires December 29, 2003 [Page 11]
Internet-Draft MUPPET June 2003
5. The MUPPET Protocol
The IMG Point-to-Multipoint Unidirectional Transport (MUPPET)
protocol defined in this document uses multicast IP delivery to
provide a transport service to IMG Descriptors. This transport
service builds on the reliable multicast transport protocol
Asynchronous Layered Coding (ALC) [4].
ALC provides a unidirectional transport service to binary objects,
such as files. ALC is based on the Layered Coding Transport (LCT)
reliable multicast protocol building block, and inherits the LCT
concept of sessions comprising one or more layered channels. An ALC/
LCT session consists of a set of logically grouped channels
associated with a single sender carrying packets with ALC/LCT headers
for one or more objects.
ALC as a generic multicast transport service leaves open
implementation options and provides guidelines on extending the
protocol. With its more specific scope, this document shall further
define the use of optional ALC features and extend the ALC protocol.
5.1 Use of IMG Sessions
The MUPPET protocol provides an IMG sender with unidirectional
transport for its IMG metadata in the scope of an IMG session,
consisting of one or more IMG channels. Each IMG channel is
implemented as a separate ALC session that provides a scalable
delivery service to ALC transport objects. In MUPPET, each transport
object is used for the delivery of an IMG Delivery Table instance or
an IMG Descriptor.
At most one of each IMG channel type (Full Channel, Update Channel,
Notify Channel) may be included in an IMG session.
5.2 Use of IMG Channels
Every IMG session in MUPPET consists of one or more IMG channels.
Each of these channels carries MUPPET packets with the same value of
the ALC/LCT Transport Session Identifier (TSI) field, are sent from
the same source port and IP address, and addressed to a different
destination port and/or IP address. One or more of the following IMG
channels MAY be included in an IMG session.
o Full channel - repeatedly delivers Complete Descriptors. When only
a partial IMG is delivered on the Full Channel, clients MAY be
provided access to the full IMG via a different protocol, e.g. a
point-to-point IMG transport protocol.
Luoma Expires December 29, 2003 [Page 12]
Internet-Draft MUPPET June 2003
o Update channel - repeatedly delivers Delta Descriptors consisting
of parts of the sender's IMG metadata that have changed since the
latest Complete Descriptor was sent.
o Notify channel - repeatedly delivers IMG Pointers to parts of the
sender's IMG that have changed since the latest Complete
Descriptor was sent.
Each IMG channel corresponds to an ALC session, and hence an IMG
session consists of one or more ALC sessions. An ALC session is
defined in RFC 3450 [4] to consist of one or more ALC channels. The
pair (source IP address, Transport Session Identifier) uniquely
identifies an ALC session, while an ALC channel is uniquely
identified by the pair (source IP address, destination IP address).
IMG sender decides on the number of ALC channels allocated for each
ALC session and the bit rate used on each ALC channel. IMG receivers
with interactive network connection are able to join and leave
transport channels, and hence control the received bit rate. IMG
receivers that only have unidirectional network connectivity have the
option of filtering only some of the received ALC channels for
processing. Furthermore, a network element such as IMG proxy can
reduce the number of ALC channels forwarded to a unidirectional link,
for example when congestion is detected at the feed of such a link.
All ALC channels that constitute an IMG channel are sent on
consecutively numbered IP addresses. Only the base IP address used
for each IMG channel needs to be signaled to the receivers, because
the Next flag in the Congestion Control Indication field (see Section
5.3) enables receivers to discover the any subsequence IP addresses
that may have been used for the current IMG channel.
An IMG receiver with interactive network connectivity is able to join
and leave ALC channels that constitute an IMG channel, as needed.
Decisions to join and leave ALC channels may be affected by the
congestion status of the network, as well as the type of IMG channels
the receiver needs to obtain. Furthermore, a network element such as
IMG proxy can reduce the number of ALC channels forwarded to a
unidirectional link, for example when congestion is detected at the
feed of such a link.
5.3 Protocol Framing
The MUPPET protocol re-uses the packet format of ALC/LCT defined in
RFC 3450 [4] and RFC 3451 [5], with extensions defined in this
document. MUPPET packets are carried over UDP. The MUPPET packet
format is shown in Figure 3.
Luoma Expires December 29, 2003 [Page 13]
Internet-Draft MUPPET June 2003
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP header |
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
. LCT header portion .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. FEC Payload ID .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Encoding Symbol(s) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Overall MUPPET Packet Format
UDP header: 32 bits
The standard UDP header.
LCT header portion: variable length
The LCT header portion of the MUPPET packet is described in
[5]. The fields of the LCT header are shown in Figure 4 and
described following the figure.
FEC Payload ID: variable length
The size and format of this header field is determined by the
FEC scheme used, as described in RFC 3450 [4]. In MUPPET, the
type of FEC scheme used is indicated by the EXT_FTI Header
Extension (see Section 5.5).
Encoding Symbol(s): variable length
This field is used to carry one or more ALC encoding symbols
[4] that are the payload of the MUPPET protocol. The size of
each encoding symbol is communicated to receivers using the
EXT_FTI Header Extension (see Section 5.5). Receivers can
determine the total length of this field by computing the total
length of the received packet and subtracting the length of the
headers. For the TOI values of 0 the payload is the IMG
Delivery Table (Section 5.4); for other values of TOI, the
payload is an Descriptor.
The LCT header portion of the MUPPET header is shown in Figure 4. The
Luoma Expires December 29, 2003 [Page 14]
Internet-Draft MUPPET June 2003
length and use of the LCT header portion fields are described in the
following.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | C | r |S| O |H|T|R|A|B| HDR_LEN | Codepoint (CP)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Control Information (CCI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Session Identifier (TSI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Object Identifier (TOI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Header Extensions (if applicable) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: LCT Header Portion
MUPPET version number (V): 4 bits
This field carries the version number of the MUPPET protocol,
which also corresponds to the versions of ALC and LCT used.
Currently, the value of this field is 1.
Congestion control flag (C): 2 bits
This field MUST have the value of 0, indicating that the 32-bit
CCI field format is to be used.
Reserved (r): 2 bits
This field is reserved for future use. A sender MUST use the
value of '0' in this field, and a receiver MUST ignore the
contents of this field.
Transport Session Identifier flag (S): 1 bit
This field MUST have the value of 1, indicating that the 32-bit
TSI field format is to be used.
Transport Object Identifier flag (O): 2 bits
This field MUST have the value of 1, indicating that the 32-bit
TOI field format is to be used.
Luoma Expires December 29, 2003 [Page 15]
Internet-Draft MUPPET June 2003
Half-word flag (H): 1 bit
This field MUST have the value of 0.
Sender Current Time present flag (T): 1 bit
This field MUST have the value of 0, indicating that the Sender
Current Time (SCT) field is not present in the LCT header.
Expected Residual Time present flag (R): 1 bit
This field MUST have the value of 0, indicating that the
Expected Residual Time (ERT) field is not present in the LCT
header.
Close Session flag (A): 1 bit
This field is normally set to 0. The sender MUST set A to 1 in
all packets sent within a MUPPET session during the last few
seconds before closing this session.
Close Object flag (B): 1 bit
This field is normally set to 0. The sender MUST set B to 1 in
all packets for a transmission object during the last few
seconds of transmitting that object.
LCT header length (HDR_LEN): 8 bits
The length of the whole LCT header portion in multiples of
32-bit words, including any Header Extensions.
Codepoint (CP): 8 bits
The codepoint field in MUPPET carries the FEC Encoding ID that
identifies the FEC encoder used for the current ALC transport
object. FEC Encoding ID is part of the FEC Object Transmission
Object Information required by RFC 3452 [8] to be transmitted
for each ALC transport object.
Congestion Control Information (CCI): 32 bits
See Figure 6 for the format of this field in MUPPET.
Transport Session Identifier (TSI): 32 bits
The value of TSI field used for each transport session is
obtained via out-of-band signaling, which is outside the scope
Luoma Expires December 29, 2003 [Page 16]
Internet-Draft MUPPET June 2003
of this specification.
Transport Object Identifier (TOI): 32 bits
The TOI value of 0 is reserved for the delivery of the IMG
Delivery Table (Section 5.4) on each IMG channel. This table in
turn describes the use of other TOI values for the delivery of
IMG Descriptors within each IMG channel.
Header Extensions: variable length
Used to accommodate zero or more optional fields, each
complying with the Header Extension format defined in RFC 3451
[5]. Receivers can determine the length of Header Extensions by
subtracting the lengths of the fixed fields in the LCT header
portion from the value of the HDR_LEN field. All LCT generic
and ALC Protocol Instantiation specific Header Extensions must
be supported, as described in RFC 3451 [5] and RFC 3450 [4]. In
addition, the IDT Header Extension (Section 5.4.1) and the
EXT_FTI Header Extension (Section 5.5) defined for MUPPET must
be supported.
Figure 5 below depicts the format of the FEC Payload ID field
corresponding to the Compact No-Code FEC scheme, which is mandatory
to support in all MUPPET implementations. Other formats of the FEC
Payload ID field corresponding to FEC schemes that MAY additionally
be supported are described in [8] and [9].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Number | Encoding Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Format of FEC Payload ID Field for the Compact No-Code FEC
Scheme
Source Block Number: 16 bits
Identifies from which source block of the object the encoding
symbol in the payload of the packet is generated, as described
in [9].
Encoding Symbol ID: 16 bits
Identifies which specific encoding symbol generated from the
source block is carried in the packet payload, as described in
[9].
Luoma Expires December 29, 2003 [Page 17]
Internet-Draft MUPPET June 2003
Figure 6 below shows the format of the CCI field, as it is used in
MUPPET.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| Reserved | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Format of the Congestion Control Information (CCI) Field
Next flag (N): 1 bit
A value of '1' in this field indicates that the current ALC
session consists of two or more ALC channels, including the
current IP address and the next consecutive IP address. A value
of '0' in this field indicates that the current IP address is
the highest IP address in the current ALC session. IMG
receivers SHOULD monitor this field to detect dynamic addition
or deletion of ALC channels by IMG senders.
Reserved: 15 bits
This part of the CCI field is reserved for future use.
Transmitters MUST use the value of '0' in this field, while
receivers MUST ignore the contents of this field.
Sequence Number: 16 bits
The value of this field is increased by one for each MUPPET
packet sent, and can be used by receivers to detect packet
loss.
5.4 IMG Delivery Table
MUPPET provides a transport service to IMG metadata based on the ALC
protocol [4]. Each IMG Descriptor is delivered within an ALC session
as an ALC transport object. The IMG Delivery Table (IDT) defined here
is used for indicating the bindings between ALC transport objects and
IMG Descriptors.
The IDT is transmitted as one or more IDT Instances, each describing
the properties of one or more IMG Descriptors. An IDT Instance is an
ALC transport object that consists of an IDT Instance Header and an
IDT Instance Payload (see Figure 7. Sender-side MUPPET
implementations MUST transmit the IDT on each IMG channel.
Receiver-side MUPPET implementations MUST support receiving and
Luoma Expires December 29, 2003 [Page 18]
Internet-Draft MUPPET June 2003
parsing the IDT.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP header |
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Default LCT header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. LCT Header Extensions (EXT_IDT, EXT_FTI, etc.) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Payload ID |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Encoding Symbol(s) of IDT Instance Payload .
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: IDT Instance
The transport objects corresponding to IDT Instances can be
transmitted interleaved with other transport objects. However, the
whole IDT Instance describing a particular IMG Descriptor MUST be
sent at least once before starting to send this descriptor within the
same IMG session.
Each receiver of an IMG session SHOULD maintain a local cache for the
IDT Instances received as part of that session. Based on the
information in its IDT cache, each receiver MAY filter or skip
processing transport objects carrying IMG Descriptors that are not
needed by the receiver.
All the IMG Descriptors delivered within an IMG session MUST be
described at least once in the IDT during the lifetime of an IMG
session. The TOI value of '0' MUST be reserved on each IMG channel
for the transmission of the IDT. In addition to IDT Instances, only
transport objects described by the IDT SHOULD be carried on an IMG
channel.
5.4.1 IDT Instance Header
The IDT Instance Header is defined as a new fixed length ALC Protocol
Instantiation specific Header Extension. The IDT Instance Header MUST
be included in every packet carrying an IDT Instance. The format of
the IDT Instance is shown in IDT Instance (Figure 8) and its fields
are defined in the following.
Luoma Expires December 29, 2003 [Page 19]
Internet-Draft MUPPET June 2003
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET=192 | IDT Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: IDT Header Format
Header Extension Type (HET): 8 bits
The type of this Header Extension.
IDT Instance ID: 24 bits
This field initially has the value of '0' for the IDT of a new
ALC transport session, and is increased by one whenever an
updated IDT is constructed for the same ALC transport session.
After reaching its maximum value of 2^24-1, the version number
wraps back to 0. When a wraparound from 2^24-1 to 0 occurs, 0
is considered higher than 2^24-1.
5.4.2 IDT Payload Format
The IDT Payload carries a number of attributes describing the
properties and delivery parameters of one or more IMG Descriptors
delivered as part of an IMG session. An expiry time is also indicated
for the entire IDT Payload. The syntax of the IDT payload is
described by the XML schema in Figure 9. Any XML structure conforming
to this schema is a valid IDT Payload.
Figure 9: XML Schema of the IDT Payload
The fields of the IDT Payload are used as follows:
o Content-Location: provides a URL that uniquely identifies the IMG
Descriptor carried as a payload of the current transport object.
If there are changes in a particular descriptor during the
lifetime of a particular IMG session, the value of the TOI field
changes while the Content-Location field remains the same.
o TOI: a unique identifier for the transport object that represents
the current version of an IMG Descriptor delivered as part of an
IMG session. With the exception of the IDT, a new TOI value MUST
be assigned to any transport object that changes during the
lifetime of an IMG session.
o Content-Type (optional): the MIME type of the transport object -
if absent, an IMG metadata format based on [7] is assumed.
o Content-Length (optional): the transfer length of the transport
object, after optionally applying a content encoding scheme. If
both this field and the EXT_FTI Header Extension describing a
particular transport object are present, the value of this field
Luoma Expires December 29, 2003 [Page 21]
Internet-Draft MUPPET June 2003
SHOULD be equal to the value of Object Length field in EXT_FTI. If
the two values are different, the value in EXT_FTI takes
precedence.
o Entity-Length (optional): the length of the transport object
before applying a content encoding scheme. This field SHOULD NOT
be included unless a non-identity content encoding is used,
otherwise the entity length is equal to the content length.
o Content-Encoding (optional): identifies the encoding used for the
transport object, such as ZLIB compression.
o Content-MD5 (optional): an MD5 checksum for the transport object.
o Expires: After the time indicated in this field, receivers SHOULD
no longer use the information in the current IDT payload.
With the exception of the TOI and Entity-Length fields, IDT Payload
fields re-use the syntax and semantics of the corresponding fields
defined in the HTTP 1.1 specification. New application-specific
attributes can be added to the IDT payload by extending the XML
schema defined here. Backward-compatibility with the current IDT
Payload schema is maintained by adding only optional XML attributes
to the "File" element of the IDT payload schema. Any new attributes
added to the schema SHOULD be in the form of MIME fields, defined in
HTTP 1.1 specification, or otherwise well known.
5.5 Forward Error Correction
MUPPET implementations are REQUIRED to support a Forward Error
Correction scheme that is an instantiation of the reliable multicast
FEC building block defined in [8], in line with the requirements of
the underlying ALC protocol. However, FEC functionality is not
expected to be necessary for MUPPET implementations in all
environments. Therefore, only the Compact No-Code FEC scheme [9] MUST
be supported by all MUPPET implementations, while other FEC schemes
compliant with [8] MAY also be supported.
RFC 3450 [4] defines FEC Object Transmission Information, a set of
attributes describing the FEC scheme used for each ALC transport
object. These attributes can be delivered using the ALC Protocol
Instantiation specific Header Extension EXT_FTI. Although the fields
of EXT_FTI and their use are defined in RFC 3450, the transfer format
of EXT_FTI is left implementation specific. MUPPET defined a transfer
format for EXT_FTI and also provides alteranative means for
delivering the FEC Object Transmission Information using the IMG
Delivery Table.
Luoma Expires December 29, 2003 [Page 22]
Internet-Draft MUPPET June 2003
The FEC Object Transmission Information describing the FEC scheme
used for each ALC transport object MUST be delivered in-band within
the MUPPET session. In MUPPET, each ALC transport object represents
an IDT instance or a metadata file. Whenever delivering an IDT
instance, the EXT_FTI Header Extension is used to carry the FEC
Object Transmission Information for the corresponding ALC transport
object. When delivering an IMG Descriptor, the FEC Object
Transmission Information is carried either in an IDT instance
describing the IMG Descriptor or in an EXT_FTI Header Extension.
The same value of the FEC Encoding Symbol Length is used in every
MUPPET packet carrying the same transport object. Whenever the
transport object length is not an exact multiplier of the Encoding
Symbol Length, the last Encoding Symbol is padded using NULL bytes
following the last payload byte. Because receivers are able to deduce
the FEC Encoding Symbol length from the payload length of each MUPPET
packet, this parameter is not included in EXT_FTI or IDT.
5.5.1 Carrying FEC Parameters in EXT_FTI
The ALC Protocol Instantiation specific Header Extension EXT_FTI
containing FEC Object Transmission Information is included in MUPPET
packets delivering IDT instances, and may also be included in MUPPET
packets delivering metadata files. When the EXT_FTI Header Extension
is used for a particular transport object, EXT_FTI must be included
in at least one MUPPET packet in the delivery of that transport
object.
The format of the EXT_FTI Header Extension that MUST be supported by
IMG senders and receivers is shown in Figure 10 and its fields are
described in the following.
Luoma Expires December 29, 2003 [Page 23]
Internet-Draft MUPPET June 2003
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET = 64 | HEL | FEC Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object Length |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. FEC Encoding ID Specific Format .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: EXT_FTI Header Extension
Header Extension Type (HET): 8 bits
The type of the Header Extension - has the value of 64, as
defined in [4].
Header Extension Length (HEL): 8 bits
The length of the whole Header Extension field in multiples of
32-bit words, including the FEC Encoding ID Specific Format.
FEC Instance ID: 16 bits
Provides a more specific identification of the FEC encoder
identified by the value of the FEC Encoding ID field. The FEC
Instance ID field is only valid for Under-Specified FEC schemes
(see [8]), which use the FEC Encoding ID values between '128'
and '255' inclusive. For other values of the FEC Encoding ID,
the sender MUST use the value of 2^16-1 in this field and the
receiver MUST ignore the contents of this field.
Object Length: 64 bits
The transfer length of the transport object, i.e. the number of
bytes transmitted in the payloads of one or more ALC packets to
deliver the object. The value of this field is calculated after
optionally applying content encoding scheme such as compression
on the transport object.
FEC Encoding ID Specific Format: variable length
The format and length of this field depend on the FEC encoding
scheme used.
The Fully-Specified Compact No-Code FEC scheme [9] identified by the
Luoma Expires December 29, 2003 [Page 24]
Internet-Draft MUPPET June 2003
FEC Encoding ID value of '0' is the only FEC building block that MUST
be supported by all MUPPET implementations. This FEC scheme does not
use any FEC encoder/decoder algorithm, and thus no error correction
information is added to the payload data. The non-unique Source Block
Number mode of this FEC scheme MUST NOT be used with MUPPET.
When the EXT_FTI Header Extension is used with the Fully-Specified
Compact No-Code FEC scheme, the FEC Encoding ID Specific Format field
in the MUPPET EXT_FTI Header Extension has the length of 32 bits and
the format shown in Figure 11.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: FEC Encoding ID Specific Format for Compact No-Code FEC
Source Block Length: 32 bits
The length in bytes of every source block of the current
transport object carried in MUPPET packet payloads.
Other FEC schemes that MAY be supported by MUPPET implementations are
described in RFC 3452 [8]. These FEC schemes are defined as
Under-Specified in RFC 3452, and thus need additional specification
to be used in a protocol implementation.
5.5.2 Carrying FEC Parameters in IDT
For any transport object, an IMG sender MAY include the corresponding
FEC Object Transmission Information in the IDT as an alternative (or
in addition) to including it in the EXT_FTI Header Extension. IMG
receivers MUST support parsing the FEC Object Transmission
Information received in the IDT. The syntax used to represent the FEC
Object Transmission Information in the IDT is outside the scope of
this specification.
5.6 Payload Segmentation
IP layer fragmentation of MUPPET packets is unwanted because of the
loss-multiplier effect that reduces the efficiency of FEC schemes at
higher protocol layers. Thus, the size of a MUPPET packet with
protocol headers SHOULD be no larger than the Layer 2 MTU.
5.7 Use of Congestion Control
Luoma Expires December 29, 2003 [Page 25]
Internet-Draft MUPPET June 2003
The transport protocol defined in this document SHALL provide a
mechanism for keeping the bandwidth consumption under given limits in
a way compatible with RFC 2357 [6]. To support scenarios where MUPPET
is deployed on a unidirectional access network with fully provisioned
bandwidth allocation, implementations of this protocol SHOULD support
a bandwidth control mechanism that does not require feedback from the
receivers to the network. In accordance with RFC 2357, a bandwidth
control mechanism that operates without receiver feedback MUST NOT be
used on network links that are routed to the public Internet.
5.8 Caching Support in IMG Proxies
It may be necessary for an IMG proxy to look into the fields of the
MUPPET payload [7] to enable better support of caching policies and
congestion control. However, this may be restricted by the use of
encryption (Section 5.10).
5.9 Authentication
The MUPPET protocol SHALL support authenticated delivery of transport
objects, allowing the integrity of the transported data to be
verified (message authentication) and the sender to be identified
(source authentication). The use of message authentication is
RECOMMENDED, while the use of source authentication is OPTIONAL. The
details of authentication are outside the scope of this
specification.
OPTIONALLY, network elements such as IMG proxies that need to modify
the payloads of MUPPET messages MAY have sufficient trust to
calculate and insert valid authentication information to the modified
MUPPET packet.
5.10 Encryption
This protocol SHALL support encrypted delivery of transport objects,
only allowing the transported data to be decrypted by a given subset
of the IMG receivers. The details of encryption are outside the scope
of this specification.
OPTIONALLY, network elements such as IMG proxies that need to modify
the payloads of MUPPET messages MAY have sufficient trust to decrypt
and re-encrypt MUPPET messages
5.11 Initial Discovery of Transport Sessions
The out-of-band signaling needed to initially discover the ports, IP
addresses and TSI values used for ALC sessions and channels, their
binding to IMG sessions and channels and the bit rates used are TBD.
Luoma Expires December 29, 2003 [Page 26]
Internet-Draft MUPPET June 2003
6. Security Considerations
The main security concern with this protocol is how to protect IMG
receiver from forged MUPPET messages. Such messages could be
generated to prevent end-users from obtaining IMGs or to insert false
information into IMGs. To enable receivers to detect message
tampering, authentication information can be added to IMG transfers,
allowing (at least some of) the IMG receivers to verify if IMG
metadata originates from a particular IMG sender and if it has been
tampered with.
Another security concern is that IMG senders may not wish all of the
IMG metadata transmitted with MUPPET to be accessible to all IMG
receivers. This can be accomplished by encrypting some IMG metadata
fields (partial encryption) or all of the IMG metadata (full
encryption) transmitted as a single IMG transfer.
Partial encryption of the MUPPET payload is best implemented at
metadata-level (as described in [7]). Full encryption can be provided
on any of the following layers: IMG metadata, MUPPET or lower
protocol layers (such as IPsec or TLS). Encryption is currently not
within the scope of MUPPET, but can be implemented as an extension to
it or provided on other protocol layers.
Luoma Expires December 29, 2003 [Page 27]
Internet-Draft MUPPET June 2003
7. Contributors
Rod Walsh
Nokia Research Center
P.O. Box 100 (Visiokatu 1)
FIN-33721 Tampere
Finland
EMail: rod.walsh@nokia.com
Toni Paila
Nokia Ventures Organization
P.O. Box 209 (Itamerenkatu 11-13)
FIN-00181 Helsinki
Finland
EMail: toni.paila@nokia.com
Luoma Expires December 29, 2003 [Page 28]
Internet-Draft MUPPET June 2003
8. Acknowledgements
The author would like to thank Yuji Nomura, Henning Schulzrinne, Rami
Lehtonen, Jani Peltotalo and Sami Peltotalo for their feedback on
this document.
Luoma Expires December 29, 2003 [Page 29]
Internet-Draft MUPPET June 2003
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCD 14, March 1997.
[2] Schulzrinne, H. and Y. Nomura, "Protocol Requirements for
Internet Program Guides",
draft-nomura-mmusic-img-requirements-00 (work in progress),
February 2003.
[3] Nomura, Y., Walsh, R., Asaeda, H. and H. Schulzrinne, "A
Framework for the Usage of Internet Media Guides",
draft-nomura-mmusic-img-framework-01 (work in progress), June
2003.
[4] Luby, M., Gemmel, J., Vicisano, L., Rizzo, L. and J. Crowcroft,
"Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC
3450, December 2002.
[5] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M. and
J. Crowcroft, "Layered Coding Transport (LCT) Building Block",
RFC 3451, December 2002.
[6] Mankin, A., Romanow, A., Bradner, S. and V. Paxson, "IETF
Criteria for Evaluating Reliable Multicast Transport and
Application Protocols", RFC 2357, June 1998.
[7] Luoma, J., "Internet Media Guide Metadata Format",
draft-luoma-mmusic-img-metadata-00 (work in progress), February
2003.
[8] Luby, M., Vicisano, L., Gemmel, J., Rizzo, L., Handley, M. and
J. Crowcroft, "Forward Error Correction (FEC) Building Block",
RFC 3452, December 2002.
[9] Vicisano, L. and M. Luby, "Compact Forward Error Correction
(FEC) Schemes", draft-ietf-rmt-bb-fec-supp-compact-01 (work in
progress), May 2003.
Luoma Expires December 29, 2003 [Page 30]
Internet-Draft MUPPET June 2003
Author's Address
Juha-Pekka Luoma
Nokia Research Center
P.O. Box 100 (Visiokatu 1)
Tampere FIN-33721
Finland
EMail: juha-pekka.luoma@nokia.com
Luoma Expires December 29, 2003 [Page 31]
Internet-Draft MUPPET June 2003
Appendix A. Example Usage
Luoma Expires December 29, 2003 [Page 32]
Internet-Draft MUPPET June 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Luoma Expires December 29, 2003 [Page 33]
Internet-Draft MUPPET June 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Luoma Expires December 29, 2003 [Page 34]