rfc3451.Layered Coding Transport (LCT) Building Block

Network Working Group M. Luby Request for Comments: 3451 Digital Fountain Category: Experimental J. Gemmell Microsoft L. Vicisano Cisco L. Rizzo Univ. Pisa M. Handley ICIR J. Crowcroft Cambridge Univ. December 2002 Layered Coding Transport (LCT) Building Block

Status of this Memo

This memo defines an Experimental Protocol for the Internet

community. It does not specify an Internet standard of any kind.

Discussion and suggestions for improvement are requested.

Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract

Layered Coding Transport (LCT) provides transport level support for

reliable content delivery and stream delivery protocols. LCT is

specifically designed to support protocols using IP multicast, but

also provides support to protocols that use unicast. LCT is

compatible with congestion control that provides multiple rate

delivery to receivers and is also compatible with coding techniques

that provide reliable delivery of content.

Luby, et. al. Experimental [Page 1]

Table of Contents

1. Introduction (2)

2. Rationale (3)

3. Functionality (4)

4. Applicability (7)

4.1 Environmental Requirements and Considerations (8)

4.2 Delivery service models (10)

4.3 Congestion Control (11)

5. Packet Header Fields (12)

5.1 Default LCT header format (12)

5.2 Header-Extension Fields (17)

6. Operations (20)

6.1 Sender Operation (20)

6.2 Receiver Operation (22)

7. Requirements from Other Building Blocks (23)

8. Security Considerations (24)

9. IANA Considerations (25)

10. Acknowledgments (25)

11. References (25)

Authors’ Addresses (28)

Full Copyright Statement (29)

1. Introduction

Layered Coding Transport provides transport level support for

reliable content delivery and stream delivery protocols. Layered

Coding Transport is specifically designed to support protocols using IP multicast, but also provides support to protocols that use

unicast. Layered Coding Transport is compatible with congestion

control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of

content.

This document describes a building block as defined in RFC 3048 [26]. This document is a product of the IETF RMT WG and follows the

general guidelines provided in RFC 3269 [24].

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 BCP 14, RFC 2119 [2]. Luby, et. al. Experimental [Page 2]

Statement of Intent

This memo contains part of the definitions necessary to fully

specify a Reliable Multicast Transport protocol in accordance with RFC 2357. As per RFC 2357, the use of any reliable multicast

protocol in the Internet requires an adequate congestion control

scheme.

While waiting for such a scheme to be available, or for an

existing scheme to be proven adequate, the Reliable Multicast

Transport working group (RMT) publishes this Request for Comments in the "Experimental" category.

It is the intent of RMT to re-submit this specification as an IETF Proposed Standard as soon as the above condition is met.

2. Rationale

LCT provides transport level support for massively scalable protocols using the IP multicast network service. The support that LCT

provides is common to a variety of very important applications,

including reliable content delivery and streaming applications.

An LCT session comprises multiple channels originating at a single

sender that are used for some period of time to carry packets

pertaining to the transmission of one or more objects that can be of interest to receivers. The logic behind defining a session as

originating from a single sender is that this is the right

granularity to regulate packet traffic via congestion control. One

rationale for using multiple channels within the same session is that there are massively scalable congestion control protocols that use

multiple channels per session. These congestion control protocols

are considered to be layered because a receiver joins and leaves

channels in a layered order during its participation in the session. The use of layered channels is also useful for streaming

applications.

There are coding techniques that provide massively scalable

reliability and asynchronous delivery which are compatible with both layered congestion control and with LCT. When all are combined the

result is a massively scalable reliable asynchronous content delivery protocol that is network friendly. LCT also provides functionality

that can be used for other applications as well, e.g., layered

streaming applications.

Luby, et. al. Experimental [Page 3]

LCT avoids providing functionality that is not massively scalable.

For example, LCT does not provide any mechanisms for sending

information from receivers to senders, although this does not rule

out protocols that both use LCT and do require sending information

from receivers to senders.

LCT includes general support for congestion control that must be

used. It does not, however, specify which congestion control should be used. The rationale for this is that congestion control must be

