Internet-Draft K. Calvert, J. Griffioen
University of Kentucky
Expires May 2001 November 2000
Internet Concast Service
draft-calvert-concast-svc-02.txt
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.
The distribution of this memo is unlimited. It is filed as <draft-
calvert-concast-svc-02.txt> and expires January 24, 2002. Please
send comments to the authors.
Abstract
Concast is a many-to-one best-effort network service that allows a
receiver to treat a group of senders as a single entity, in much the
same way that IP multicast allows a sender to treat a group of
receivers as one. Each concast datagram delivered to a receiver is
derived from (possibly many) datagrams sent by different members of
the concast group to that receiver; the relationship between the
delivered datagram and the sent datagrams is defined by a "merge
specification". Concast provides a framework that allows the
semantics of this merging operation to vary to suit the needs of
different applications. Concast is incrementally deployable and
backward compatible with IPv4 and IPv6. It can be implemented
entirely in end systems, but offers the most benefits in terms of
scalability when it is supported by routers in the network. This
Calvert et al [Page 1]
INTERNET-DRAFT Internet Concast Service November 2000
document describes the concast service and its framework for defining
merge semantics, including safety properties required of the merge
framework implementation.
1. Introduction
Multicast has been an Internet service for many years now [1]. Its
semantics are simple: when a host sends a packet to a multicast
address, the network makes its best effort to deliver a copy to all
hosts in the group. The network keeps track of receiving hosts'
locations, and duplicates datagrams as needed while forwarding them
toward all receivers. The power of multicast is in its abstraction
mechanism, which enables a sender to treat an arbitrary number of
receivers as a single entity.
Concast is intended to provide a similar abstraction in the reverse
direction: it enables a receiver to treat an arbitrary number of
senders as a single entity. When multiple senders transmit concast
datagrams to the same receiver, the network makes its best effort to
"merge" them into a single message for delivery to that receiver.
The utility of such a service depends on the semantics of the merging
operation performed by the network layer. It seems unlikely that any
single (necessarily application-independent) semantics would have
sufficiently broad applicability to justify implementation of the
concast service. Therefore concast is designed to allow for a broad
range of merge semantics, all fitting within a certain framework.
The following examples illustrate a range of possible merge
semantics:
o Inverse multicast/duplicate suppression: at most one copy of
any datagram is delivered to the receiver within a particular
window of time.
o Voting: each datagram contains a value chosen by its sender.
When some threshold number of datagrams has been sent, a single
datagram containing the value that occurred most often in the
sent datagrams is delivered.
o Applying an associative and commutative operator: each datagram
contains a value. The maximum (minimum, sum, product,
conjunction, disjunction, bitwise conjunction, bitwise
disjunction) of the values in all sent datagrams is placed in the
datagram delivered to the receiver.
It is envisioned that certain simple merge functions like these will
Calvert et al [Page 2]
INTERNET-DRAFT Internet Concast Service November 2000
be "hardwired" into the network. The merge framework defined later
allows for new merge semantics to be specified simply by defining
certain functions that make up the framework. For maximum
flexibility, authorized receivers would supply such definitions using
an encoding interpreted by all concast-capable nodes. The nature of
this encoding determines the power of the computations permitted for
merge specifications.
Concast can be used alone, for example to collect and distill
telemetry from a group of remote sensors. It is also especially
useful in conjunction with multicast. Many multicast applications
require some form of feedback from the receiver set. For such
applications, implosion at the multicast source or at internal
network nodes is a real problem as group sizes grow large, because
(in the absence of concast) the only way to convey feedback is via
unicast datagrams. This fundamentally breaks the multicast
abstraction by forcing the sender to deal with individuals instead of
the group as a whole. Moreover, in most cases, the feedback
recipient is not interested in the individuals' information, but
rather some function -- for example the maximum or minimum -- of the
group's information. Support for the concast abstraction allows such
"summary information" to be provided in a scalable way, by computing
it at strategic points along the way.
Support for concast requires modifications to those hosts and routers
that support it. It does not, however, require any modification to
other parts of the infrastructure, nor does it require additional
routing or forwarding capabilities beyond those required for unicast.
In particular, concast does not depend on multicast in any way.
Concast service can be provided on an end-system-only basis, though
router support is necessary for scalability (in terms of the group
size supportable without implosion). Partial deployment among
routers is beneficial, and indeed most of the scalability and
implosion-prevention benefits are likely to be attainable by
deployment of concast at select routers at domain boundaries. This
document describes extensions to Version 4 of the Internet Protocol.
Similar extensions can be defined for IPv6.
The next section provides an overview of the service and its use.
Section 3 defines the semantic framework for merging datagrams, and
gives an example of its use. Section 4 describes the processing of
concast datagrams by the IP implementations of concast-capable
nodes, in terms of the semantic framework. Security considerations
are discussed in Section 5.
2. Service Overview
Calvert et al [Page 3]
INTERNET-DRAFT Internet Concast Service November 2000
The unit of concast service is the "flow". Concast flows are
unidirectional: data travels only from the senders to the (single)
receiver. Each concast flow is identified by a pair (R,G), where R
is the (unicast) IP address of the receiver and G is a concast group
identifier. Concast group IDs are 32 bit numbers chosen by the
receiver. Note that different receiving applications on the same
host need to use different group IDs so their flows can be
distinguished.
Each concast flow has an associated Merge Specification, which is
chosen by the receiver and specified at flow creation time. The
Merge Specification defines the relationship between datagrams
delivered to the receiver application and those transmitted by the
senders.
Thus to use concast, receiver and senders must agree (through some
out-of-band means) on two things: the concast group ID and the Merge
Specification. Senders must transmit datagrams containing
information in the format expected by the Merge Specification.
A concast-capable node N maintains state information for each concast
flow (R,G) passing through it (i.e., for which N is on the path to R
from some sender participating in the flow). Responsibility for
establishment and maintainance of this per-flow information belongs
to the Concast Signaling Protocol (CSP), which is described in a
separate document [1]. CSP uses soft-state techniques to ensure that
the concast service is robust in the face of route changes. The per-
flow information includes the identities of all concast-capable nodes
"upstream" of N on the flow, and state relevant to the ongoing merge
processing of messages sent on the flow.
In contrast to multicast -- as multicast is currently specified and
implemented in the Internet [2] -- both senders and receiver are
required to signal the network before using the concast service.
(Multicast only requires receivers to signal.) A benefit of this
"uniform" signaling requirement is that it provides an opportunity
for authentication and authorization checks on users of the service.
This is likely to be important since router support for concast
requires the maintenance of per-flow state.
2.1 Concast Datagram Format
Concast datagrams are distinguished from ordinary IP datagrams by the
presence of a "Concast ID" option in the IP header, which contains
the concast group number. Concast-oblivious routers do not recognize
the concast ID option, and simply forward concast datagrams as if
they were regular unicast datagrams.
Calvert et al [Page 4]
INTERNET-DRAFT Internet Concast Service November 2000
Concast-capable routers MUST check every forwarded datagram for the
presence of the Concast ID option. One means of achieving this is to
check for this particular option. However, other protocols (e.g.
RSVP) also require processing at non-destination nodes, and various
methods of diverting datagrams from the forwarding path for special
processing are available, including the Router Alert option [4] and
the Waypoint mechanism [5].
The source address field of a concast datagram's IP header contains
the IP address of the last concast-capable node to process the
datagram. This enables a node processing an incoming datagram to
check that the datagram was forwarded by one of that node's known
upstream neighbors. (This check is of course not secure. See Section
5.)
The concast service does not specify any other headers of its own.
Instead, each individual merge specification defines the information
it expects to be carried in packets.
2.2 Concast Flow Lifecycle
The normal sequence of events for establishing and using a concast
flow is as follows:
1. The receiver creates the flow by supplying its local IP concast
module with the concast group ID G, the preferred receiver address
R, and the Merge Specification (described below).
2. Nodes wishing to join the group and participate as senders do so
by supplying (R,G) to their local IP concast module. This invokes
the signaling protocol, which causes flow state (including the
Merge Specification) to be established along the paths from the
senders to the receiver.
3. Senders transmit packets as usual. Each sender's IP concast
implementation ensures that each sent concast datagram carries a
concast group ID option with value G.
4. As concast datagrams travel hop-by-hop toward the receiver, at
each concast-capable node (including at least the receiving host)
they are diverted for concast processing. This involves retrieving
the state for the (R,G) flow and carrying out the computation
defined by the merge specification for that flow. Packets are
forwarded (toward $R$) after processing only under the conditions
defined by the merge specification.
5. When the receiving application receives data from the flow via
Calvert et al [Page 5]
INTERNET-DRAFT Internet Concast Service November 2000
its network API, concast messages appear to have been sent by the
concast group; they contain the result of merging the messages sent
by group members.
6. Senders may leave the concast group at any time. When a sender
leaves the group, the signaling protocol is invoked to inform the
sender's downstream neighbor that one of its upstream neighbors is
going away. When a node has no remaining upstream neighbors, it
recursively informs its downstream neighbor that it is leaving the
flow. In this way, the concast "tree" grows and shrinks as senders
join and leave the group.
7. The receiving application may tear down the flow at any time.
The signaling protocol then notifies all upstream neighbors that
the flow has gone away. Those nodes inform their neighbors, and so
on, until all state for the flow has been removed from the system.
The Concast Signaling Protocol, including the soft-state techniques
that are used to detect route changes and connectivity problems, is
defined elsewhere [1].
3. Merge Semantics
The nature of the merge function determines the utility of the
concast service for any particular application; different
applications in general need different semantics. On the other hand,
the processing burden placed on the intermediate nodes by the merge
computation, along with the potential for misbehaior by the merge
function, must be limited. We therefore constrain the general form
of the merge computation by defining certain steps to be common to
all merge functions, and by defining the "shape" of the variable
parts.
The merge semantics tells which datagrams within a flow are to be
merged together, and defines the computation that takes as input the
(possibly many) messages sent, and produces as output the message
ultimately delivered to the receiver.
In the context of a particular concast flow, a Datagram Equivalence
Class (DEC) is defined as a set of concast datagrams to be merged
together. A flow may have datagrams belonging to multiple DECs in
the network at the same time. For example, in the inverse multicast
(duplicate suppression) service mentioned in the first section, two
packets could be in the same DEC if they have the destination IP
address, concast group ID, and IP payload.
Calvert et al [Page 6]
INTERNET-DRAFT Internet Concast Service November 2000
Because packets are processed one at a time as they arrive, each
concast node maintains a "merge state block" (MSB) for each active
DEC of a flow. To limit the amount of per-flow state, the size and
number of active MSBs will in general be limited by the concast
implementation. When a merge computation is ``finished'', a concast
datagram is constructed using information in the MSB, and forwarded
toward the destination R.
Based on the foregoing, we can outline the steps in "merge"
processing, given the merge specification for flow (R,G):
1. Determine the datagram equivalence class to which the datagram
belongs, according to the merge specification.
2. Retrieve the Merge State Block for that DEC.
3. Update the contents of the MSB using the old contents and the
datagram according to the merge specification.
4. If the computation is finished according to the merge
specification, construct and forward an IP datagram with
destination address equal to R, source address equal to the IP
address of the interface that leads toward R (or the concast group
ID if this node is R), the concast group ID option with value G,
and payload constructed from the MSB according to the merge
specification.
3.1 Variable Components of the Merge Specification
The semantics of merge are defined by giving definitions for certain
types and methods. In defining those methods, the following types
are considered to be given:
The type DECTag, of tags that identify Datagram Equivalence
Classes.
A Merge Specification consists of precise definitions of the
following types and functions:
The type MergeStateBlock, which defines the state information to be
stored for in-progress merges, including information that will be
carried in any forwarded datagram. The maximum size of a
MergeStateBlock must be fixed at the time of the definition. Every
MergeStateBlock contains a one-byte field used for computing TTL
values of forwarded datagrams, as described below. The definition
of the MergeStateBlock type MUST include initial values for all
fields.
Calvert et al [Page 7]
INTERNET-DRAFT Internet Concast Service November 2000
The function getTag(), which takes a concast datagram as input and
returns a DECTag. This function determines the Datagram
Equivalence Class to which a given packet belongs. Typically this
function will extract a value from a particular location or
locations in the datagram (header and/or payload). Alternatively,
it might compute a digest of the datagram's payload.
The function merge(), which takes a MergeStateBlock, a concast
datagram, and per-flow information and returns an updated
MergeStateBlock. This function does the real work of merging,
combining information from an incoming datagram with information
derived from previously processed datagrams.
The predicate done() on MergeStateBlocks, which returns "true" when
a datagram needs to be constructed and forwarded to R.
The function buildDatagram(), which takes a MergeStateBlock and
returns a datagram containing a valid IP header, transport header,
and payload.
The method of specification of the above functions is beyond the
scope of this memo. Note that some merge specifications are expected
to be well-known and commonly supported, so that receivers can invoke
them by name.
3.2 Generic Portion of the Merge Specification
The fixed component of the merge semantics defines that portion of
the merge computation that is the same on every node, for every flow.
It is specified by the pseudocode below.
ProcessDatagram(IPAddr R, ConcastGroupID G, IPDatagram m)
// Generic concast merge processing
{
FlowStateBlock fsb; // flow state for flow (R,G)
DECTag t; // tag for m's DEC
MergeStateBlock s;
fsb = LOOKUP_FLOW(R,G); // get relevant flow state
if (fsb != NULL) {
t = fsb.getTag(m); // get the DEC
s = GET_MERGE_STATE(fsb,t); // get state of in-progress merge
s = UPDATE_TTL(s,m); // fixed function
s = fsb.merge(s,m,fsb); // merge computation
if (fsb.done(s)) { // time to send something on?
(s,m) = fsb.buildDatagram(s);
FORWARD_DG(fsb,s,m); // on toward R
}
Calvert et al [Page 8]
INTERNET-DRAFT Internet Concast Service November 2000
PUT_MERGE_STATE(fsb,s,t); // replace old state
}
The data type "FlowStateBlock" encapsulates flow-specific information
that might be useful to the merge computation, for example the list
of upstream neighbors of the current node in the concast tree.
Methods whose names are given in CAPITALS are built-in, fixed parts
of the merging framework; their semantics cannot be modified by the
user.
The method LOOKUP_FLOW takes a flow specifier and returns the flow
state block belonging to that flow, if any. If no such flow state
block exists, the datagram is silently dropped.
The method GET_MERGE_STATE takes a tag identifying a Datagram
Equivalence Class, and a flow state block, and returns a
MergeStateBlock associated with the given tag in the flow. In order
to bound the amount of per-flow state kept at a node, a limit
(MAX_ACTIVE_DECS) is placed on the number of distinct tag values that
may have MergeStateBlocks bound to them at any instant. However,
GET_MERGE_STATE always returns a valid MergeStateBlock instance.
These two facts imply that when the limit on extant MSBs is reached,
calls to saveMergeState with a new DECTag value will result in some
(tag, MSB) pair being evicted from the state store. It is the
application's responsibility to ensure that the limit on extant
MergeStateBlocks is not violated, by limiting the rate at which
concast datagrams arrive at intermediate routers. The value of
MAX_ACTIVE_DECS should be globally defined and published, so that
applications can limit their sending rate accordingly. If the
MergeStateBlock returned by GET_MERGE_STATE is a new instance, it has
been initialized according to the specification.
The method UPDATE_TTL replaces the Time-to-live value stored in the
MergeStateBlock with the minimum of that value and the TTL value
from the IP header of the given datagram, and returns the modified
MergeStateBlock.
The method "FORWARD_DG" takes an IP datagram and does the following
to the IP header:
1. Overwrites the IP destination address with the given destination
R.
2. Writes the IP address of the outgoing interface (toward R) into
the
IP source address.
Calvert et al [Page 9]
INTERNET-DRAFT Internet Concast Service November 2000
3. Writes the Time-to-live value from the given MergeStateBlock,
minus one, into the TTL field.
4. Adds a Concast Group ID option containing the group ID G, and
adjusts the header and datagram length fields accordingly.
5. Resets the TOS bits to 0.
6. Recomputes the IP header checksum.
Note that any higher-level headers above IP are entirely the
responsibility of the merge spec-defined functions. In particular,
UDP and TCP checksums are not recomputed by the FORWARD_DG procedure;
thus if UDP or TCP is used, the buildDatagram function must compute
them properly, using R and the outgoing interface's address in the IP
pseudo-header that is included in the checksum computation. Thus the
IP address of the outgoing interface toward R MUST be available to
the buildDatagram function.
The PUT_MERGE_STATE method associates the given MergeStateBlock with
the given DECTag value in the given flow, replacing the old
MergeStateBlock value. (The foregoing discussion of GET_MERGE_STATE
implies that an old value exists for the given tag.)
3.3 Example Merge Function
To illustrate the use of the Merge Specification framework, we
present a definition of the "inverse multicast" (duplicate
suppression) service mentioned in the Introduction. To implement
this service, the network must "remember" each datagram that is
delivered to the receiver, and suppress subsequent copies without
forwarding them. For the purposes of this service, two datagrams
belonging to the same flow are considered "identical" if they have
the same payload. In other words, datagrams with the same payload
belong to the same DEC.
In principle, the only state needed for a DEC is that fact that a
datagram in that DEC has already been forwarded by a node. However,
because of the way the generic part of the computation is structured,
on the first arrival of a datagram from a DEC, the merge state must
record the fact that no merge state was found for that DEC
originally. Therefore we define:
typedef MergeStateBlock {
boolean forwarded;
IPPayload pendingDG;
}
Calvert et al [Page 10]
INTERNET-DRAFT Internet Concast Service November 2000
The DECTag value is computed by taking the MD5 hash [3] of the
payload of the given datagram:
DECTag getTag(IPDatagram m)
{
return (DECTag) MD5hash(m.payload);
}
The merge() function simply records the datagram for forwarding.
MergeStateBlock merge(MergeStateBlock s, IPDatagram m, FSB f)
{
if (s==NULL) {
create a new MergeStateBlock newState;
newState.forwarded := false;
newState.pendingDG := m;
return newState;
} else
return s;
}
The done() function simply checks whether the packet has already been
forwarded:
boolean done(MergeStateBlock s)
{
return NOT(s.forwarded);
}
The buildDatagram() function updates the state to indicate that the
datagram has been forwarded, and returns the updated state along with
the protocol number and payload of the datagram:
(MergeStateBlock,ProtocolNumber,IPPayload)
buildDatagram(MergeStateBlock s)
{
s.forwarded := true;
return (s,s.pendingDG);
}
3.4 Discussion
The definition of particular merge functions using code like that of
Section 3.3 does not imply that the actual processing should be
accomplished in software. For the example above, the computation can
be very efficiently implemented in hardware, and it is expected that
routers supporting this merge function would do so.
However, for flexibility it may also be useful to support user-
supplied merge functions coded in some restricted-but-high-level
language, for example a limited subset of Java. Obviously some
constructs (e.g. recursion, dynamic storage allocation, unbounded
iteration) should be restricted or prohibited in such code. On the
other hand, certain functionality may be needed by such code.
Calvert et al [Page 11]
INTERNET-DRAFT Internet Concast Service November 2000
For example, in some cases it is useful to initiate merge processing
via the passage of time, rather than datagram arrival. This
capability can be provided by providing a method by which user-
supplied code can arrange for the last portion of the merge
processing (beginning with the done() test) to be executed a
specified amount of time in the future. To limit overhead, each flow
is permitted at most one pending timeout-callback per MSB at any
time.
3.5 Fragmentation
The notion of a datagram equivalence class is well-defined only for
complete (unfragemented) IP datagrams. Therefore it is necessary for
applications using concast to send datagrams that will not be
fragmented in the network. This can be achieved either by performing
path MTU discovery for the path between each sender and the receiver,
or by sending datagrams smaller than the minimum IP datagram size.
4. Levels of Support
A node participating in a concast flow as a sender or receiver MUST
implement some part of the the Concast Signaling Protocol (CSP) [1].
The parts of CSP that must be implemented depend on the level of
concast support provided by the node. Some nodes may only be able to
originate concast datagrams and thus do not need to implement the
receiving or merging components of the CSP protocol. Other nodes may
only be able to receive concast messages. Some nodes will support
both sending and receiving. Internal network nodes need only to
support the merge processing described earlier. Legacy nodes that do
not support concast at all, simply need to forward concast packets as
if they were unicast.
4.1 Sending Host Processing
In order for a host to participate as a sender in a concast group, it
needs to support the portion of the CSP protocol that signals the
node's intent to join (or leave) as a sender. Once CSP has
established the necessary state information to link the sender into
the concast flow, the sender can begin transmitting concast
datagrams. Specifically, senders must mark outgoing packets as
concast packets requiring hop-by-hop processing. This is achieved
simply by inserting a "Concast ID" option in the IP header containing
the concast group G from which this packet originated. The packet is
then routed and transmitted using the standard IP mechanism.
4.2 Receiving Host Processing
Calvert et al [Page 12]
INTERNET-DRAFT Internet Concast Service November 2000
Applications join the group G as a receiver by identifying (via a
system call) the concast flow to be joined (R,G) and providing the
Merge Specification for the flow. Concast receivers must support the
parts of the CSP protocol that respond to requests for Merge
Specifications and Join requests. Once the CSP protocol establishes
the flow and distributes the Merge Specification, concast datagrams
will begin arriving at the receiver. The receiver's IP module must
recognize the "Concast ID" option and divert the incoming packet for
merge processing as specified in Section 3. Following merge
processing, the FORWARD_DG function passes any resulting datagram to
the local IP module, which recognizes the destination address as its
own demultiplexes it as usual to the higher-level protocol indicated
in the IP header.
4.3 Per-flow State Considerations
Because sender-only nodes simply mark outgoing packets as concast
packets, the state information maintained at such nodes will be
minimal. However, because merge state accumulates at internal
concast-capable nodes and at concast receivers, state size could
potentially grow without bound. Consequently the fsb.saveMergeState
function should limit the amount of state information any particular
flow can consume. The language used to construct the Merge
Specification may also impose limits on the amount of state
information that can be saved. Assuming the merge state is bounded,
the state needed to maintain information about flows is similar to
the state used by shortest-path multicast routing protocols.
5 Security Considerations
Security considerations for concast fall into two main categories.
First and foremost, concast implementations must ensure the stability
of individual nodes as well as the network as a whole. For example,
concast should not enable new classes of denial of service, or other
forms of attack. Second, the protocol should be designed so that
access to the concast service can be controlled by network (or
provider) policy.
5.1 Node Safety
Implementations of the concast merge framework must ensure the safety
of individual nodes. Nodes that accept user-supplied Merge
Specifications SHOULD take steps to ensure that the
interpretation/execution of such specifications is safe, in
particular consumes acceptable amounts of compute bandwidth and
storage and does not modify the router state in unacceptable ways.
One possible approach is to require that the Merge Specification be
Calvert et al [Page 13]
INTERNET-DRAFT Internet Concast Service November 2000
supplied in an encoding that allows a priori verification of desired
safety properties. Another is to impose limits on per-message
processing and storage at run time. The limits of "acceptable
amounts of compute bandwidth and storage" will depend on the capacity
available at each node; presumably concast-capable nodes will be
equipped with sufficient processing and storage capacity to enable
them to handle some amount of concast processing without harm to
their other required functions.
Note that the signaling requirements of concast provide a means for
nodes to limit the amount of processing for which they are obligated.
Nodes that are fully booked can simply refuse requests to establish
new flows.
If the risk of executing user-supplied Merge Specifications is
considered to be excessive, the service can still be supported, but
with only built-in (i.e. user-selectable but not user-customizable)
merge functions.
5.2 Network Safety
The construction and emission of datagrams at routers under user
control -- however limited -- should always be handled with care.
As an example, in some earlier descriptions of this service, concast
datagrams were identified by the presence of a group address (e.g. a
Class E or multicast address) in the Source field of the IP header.
While this approach is nicely symmetric with multicast in that no
individual address is associated with the source of the datagram, it
conflicts with anti-spoofing source checks applied in some parts of
the current Internet. Unfortunately, modification of such checks to
allow packets with concast source addresses to pass opens up the
possibility of untraceable denial-of-service attacks on concast-
capable hosts that reside in domains with no concast-capable routers,
and therefore the method of marking concast datagrams was changed.
The concast merge framework MUST be implemented in such a way that
the "construction and emission" process for concast has certain
properties:
o Fixed Destination: The only destination to which datagrams
can be forwarded as a result of concast processing is R, the
flow's receiver.
o Conservation of packets: At most one datagram is
emitted per incoming concast datagram processed.
o TTL Monotonicity: For each flow passing through a node, the TTL
Calvert et al [Page 14]
INTERNET-DRAFT Internet Concast Service November 2000
values of the datagrams belonging to that flow decrease as they
are processed. That is, the TTL value in each emitted datagram
is smaller than the TTL values of all the packets that were
merged to form that datagram.
These properties can be ensured by judicious implementation of the
fixed part of the merge framework, and by restricting the operations
permitted by the variable part. For example, if user-supplied merge
functions are permitted to set timeouts, the merge framework MUST
ensure that at most one timeout per MergeStateBlock can be pending.
In order to guarantee the "Conservation of packets" property,
invocation of the FORWARD_DG function for a MergeStateBlock should
cancel any timeout pending for that MergeStateBlock.
5.3 Controlling Access to Concast Services
In the absence of strong authentication applied to each packet at
each concast-capable node, packets can be inserted into a concast
flow by nodes that have not joined the flow. This may corrupt the
information delivered to the receiver. However, the same threat
exists when unicast is used to deliver the information.
It is straightforward to add an authentication check to the generic
merge processing of Section 3.2. Moreover, the signaling phase
provides an opportunity for establishment of the necessary security
associations between neighbors in the concast tree (indeed this is
one motivation for requiring signaling by all parties). However, the
security provided is necessarily hop-by-hop.
[Discussion of extension of concast tree to be added.]
6 Acknowledgements
The contributions of Billy Mullins, Leon Poutievsky, Amit Sehgal,
and Su Wen to this service specification are acknowledged with
thanks.
The support of the Defense Advanced Research Projects Agency (DARPA)
and Air Force Research Laboratory, Air Force Materiel Command, USAF,
under agreement number F30602-99-1-0514, is gratefully acknowledged.
The views and conclusions contained herein are those of the authors
and should not be interpreted as necessarily representing the
official policies or endorsements, either expressed or implied, of
the Defense Advanced Research Projects Agency (DARPA), the Air Force
Calvert et al [Page 15]
INTERNET-DRAFT Internet Concast Service November 2000
Research Laboratory, or the U.S. Government.
References
[1] Calvert, K. L. and Griffioen, J. N., "Concast Signaling
Protocol", Internet-Draft, in preparation.
[2] Deering, S., "Host Requirements for IP Multicasting", RFC 1112,
August 1989.
[3] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[4] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[5] Lindell, B. and Braden, B., "Waypoint - A Path Oriented Delivery
Mechanism for IP based Control, Measurement, and Signaling
Protocols", Internet Draft (work in progress), November 2000,
draft-lindell-waypoint-00.txt.
Authors' Address:
Kenneth L. Calvert (calvert@netlab.uky.edu)
James N. Griffioen (griff@netlab.uky.edu)
Lab for Advanced Networking
University of Kentucky
Hardymon Building, 2nd Floor
301 Rose Street
Lexington, KY 40506-0495
Calvert et al [Page 16]