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 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]