provided by any protocol that is network friendly, and yet the

different applications that can use LCT will not have the same

requirements for congestion control. For example, a content delivery protocol may strive to use all available bandwidth between receivers and the sender. It must, therefore, drastically back off its rate

when there is competing traffic. On the other hand, a streaming

delivery protocol may strive to maintain a constant rate instead of

trying to use all available bandwidth, and it may not back off its

rate as fast when there is competing traffic.

Beyond support for congestion control, LCT provides a number of

fields and supports functionality commonly required by many

protocols. For example, LCT provides a Transmission Session ID that can be used to identify which session each received packet belongs

to. This is important because a receiver may be joined to many

sessions concurrently, and thus it is very useful to be able to

demultiplex packets as they arrive according to which session they

belong to. As another example, LCT provides optional support for

identifying which object each packet is carrying information about.

Therefore, LCT provides many of the commonly used fields and support for functionality required by many protocols.

3. Functionality

An LCT session consists of a set of logically grouped LCT channels

associated with a single sender carrying packets with LCT headers for one or more objects. An LCT channel is defined by the combination of a sender and an address associated with the channel by the sender. A receiver joins a channel to start receiving the data packets sent to the channel by the sender, and a receiver leaves a channel to stop

receiving data packets from the channel.

LCT is meant to be combined with other building blocks so that the

resulting overall protocol is massively scalable. Scalability refers to the behavior of the protocol in relation to the number of

receivers and network paths, their heterogeneity, and the ability to accommodate dynamically variable sets of receivers. Scalability

limitations can come from memory or processing requirements, or from the amount of feedback control and redundant data packet traffic Luby, et. al. Experimental [Page 4]

generated by the protocol. In turn, such limitations may be a

consequence of the features that a complete reliable content delivery or stream delivery protocol is expected to provide.

The LCT header provides a number of fields that are useful for

conveying in-band session information to receivers. One of the

required fields is the Transmission Session ID (TSI), which allows

the receiver of a session to uniquely identify received packets as

part of the session. Another required field is the Congestion

Control Information (CCI), which allows the receiver to perform the

required congestion control on the packets received within the

session. Other LCT fields provide optional but often very useful

additional information for the session. For example, the Transport

Object Identifier (TOI) identifies which object the packet contains

data for. As other examples, the Sender Current Time (SCT) conveys

the time when the packet was sent from the sender to the receiver,

the Expected Residual Time (ERT) conveys the amount of time the

session will be continued for, flags for indicating the close of the session and the close of sending packets for an object, and header

extensions for fields that for example can be used for packet

authentication.

LCT provides support for congestion control. Congestion control MUST be used that conforms to RFC 2357 [13] between receivers and the

sender for each LCT session. Congestion control refers to the

ability to adapt throughput to the available bandwidth on the path

from the sender to a receiver, and to share bandwidth fairly with

competing flows such as TCP. Thus, the total flow of packets flowing to each receiver participating in an LCT session MUST NOT compete

unfairly with existing flow adaptive protocols such as TCP.

A multiple rate or a single rate congestion control protocol can be

used with LCT. For multiple rate protocols, a session typically

consists of more than one channel and the sender sends packets to the channels in the session at rates that do not depend on the receivers. Each receiver adjusts its reception rate during its participation in the session by joining and leaving channels dynamically depending on the available bandwidth to the sender independent of all other

receivers. Thus, for multiple rate protocols, the reception rate of each receiver may vary dynamically independent of the other

receivers.

For single rate protocols, a session typically consists of one

channel and the sender sends packets to the channel at variable rates over time depending on feedback from receivers. Each receiver

remains joined to the channel during its participation in the

session. Thus, for single rate protocols, the reception rate of each receiver may vary dynamically but in coordination with all receivers. Luby, et. al. Experimental [Page 5]

Generally, a multiple rate protocol is preferable to a single rate

protocol in a heterogeneous receiver environment, since generally it more easily achieves scalability to many receivers and provides

higher throughput to each individual receiver. Some possible

multiple rate congestion control protocols are described in [22],

