3 - 4 - 6 - 8 - A - B - C - D - E - F - G - H - I - J - L - M - N - O - P - Q - R - S - T - U - V - W
transport
Click on the red underlined text to get to the source
... Multicast (NORM)
protocol is designed to provide reliable transport of data from one
or more sender(s) to a group ...
...
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 ...
...
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 ...
... group address,
but unicast transport may also be established or applied as an
adjunct to multicast delivery ...
... file storage). Other
than that distinction, the two are identical, providing for reliable
transport of finite (but potentially very large) units of content.
These static data and file services are anticipated to be useful for
...
... services might make use of these
transport object types, too. The use of the NORM_OBJECT_STREAM type
...
... NORM_OBJECT_STREAM provides for reliable transport analogous to that
of the Transmission Control Protocol (TCP ...
... the receiver node's participation in the current transport activity.
This also allows the protocol to be flexible with minimal pre-
coordination among senders ...
... alternatively be embedded within the data content. NORM does
identify transmitted content (NormObjects) with transport identifiers
that are applicable only while the sender ...
... sender is transmitting and/or
repairing the given object. These transport data content identifiers
(NormTransportIds) are assigned in a monotonically increasing fashion
...
... sender
maintains its NormTransportId assignments independently so that
individual NormObjects may be uniquely identified during transport
with the concatenation of the sender ...
...
To summarize, the NORM protocol provides reliable transport of
different types of data content (including potentially mixed types).
The senders ...
... group.
Mechanisms for "out-of-band" information and other transport control
mechanisms are specified for use by applications to form complete
reliable multicast ...
... NORM to scale well while maintaining
reliable data delivery transport with low latency relative to the
network topology ...
... provide by TCP for unicast data transport. The format of the stream
content is application-defined and may be byte or message oriented.
...
... sender-assigned and applicable and valid only during
a NormObject's actual _transport_ (i.e., for as long as the sender is
transmitting ...
... out-of-band" context information for a given
transport object. A single NORM_INFO message can be associated with
a NormObject. Because of its atomic nature, missing NORM ...
... NORM are designed to provide some
measure of general purpose utility, it is important to emphasize the
understanding that "no one size fits all" in the reliable multicast
transport arena. There are numerous engineering tradeoffs involved
in reliable multicast transport design and this requires an increased
...
... understanding that "no one size fits all" in the reliable multicast
transport arena. There are numerous engineering tradeoffs involved
in reliable multicast transport design and this requires an increased
awareness of application and network architecture considerations.
...
... delivery delay, group dynamics, mobility, congestion
control, and transport across low capacity connections. NORM
...
... multicast applications outside of bulk data transfer, but there is an
assumed model of bulk transfer transport service that drives the
trade-offs that determine the scalability and performance ...
... buffering resources than typical point-to-point transport protocols.
This is because NORM feedback suppression is based upon randomly-
...
... 4] and [5], completely specifies a
working reliable multicast transport protocol that conforms to the
requirements described in RFC 2357 ...
... | instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | fec_id | object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_payload ...
... segments (or info content)
for those objects are not received (i.e., a gap in the
"object_transport_id" sequence is noted). In this case, the sender
should invoke the NORM ...
... performance.
The "object_transport_id" field is a monotonically and incrementally
increasing value assigned by the sender to NormObjects being
...
... sender to NormObjects being
transmitted. Transmissions and repair requests related to that
object use the same "object_transport_id" value. For sessions of
very long or indefinite duration, the "object_transport ...
... transport_id" value. For sessions of
very long or indefinite duration, the "object_transport_id" field may
be repeated, but it is presumed that the 16-bit field size provides
...
... concatenation of the sender "source_id"
and the given "object_transport_id". Note that NORM_INFO messages
associated with the identified object carry the same
...
... NORM_INFO messages
associated with the identified object carry the same
"object_transport_id" value.
The "fec_payload ...
... concatenation of
object_transport_id::fec_payload_id can be viewed as a unique
transport protocol ...
... transport_id::fec_payload_id can be viewed as a unique
transport protocol data unit identifier for the attached segment ...
... 5]) is required to properly receive and
decode NORM transport objects. This information MAY be provided as
out-of-band session information ...
... payload_len" and "payload_offset" fields are
present ONLY for transport objects of type NORM_OBJECT_STREAM. These
...
... fields are NOT present when the "flags" portion of the NORM_DATA
message indicate the transport object if of type NORM_OBJECT_FILE or
NORM ...
... NORM_DATA messages for the
corresponding "object_transport_id" and the NORM_INFO message shall
be transmitted as the first message for the NormObject.
...
... | instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | fec_id | object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header ...
...
The "instance_id", "grtt", "backoff", "gsize", "flags", "fec_id", and
"object_transport_id" fields carry the same information and serve the
same purpose as with NORM_DATA messages ...
... block size. This is analogous to application trade-offs for other
transport protocols such as the selection of different TCP modes of
operation such as "no delay", etc.
...
... | instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor = 1 | fec_id | object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_payload ...
... The "fec_id" field indicates the FEC type used for the flushing
"object_transport_id" and implies the size and format of the
"fec_payload_id" field. Note the "hdr_len" value for the
...
... header extensions are present.
The "object_transport_id" and "fec_payload_id" fields indicate the
sender ...
... sender is requesting explicit positive acknowledgment of reception up
through the transmission point identified by the
"object_transport_id" and "fec_payload_id" fields. The length of the
list can be inferred from the length of the received NORM ...
... | instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor = 3 | fec_id | object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_payload ...
... message which initiated the squelch transmission.
The "object_transport_id" and "fec_payload_id" fields are
concatenated to indicate the beginning of the sender ...
... CMD(SQUELCH)
generation. The NormObjectIds in the "invalid_object_list" MUST be
greater than the "object_transport_id" marking the beginning of the
sender's repair window. This insures convergence ...
... sender's current window allows the sender application (most notably
for discrete "object" based transport) to arbitrarily invalidate
(i.e., dequeue) portions of enqueued content (e.g., certain objects)
for which it no longer wishes to provide reliable transport ...
... transport) to arbitrarily invalidate
(i.e., dequeue) portions of enqueued content (e.g., certain objects)
for which it no longer wishes to provide reliable transport.
...
... segment, entire FEC coding block, or entire transport object).
Possible flag values include:
...
... NORM_NACK_SEGMENT flag is set, the "object_transport_id" and
"fec_payload_id" fields are used to determine which sets or ranges ...
... NORM_INFO segment for the indicated
"object_transport_id". Note the NORM_NACK_INFO may be set in
...
... indicates the receiver is missing the entire NormTransportObject
referenced by the "object_transport_id". This also implicitly
requests any available NORM_INFO for the NormObject, if applicable.
...
... The "repair_request_items" field consists of a list of individual or
range pairs of transport data unit identifiers in the following
...
... 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id | reserved | object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_payload ...
... NACK content.
The "object_transport_id" corresponds to the NormObject for which
repair is being requested and the "fec_payload_id" identifies the
...
... NORM_NACK messages with their repair requests in ordinal order with
respect to "object_transport_id" and "fec_payload_id" values. The
"nack_payload ...
... | form = 1 | flags = 0x01 | length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id = 129 | reserved | object_transport_id = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number = 3 |
...
... encoding_symbol_id = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id = 129 | reserved | object_transport_id = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number = 3 |
...
... encoding_symbol_id = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id = 129 | reserved | object_transport_id = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number = 3 |
...
... | form = 2 | flags = 0x01 | length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id = 129 | reserved | object_transport_id = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number = 6 |
...
... encoding_symbol_id = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id = 129 | reserved | object_transport_id = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number = 6 |
...
... | form = 1 | flags = 0x05 | length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id = 129 | reserved | object_transport_id = 19 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number = 1 |
...
... 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id | reserved | object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_payload ...
... NORM_INFO messages may optionally precede the
transmission of data content for NORM transport objects.
3) As receivers ...
... receivers must use a common algorithm for logically
segmenting transport data into FEC encoding blocks and symbols so
...
... receivers use these FEC parameters, along with the
NormSegmentSize and transport object size to compute the source block
structure for transport objects. These parameters are provided in
...
... NormSegmentSize and transport object size to compute the source block
structure for transport objects. These parameters are provided in
the FEC Transmission Information for each object. The algorithm ...
... NORM_OBJECT_DATA and NORM_OBJECT_FILE transport object types where
the object size is fixed and predetermined. For NORM_OBJECT_STREAM ...
... NORM block segmentation algorithm is defined as follows. For a
transport object of a given length (L_obj) in bytes, a first number
of FEC source blocks (N_large) is delineated of a larger block size ...
... sender's NormSegmentSize, the block
segmentation for a given NORM transport object is determined as
follows:
...
... Outputs:
N_total = The total number of source blocks into which the transport
object is partitioned.
...
... Algorithm:
1) The total number of source symbols in the transport object is
computed as: S_total = L_obj/L_sym [rounded up to the nearest
integer ...
... integer]
2) The transport object is partitioned into N_total source blocks,
where: N_total = S_total/B_max [rounded up to the nearest
integer ...
... receivers joining the group to limit or avoid repair requests for
transport objects already in progress. The NORM sender
implementation may wish to impose additional constraints ...
... NORM_CMD(SQUELCH)
message SHALL begin with the lowest "object_transport_id" from the
invalid NORM_NACK ...
... NORM_CMD(SQUELCH)
transmission. Lower ordinal invalid "object_transport_ids" should be
included only while the NORM_CMD ...
... advantage of timing and transmission scheduling information available
to the NORM transport.
The NORM ...
... NORM_CMD(FLUSH) contain a
"object_transport_id" and "fec_payload_id" denoting the watermark
transmission point for which acknowledgment is requested. This
...
... Kermode, R. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002. ...
... Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S., and M. Luby, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer", RFC 3048, January 2001. ...
... Mankin, A., Romanow, A., Bradner, S., and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998. ...
... Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550std64 ...