NORM
Click on the red underlined text to get to the source
... NACK)-
oriented reliable multicast (NORM) protocols. While different
protocol instantiations may be required to meet specific application
and network architecture ...
... document discusses a large set of reliable multicast components and
issues relevant to NORM protocol design, it specifically addresses in
...
... FEC), congestion control)
and general issues with NORM protocols are also discussed. This
document is a product of the IETF RMT ...
... created to address areas outside of the scope of this
document. NORM protocol instantiations may depend upon these other
building blocks as well as the ones presented here. This document
focuses on areas that are unique to NORM ...
... NORM protocol instantiations may depend upon these other
building blocks as well as the ones presented here. This document
focuses on areas that are unique to NORM but may be used in concert
with the other building block areas. In some cases, a building block
may be able address ...
... can apply without NACK implosion problems. Research suggests that
NORM group sizes on the order of tens of thousands of receivers may
...
... The previous section has presented the role of protocol building
blocks and some of the criteria that may affect NORM building block
identification/design. This section describes different building
block areas applicable to NORM ...
... NORM building block
identification/design. This section describes different building
block areas applicable to NORM protocols. Some of these areas are
specific to NACK-oriented protocols. Detailed descriptions of such
...
... multicast.
Where applicable, other building block documents are referenced for
possible contribution to NORM protocols.
For each building block, a notional "interface ...
... document (e.g., congestion control or FEC). In other cases NORM
building block "inputs" must be satisfied by the specific protocol
...
... application data and control).
The following building block components relevant to NORM are
identified:
...
... identified:
(NORM-Specific)
1) NORM Sender Transmission
...
...
The components on the left side of this figure are areas that may be
applicable beyond NORM. The most significant of these components are
discussed in other building block documents such as [9]. A brief
...
... 9]. A brief
description of these areas and their role in the NORM protocol is
given below. The components on the right are seen as specific to
NORM ...
... NORM protocol is
given below. The components on the right are seen as specific to
NORM protocols, most notably the NACK repair process. These areas
are discussed in detail ...
... Router Assistance" may be more transparent to the core protocol
processing. The sections below describe the "NORM Sender
Transmission", "NORM ...
... NORM Sender
Transmission", "NORM Repair Process", and "RTT Collection" building
blocks in detail. The relationships to and among the other building
...
... RTT Collection" building
blocks in detail. The relationships to and among the other building
block areas are also discussed, focusing on issues applicable to NORM
protocol design. Where applicable, specific technical
...
... protocol design. Where applicable, specific technical
recommendations are made for mechanisms that will properly satisfy
the goals of NORM transport for the Internet.
...
... NORM Sender Transmission ...
...
NORM senders will transmit data content to the multicast session.
The data content will be application dependent. The sender ...
... congestion control mechanisms are needed (REQUIRED for
general Internet operation), NORM transmission SHALL be controlled by
the congestion control mechanism. In any case, it is RECOMMENDED
...
... the congestion control mechanism. In any case, it is RECOMMENDED
that all data transmissions from NORM senders be subject to rate
limitations determined by the application or congestion control
algorithm ...
... protocol operation. These messages may occur
outside of the scope of application data transfer. In NORM
protocols, reliability of such protocol messages ...
... receivers to respond with NACKs for any
outstanding repairs they require following the rules of the NORM NACK
procedure. For efficiency, the sender ...
... control messages
issued by a sender and other NORM protocol timeouts should be
dependent upon the group greatest round trip ...
... and any expected resultant NACK or other feedback operation. The
NORM GRTT is an estimate of the worst-case round-trip timing from a
...
... network topology with
respect to given sender. NORM instantiations SHOULD be able to
dynamically adapt to a wide range of multicast ...
... identifying data or repair content within the context of the
NORM session.
2) Commands indicating sender ...
... NORM Repair Process ...
...
A critical component of NORM protocols is the NACK repair process.
This includes the receiver ...
... sender's response to such requests. There are four
primary elements of the NORM repair process:
1) Receiver ...
... the start of reception of a subsequent coding block or transmission
object. This implies the NORM data content is marked to identify its
FEC block number and that ordinal relationship is preserved in order
...
...
An effective NORM feedback suppression mechanism is the use of random
backoff timeouts prior to NACK transmission by receivers ...
... needs. The specific information depends on the use and type of FEC
in the NORM repair process. The identification of repair needs is
dependent upon the data content identification (See Section 3.5
...
... segments) of data and FEC content. It should also
be noted that NORM can be effectively instantiated without a
requirement for reliable NACK ...
... Symbols
Fig. 2: NORM Data Content Identification Hierarchy
...
... 4) Have a reasonably compact format.
If the NORM transport object/stream is identified with an <objectId>
...
... NORM Receiver Join Policies and Procedures ...
...
In a NORM protocol (or other multicast protocols) where there is the
potential for multiple sources of data, it is necessary to provide
...
...
The data and repair content transmitted by a NORM sender requires
some form of identification in the protocol header fields. This
...
... stream
identifier that has been provided. Thus, in some cases, NORM
protocol instantiations may be able to receive transmissions and
request repair for multiple streams and one or more sets of static
...
... message format for identifying FEC
transmission content. NORM protocol instantiations using FEC SHOULD
follow that document's guidelines.
...
... In summary, the following data content identification fields may be
required for NORM protocol data content messages:
1) Source node identifier ...
... identifiers in requesting repair or retransmission of
data. NORM protocols that use these data content fields should also
be compatible with support for intermediate system assistance to
reliable multicast transport ...
... 11], [12], [13]. NORM protocols can reap additional
benefits since FEC-based repair does not _generally_ require explicit
...
... FEC-based repair does not _generally_ require explicit
knowledge of repair content within the bounds of its coding block
size (in symbols). In NORM, parity repair packets generated will
generally be transmitted only in response to NACK repair requests
...
... packet loss. While the application of
FEC is not unique to NORM, these sorts of requirements may dictate
the types of algorithms ...
...
A specific issue related to the use of FEC with NORM is the mechanism
used to identify the portion(s) of transmitted data content to which
specific FEC ...
... the GRTT among the receivers who are actively participating in NORM
operation. The set of receivers participating in this process may be
...
... congestion control purposes.
In summary, although NORM repair cycle timeouts are based on GRTT, it
should be noted that convergent operation of the protocol does not
...
... GRTT estimation. The current
mechanism has proved sufficient in simulations and in the
environments where NORM-like protocols have been deployed to date.
The estimate provided by the algorithm tracks the peak envelope of
...
... RTT_MIN and RTT_MAX respectively. NORM applications may wish to
place an additional, smaller upper limit on the GRTT advertised by
...
... GRTT times in the
range of 1 microsecond to 1000 seconds. Of course, NORM protocol
implementations may wish to further constrain advertised GRTT
...
... Multicast Congestion
Control (PGMCC) techniques [17] may be applied to NORM operation to
meet this requirement.
...
... receivers as it is relayed toward the
sender could enhance NORM group size scalability. For NORM protocols
...
... sender could enhance NORM group size scalability. For NORM protocols
using FEC, it is possible that intermediate systems may be able to
...
... NORM Applicability ...
...
The NORM building block applies to protocols wishing to employ
negative acknowledgement to achieve reliable data transfer ...
... multicast
(NORM) protocols offer scalability advantages for applications and/or
network topologies ...
... services or dynamic
networks and applications. NORM protocols can make use of reciprocal
(among senders and receivers ...
... sender(s).
NORM operation is compatible with transport layer forward error
correction coding techniques as described in [13 ...
... 17]. A
principal limitation of NORM operation involves group size
scalability when network capacity for receiver ...
... network capacity for receiver feedback is very
limited. NORM operation is also governed by implementation buffering
constraints ...
... IP and IP multicast protocols.
NORM is compatible with IP security (IPsec) authentication mechanisms ...
... protocols is that of NACK replay attacks that would prevent a NORM
sender from making forward progress in transmission. Any standard
IPsec mechanisms that can provide protection against ...
... IPsec mechanisms that can provide protection against such replay
attacks are RECOMMENDED for use. Additionally, NORM protocol
instantiations SHOULD consider providing support for their own NACK
...
... Multicast Security (msec) Working Group is also
developing solutions which may be applicable to NORM in the future.
...
... Macker, J. and R. Adamson, "Quantitative Prediction of Nack Oriented Reliable Multicast (NORM) Feedback", Proc. IEEE MILCOM 2002, October 2002. ...