[3], and [25]. A possible single rate congestion control protocol is described in [19].

Layered coding refers to the ability to produce a coded stream of

packets that can be partitioned into an ordered set of layers. The

coding is meant to provide some form of reliability, and the layering is meant to allow the receiver experience (in terms of quality of

playout, or overall transfer speed) to vary in a predictable way

depending on how many consecutive layers of packets the receiver is

receiving.

The concept of layered coding was first introduced with reference to audio and video streams. For example, the information associated

with a TV broadcast could be partitioned into three layers,

corresponding to black and white, color, and HDTV quality. Receivers can experience different quality without the need for the sender to

replicate information in the different layers.

The concept of layered coding can be naturally extended to reliable

content delivery protocols when Forward Error Correction (FEC)

techniques are used for coding the data stream. Descriptions of this can be found in [20], [18], [7], [22] and [4]. By using FEC, the

data stream is transformed in such a way that reconstruction of a

data object does not depend on the reception of specific data

packets, but only on the number of different packets received. As a result, by increasing the number of layers a receiver is receiving

from, the receiver can reduce the transfer time accordingly. Using

FEC to provide reliability can increase scalability dramatically in

comparison to other methods for providing reliability. More details on the use of FEC for reliable content delivery can be found in [11]. Reliable protocols aim at giving guarantees on the reliable delivery of data from the sender to the intended recipients. Guarantees vary from simple packet data integrity to reliable delivery of a precise

copy of an object to all intended recipients. Several reliable

content delivery protocols have been built on top of IP multicast

using methods other than FEC, but scalability was not the primary

design goal for many of them.

Two of the key difficulties in scaling reliable content delivery

using IP multicast are dealing with the amount of data that flows

from receivers back to the sender, and the associated response

(generally data retransmissions) from the sender. Protocols that Luby, et. al. Experimental [Page 6]

avoid any such feedback, and minimize the amount of retransmissions, can be massively scalable. LCT can be used in conjunction with FEC

codes or a layered codec to achieve reliability with little or no

feedback.

Protocol instantiations MAY be built by combining the LCT framework

with other components. A complete protocol instantiation that uses

LCT MUST include a congestion control protocol that is compatible

with LCT and that conforms to RFC 2357 [13]. A complete protocol

instantiation that uses LCT MAY include a scalable reliability

protocol that is compatible with LCT, it MAY include an session

control protocol that is compatible with LCT, and it MAY include

other protocols such as security protocols.

4. Applicability

An LCT session comprises a logically related set of one or more LCT

channels originating at a single sender. The channels are used for

some period of time to carry packets containing LCT headers, and

these headers pertain to the transmission of one or more objects that can be of interest to receivers.

LCT is most applicable for delivery of objects or streams in a

session of substantial length, i.e., objects or streams that range in aggregate length from hundreds of kilobytes to many gigabytes, and

where the duration of the session is on the order of tens of seconds or more.

As an example, an LCT session could be used to deliver a TV program

using three LCT channels. Receiving packets from the first LCT

channel could allow black and white reception. Receiving the first

two LCT channels could also permit color reception. Receiving all

three channels could allow HDTV quality reception. Objects in this

example could correspond to individual TV programs being transmitted. As another example, a reliable LCT session could be used to reliably deliver hourly-updated weather maps (objects) using ten LCT channels at different rates, using FEC coding. A receiver may join and

concurrently receive packets from subsets of these channels, until it has enough packets in total to recover the object, then leave the

session (or remain connected listening for session description

information only) until it is time to receive the next object. In

this case, the quality metric is the time required to receive each

object.

Before joining a session, the receivers MUST obtain enough of the

session description to start the session. This MUST include the

relevant session parameters needed by a receiver to participate in Luby, et. al. Experimental [Page 7]

the session, including all information relevant to congestion

control. The session description is determined by the sender, and is typically communicated to the receivers out-of-band. In some cases, as described later, parts of the session description that are not

required to initiate a session MAY be included in the LCT header or

communicated to a receiver out-of-band after the receiver has joined the session.

An encoder MAY be used to generate the data that is placed in the

packet payload in order to provide reliability. A suitable decoder

is used to reproduce the original information from the packet

payload. There MAY be a reliability header that follows the LCT

header if such an encoder and decoder is used. The reliability

header helps to describe the encoding data carried in the payload of the packet. The format of the reliability header depends on the

coding used, and this is negotiated out-of-band. As an example, one of the FEC headers described in [12] could be used.

For LCT, when multiple rate congestion control is used, congestion

control is achieved by sending packets associated with a given

session to several LCT channels. Individual receivers dynamically

join one or more of these channels, according to the network

congestion as seen by the receiver. LCT headers include an opaque

field which MUST be used to convey congestion control information to the receivers. The actual congestion control scheme to use with LCT is negotiated out-of-band. Some examples of congestion control

protocols that may be suitable for content delivery are described in [22], [3], and [25]. Other congestion controls may be suitable when LCT is used for a streaming application.

This document does not specify and restrict the type of exchanges

between LCT (or any PI built on top of LCT) and an upper application. Some upper APIs may use an object-oriented approach, where the only

possible unit of data exchanged between LCT (or any PI built on top

of LCT) and an application, either at a source or at a receiver, is

an object. Other APIs may enable a sending or receiving application to exchange a subset of an object with LCT (or any PI built on top of LCT), or may even follow a streaming model. These considerations are outside the scope of this document.

4.1 Environmental Requirements and Considerations

LCT is intended for congestion controlled delivery of objects and

streams (both reliable content delivery and streaming of multimedia

information).

Luby, et. al. Experimental [Page 8]

LCT can be used with both multicast and unicast delivery. LCT

requires connectivity between a sender and receivers but does not

require connectivity from receivers to a sender. LCT inherently

works with all types of networks, including LANs, WANs, Intranets,

the Internet, asymmetric networks, wireless networks, and satellite

networks. Thus, the inherent raw scalability of LCT is unlimited.

However, when other specific applications are built on top of LCT,

then these applications by their very nature may limit scalability.

For example, if an application requires receivers to retrieve out of band information in order to join a session, or an application allows receivers to send requests back to the sender to report reception

statistics, then the scalability of the application is limited by the ability to send, receive, and process this additional data.

LCT requires receivers to be able to uniquely identify and

demultiplex packets associated with an LCT session. In particular,

there MUST be a Transport Session Identifier (TSI) associated with

each LCT session. The TSI is scoped by the IP address of the sender, and the IP address of the sender together with the TSI MUST uniquely identify the session. If the underlying transport is UDP as

described in RFC 768 [16], then the 16 bit UDP source port number MAY serve as the TSI for the session. The TSI value MUST be the same in all places it occurs within a packet. If there is no underlying TSI provided by the network, transport or any other layer, then the TSI

MUST be included in the LCT header.

LCT is presumed to be used with an underlying network or transport

service that is a "best effort" service that does not guarantee

packet reception or packet reception order, and which does not have

any support for flow or congestion control. For example, the Any-

Source Multicast (ASM) model of IP multicast as defined in RFC 1112

[5] is such a "best effort" network service. While the basic service provided by RFC 1112 is largely scalable, providing congestion

control or reliability should be done carefully to avoid severe

scalability limitations, especially in presence of heterogeneous sets of receivers.

There are currently two models of multicast delivery, the Any-Source Multicast (ASM) model as defined in RFC 1112 [5] and the Source-

Specific Multicast (SSM) model as defined in [10]. LCT works with

both multicast models, but in a slightly different way with somewhat different environmental concerns. When using ASM, a sender S sends

packets to a multicast group G, and the LCT channel address consists of the pair (S,G), where S is the IP address of the sender and G is a multicast group address. When using SSM, a sender S sends packets to an SSM channel (S,G), and the LCT channel address coincides with the SSM channel address.

Luby, et. al. Experimental [Page 9]

A sender can locally allocate unique SSM channel addresses, and this makes allocation of LCT channel addresses easy with SSM. To allocate LCT channel addresses using ASM, the sender must uniquely chose the

ASM multicast group address across the scope of the group, and this

makes allocation of LCT channel addresses more difficult with ASM.

LCT channels and SSM channels coincide, and thus the receiver will

only receive packets sent to the requested LCT channel. With ASM,

the receiver joins an LCT channel by joining a multicast group G, and all packets sent to G, regardless of the sender, may be received by

the receiver. Thus, SSM has compelling security advantages over ASM for prevention of denial of service attacks. In either case,

receivers SHOULD use mechanisms to filter out packets from unwanted

sources.

Some networks are not amenable to some congestion control protocols

that could be used with LCT. In particular, for a satellite or

wireless network, there may be no mechanism for receivers to

effectively reduce their reception rate since there may be a fixed

transmission rate allocated to the session.

4.2 Delivery service models

LCT can support several different delivery service models. Two

examples are briefly described here.

Push service model.

One way a push service model can be used for reliable content

delivery is to deliver a series of objects. For example, a receiver could join the session and dynamically adapt the number of LCT

channels the receiver is joined to until enough packets have been

received to reconstruct an object. After reconstructing the object

the receiver may stay in the session and wait for the transmission of the next object.

The push model is particularly attractive in satellite networks and

wireless networks. In these cases, a session may consist of one

fixed rate LCT channel.

On-demand content delivery model.

For an on-demand content delivery service model, senders typically

transmit for some given time period selected to be long enough to

allow all the intended receivers to join the session and recover the object. For example a popular software update might be transmitted Luby, et. al. Experimental [Page 10]

using LCT for several days, even though a receiver may be able to

complete the download in one hour total of connection time, perhaps

spread over several intervals of time.

In this case the receivers join the session, and dynamically adapt

the number of LCT channels they subscribe to according to the

available bandwidth. Receivers then drop from the session when they have received enough packets to recover the object.

As an example, assume that an object is 50 MB. The sender could send 1 KB packets to the first LCT channel at 50 packets per second, so

that receivers using just this LCT channel could complete reception

of the object in 1,000 seconds in absence of loss, and would be able to complete reception even in presence of some substantial amount of losses with the use of coding for reliability. Furthermore, the

sender could use a number of LCT channels such that the aggregate

rate of 1 KB packets to all LCT channels is 1,000 packets per second, so that a receiver could be able to complete reception of the object in as little 50 seconds (assuming no loss and that the congestion

control mechanism immediately converges to the use of all LCT

channels).

Other service models.

There are many other delivery service models that LCT can be used for that are not covered above. As examples, a live streaming or an on- demand archival content streaming service model. A description of

the many potential applications, the appropriate delivery service

model, and the additional mechanisms to support such functionalities when combined with LCT is beyond the scope of this document. This

document only attempts to describe the minimal common scalable

elements to these diverse applications using LCT as the delivery

transport.

4.3 Congestion Control

The specific congestion control protocol to be used for LCT sessions depends on the type of content to be delivered. While the general

behavior of the congestion control protocol is to reduce the

throughput in presence of congestion and gradually increase it in the absence of congestion, the actual dynamic behavior (e.g. response to single losses) can vary.

Some possible congestion control protocols for reliable content

delivery using LCT are described in [22], [3], and [25]. Different

delivery service models might require different congestion control

protocols.

Luby, et. al. Experimental [Page 11]

5. Packet Header Fields

Packets sent to an LCT session MUST include an "LCT header". The LCT header format described below is the default format, and this is the format that is recommended for use by protocol instantiations to

ensure a uniform format across different protocol instantiations.

Other LCT header formats MAY be used by protocol instantiations, but if the default LCT header format is not used by a protocol

instantiation that uses LCT, then the protocol instantiation MUST

specify the lengths and positions within the LCT header it uses of

all fields described in the default LCT header.

Other building blocks MAY describe some of the same fields as

described for the LCT header. It is RECOMMENDED that protocol

instantiations using multiple building blocks include shared fields

at most once in each packet. Thus, for example, if another building block is used with LCT that includes the optional Expected Residual

Time field, then the Expected Residual Time field SHOULD be carried

in each packet at most once.

The position of the LCT header within a packet MUST be specified by

any protocol instantiation that uses LCT.

5.1 Default LCT header format

The default LCT header is of variable size, which is specified by a

length field in the third byte of the header. In the LCT header, all integer fields are carried in "big-endian" or "network order" format, that is, most significant byte (octet) first. Bits designated as

"padding" or "reserved" (r) MUST by set to 0 by senders and ignored

by receivers. Unless otherwise noted, numeric constants in this

specification are in decimal (base 10).

The format of the default LCT header is depicted in Figure 1.

Luby, et. al. Experimental [Page 12]

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, length = 32*(C+1) bits) |

| ... |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Transport Session Identifier (TSI, length = 32*S+16*H bits) |

| ... |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Transport Object Identifier (TOI, length = 32*O+16*H bits) |

| ... |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Sender Current Time (SCT, if T = 1) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Expected Residual Time (ERT, if R = 1) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Header Extensions (if applicable) |

| ... |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1 - Default LCT header format

The function and length of each field in the default LCT header is

the following. Fields marked as "1" mean that the corresponding bits MUST be set to "1" by the sender. Fields marked as "r" or "0" mean

that the corresponding bits MUST be set to "0" by the sender.

LCT version number (V): 4 bits

Indicates the LCT version number. The LCT version number for

this specification is 1.

Congestion control flag (C): 2 bits

C=0 indicates the Congestion Control Information (CCI) field is 32-bits in length. C=1 indicates the CCI field is 64-bits in

length. C=2 indicates the CCI field is 96-bits in length. C=3 indicates the CCI field is 128-bits in length.

Reserved (r): 2 bits

Reserved for future use. A sender MUST set these bits to zero and a receiver MUST ignore these bits.

Luby, et. al. Experimental [Page 13]

Transport Session Identifier flag (S): 1 bit

This is the number of full 32-bit words in the TSI field. The TSI field is 32*S + 16*H bits in length, i.e. the length is

either 0 bits, 16 bits, 32 bits, or 48 bits.

Transport Object Identifier flag (O): 2 bits

This is the number of full 32-bit words in the TOI field. The TOI field is 32*O + 16*H bits in length, i.e., the length is

either 0 bits, 16 bits, 32 bits, 48 bits, 64 bits, 80 bits, 96 bits, or 112 bits.

Half-word flag (H): 1 bit

The TSI and the TOI fields are both multiples of 32-bits plus

16*H bits in length. This allows the TSI and TOI field lengths to be multiples of a half-word (16 bits), while ensuring that

the aggregate length of the TSI and TOI fields is a multiple of 32-bits.

Sender Current Time present flag (T): 1 bit

T = 0 indicates that the Sender Current Time (SCT) field is not present. T = 1 indicates that the SCT field is present. The

SCT is inserted by senders to indicate to receivers how long

the session has been in progress.

Expected Residual Time present flag (R): 1 bit

R = 0 indicates that the Expected Residual Time (ERT) field is not present. R = 1 indicates that the ERT field is present.

The ERT is inserted by senders to indicate to receivers how

much longer the session / object transmission will continue.

Senders MUST NOT set R = 1 when the ERT for the session is more than 2^32-1 time units (approximately 49 days), where time is

measured in units of milliseconds.

Close Session flag (A): 1 bit

Normally, A is set to 0. The sender MAY set A to 1 when

termination of transmission of packets for the session is

imminent. A MAY be set to 1 in just the last packet

transmitted for the session, or A MAY be set to 1 in the last

few seconds of packets transmitted for the session. Once the

sender sets A to 1 in one packet, the sender SHOULD set A to 1 in all subsequent packets until termination of transmission of Luby, et. al. Experimental [Page 14]

packets for the session. A received packet with A set to 1

indicates to a receiver that the sender will immediately stop

sending packets for the session. When a receiver receives a

packet with A set to 1 the receiver SHOULD assume that no more packets will be sent to the session.

Close Object flag (B): 1 bit

Normally, B is set to 0. The sender MAY set B to 1 when

termination of transmission of packets for an object is

imminent. If the TOI field is in use and B is set to 1 then

termination of transmission for the object identified by the

TOI field is imminent. If the TOI field is not in use and B is set to 1 then termination of transmission for the one object in the session identified by out-of-band information is imminent.

B MAY be set to 1 in just the last packet transmitted for the

object, or B MAY be set to 1 in the last few seconds packets

transmitted for the object. Once the sender sets B to 1 in one packet for a particular object, the sender SHOULD set B to 1 in all subsequent packets for the object until termination of

transmission of packets for the object. A received packet with B set to 1 indicates to a receiver that the sender will

immediately stop sending packets for the object. When a

receiver receives a packet with B set to 1 then it SHOULD

assume that no more packets will be sent for the object to the session.

LCT header length (HDR_LEN): 8 bits

Total length of the LCT header in units of 32-bit words. The

length of the LCT header MUST be a multiple of 32-bits. This

field can be used to directly access the portion of the packet beyond the LCT header, i.e., to the first other header if it

exists, or to the packet payload if it exists and there is no

other header, or to the end of the packet if there are no other headers or packet payload.

Codepoint (CP): 8 bits

An opaque identifier which is passed to the packet payload

decoder to convey information on the codec being used for the

packet payload. The mapping between the codepoint and the

actual codec is defined on a per session basis and communicated out-of-band as part of the session description information.

The use of the CP field is similar to the Payload Type (PT)

field in RTP headers as described in RFC 1889 [21].

Luby, et. al. Experimental [Page 15]

Congestion Control Information (CCI): 32, 64, 96 or 128 bits

Used to carry congestion control information. For example, the congestion control information could include layer numbers,

logical channel numbers, and sequence numbers. This field is

opaque for the purpose of this specification.

This field MUST be 32 bits if C=0.

This field MUST be 64 bits if C=1.

This field MUST be 96 bits if C=2.

This field MUST be 128 bits if C=3.

Transport Session Identifier (TSI): 0, 16, 32 or 48 bits

The TSI uniquely identifies a session among all sessions from a particular sender. The TSI is scoped by the IP address of the sender, and thus the IP address of the sender and the TSI

together uniquely identify the session. Although a TSI in

conjunction with the IP address of the sender always uniquely

identifies a session, whether or not the TSI is included in the LCT header depends on what is used as the TSI value. If the

underlying transport is UDP, then the 16 bit UDP source port

number MAY serve as the TSI for the session. If the TSI value appears multiple times in a packet then all occurrences MUST be the same value. If there is no underlying TSI provided by the network, transport or any other layer, then the TSI MUST be

included in the LCT header.

The TSI MUST be unique among all sessions served by the sender during the period when the session is active, and for a large

period of time preceding and following when the session is

active. A primary purpose of the TSI is to prevent receivers

from inadvertently accepting packets from a sender that belong to sessions other than the sessions receivers are subscribed

to. For example, suppose a session is deactivated and then

another session is activated by a sender and the two sessions

use an overlapping set of channels. A receiver that connects

and remains connected to the first session during this sender

activity could possibly accept packets from the second session as belonging to the first session if the TSI for the two

sessions were identical. The mapping of TSI field values to

sessions is outside the scope of this document and is to be

done out-of-band.

The length of the TSI field is 32*S + 16*H bits. Note that the aggregate lengths of the TSI field plus the TOI field is a

multiple of 32 bits.

Luby, et. al. Experimental [Page 16]

Transport Object Identifier (TOI): 0, 16, 32, 48, 64, 80, 96 or 112 bits.

This field indicates which object within the session this

packet pertains to. For example, a sender might send a number of files in the same session, using TOI=0 for the first file,

TOI=1 for the second one, etc. As another example, the TOI may be a unique global identifier of the object that is being

transmitted from several senders concurrently, and the TOI

value may be the output of a hash function applied to the

object. The mapping of TOI field values to objects is outside the scope of this document and is to be done out-of-band. The TOI field MUST be used in all packets if more than one object

is to be transmitted in a session, i.e. the TOI field is either present in all the packets of a session or is never present.

The length of the TOI field is 32*O + 16*H bits. Note that the aggregate lengths of the TSI field plus the TOI field is a

multiple of 32 bits.

Sender Current Time (SCT): 0 or 32 bits

This field represents the current clock at the sender and at

the time this packet was transmitted, measured in units of 1ms and computed modulo 2^32 units from the start of the session.

This field MUST NOT be present if T=0 and MUST be present if

T=1.

Expected Residual Time (ERT): 0 or 32 bits

This field represents the sender expected residual transmission time for the current session or for the transmission of the

current object, measured in units of 1ms. If the packet

containing the ERT field also contains the TOI field, then ERT refers to the object corresponding to the TOI field, otherwise it refers to the session.

This field MUST NOT be present if R=0 and MUST be present if

R=1.

5.2 Header-Extension Fields

Header Extensions are used in LCT to accommodate optional header

fields that are not always used or have variable size. Examples of

the use of Header Extensions include:

o Extended-size versions of already existing header fields.

Luby, et. al. Experimental [Page 17]

o Sender and Receiver authentication information.

The presence of Header Extensions can be inferred by the LCT header

length (HDR_LEN): if HDR_LEN is larger than the length of the

standard header then the remaining header space is taken by Header

Extension fields.

If present, Header Extensions MUST be processed to ensure that they

are recognized before performing any congestion control procedure or otherwise accepting a packet. The default action for unrecognized

header extensions is to ignore them. This allows the future

introduction of backward-compatible enhancements to LCT without

changing the LCT version number. Non backward-compatible header

extensions CANNOT be introduced without changing the LCT version

number.

Protocol instantiation MAY override this default behavior for PI-

specific extensions (see below).

There are two formats for Header Extension fields, as depicted below. The first format is used for variable-length extensions, with Header Extension Type (HET) values between 0 and 127. The second format is used for fixed length (one 32-bit word) extensions, using HET values from 127 to 255.

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 (<=127) | HEL | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +

. .

. Header Extension Content (HEC) .

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 (>=128) | Header Extension Content (HEC) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2 - Format of additional headers

The explanation of each sub-field is the following:

Header Extension Type (HET): 8 bits

The type of the Header Extension. This document defines a

number of possible types. Additional types may be defined in Luby, et. al. Experimental [Page 18]

future versions of this specification. HET values from 0 to

127 are used for variable-length Header Extensions. HET values from 128 to 255 are used for fixed-length 32-bit Header

Extensions.

Header Extension Length (HEL): 8 bits

The length of the whole Header Extension field, expressed in

multiples of 32-bit words. This field MUST be present for

variable-length extensions (HET between 0 and 127) and MUST NOT be present for fixed-length extensions (HET between 128 and

255).

Header Extension Content (HEC): variable length

The content of the Header Extension. The format of this sub-

field depends on the Header Extension type. For fixed-length

Header Extensions, the HEC is 24 bits. For variable-length

Header Extensions, the HEC field has variable size, as

specified by the HEL field. Note that the length of each

Header Extension field MUST be a multiple of 32 bits. Also

note that the total size of the LCT header, including all

Header Extensions and all optional header fields, cannot exceed 255 32-bit words.

Header Extensions are further divided between general LCT extensions and Protocol Instantiation specific extensions (PI-specific).

General LCT extensions have HET in the ranges 0:63 and 128:191

inclusive. PI-specific extensions have HET in the ranges 64:127 and 192:255 inclusive.

General LCT extensions are intended to allow the introduction of

backward-compatible enhancements to LCT without changing the LCT

version number. Non backward-compatible header extensions CANNOT be introduced without changing the LCT version number.

PI-specific extensions are reserved for PI-specific use with semantic and default parsing actions defined by the PI.

The following general LCT Header Extension types are defined:

EXT_NOP=0 No-Operation extension.

The information present in this extension field MUST be ignored by receivers.

EXT_AUTH=1 Packet authentication extension

Information used to authenticate the sender of the

packet. The format of this Header Extension and its Luby, et. al. Experimental [Page 19]

相关推荐
相关主题
热门推荐