Network Working Group David Meyer Internet Draft University of Oregon Sangeeta Mukherjee Sun Microsystems Kurt Windisch University of Oregon draft-meyer-pim-dm-prune-refresh-00.txt September 1997 Prune Refresh Extensions for PIM-DM 1. Status of this Memo This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 2. Abstract This document describes extensions to PIM-DM that limit the periodic traffic associated with the maintenance of prune state. The same mechanism also improves the robustness of the current PIM-DM Prune and Assert mechanisms. David Meyer, Sangeeta Mukherjee, Kurt Windisch [Page 1] Internet Draft draft-meyer-pim-dm-prune-refresh-00.txt September 1997 3. Protocol Overview This document is specific to PIM Dense-Mode [PIM-DM]. PIM-DM is a member of the family of multicast routing protocols (please see [WEI93] for a discussion of multicast tree distribution types and associated tradeoffs). The basic operational paradigm of these protocols is that when a source S sends data to a multicast group G, data is broadcast to the entire network using the shortest reverse path tree (SPT). The distribution tree is constructed using reverse- path forwarding (RPF), and is eventually pruned back to just those branches where there are receivers present [DEERING89]. The prune state will eventually time out, and the broadcast and prune cycle is repeated. This periodic broadcast and prune behavior can cause PIM-DM to unnecessarily use downstream resources on those branches where no receivers are present. 4. Problems with Current PIM-DM Join/Prune Mechanism There are several common scenarios in which the the PIM-DM Join/Prune mechanism can cause blackholes (failure to forward data) or forward data unnecessarily. These scenarios are outlined below. 4.1. Lost Join/Prune If a Prune is lost on a multi-access network, other downstream routers on the network not have an opportunity to override the prune. Similarly, a Join itself may be lost. In either case, downstream receivers can experience a blackout for time proportional to the upstream prune state timeout. This suggests that a router should be "alerted" that it is about to be pruned. 4.2. Router Doesn't Have Expected State A router in the middle of a pruned branch may not have the expected state (for example, if it is recovering from a crash). In this case, the router may not have sufficient information to be able to send a Graft message upstream in the event that it has downstream group members. A router should be "notified" that they are currently pruned by an upstream router. David Meyer, Sangeeta Mukherjee, Kurt Windisch [Page 2] Internet Draft draft-meyer-pim-dm-prune-refresh-00.txt September 1997 4.3. Broadcast and Prune Cycles Prune state in a downstream router times out periodically, creating potentially costly broadcast and prune cycles. These cycles can be prevented by keeping prune state alive ("keep alive") as long as there is data traffic flowing on the non-pruned part of the tree. 5. Prune Refresh Protocol Mechanism Alert, Notification, and Keep Alive can be accomplished with a new (S,G)-specific Prune Refresh message. (S,G)-Prune-Refresh messages are sent periodically by the router at the root of a branch that is pruned for (S,G). Prune Refresh messages are forwarded hop by hop down a pruned branch. A router at the root of a pruned branch originates Prune Refresh messages, while downstream routers forward Prune Refresh messages. 5.1. Originating vs. Forwarding Prune Refresh An outgoing interface may be in one of four (S,G) specific states: (1) originating Prune Refresh messages, (2) forwarding Prune Refresh messages, (3) forwarding data, or (4) no (S,G) state. This is illustrated by the state diagram below. /---------------\ | Data | | Forwarder | \---------------/ / ^ ^ ^ \ / / | \ \ / / | \ \ / / | \ \ v / | \ v /---------------\ | /---------------\ | Prune-Refresh | <-------- | Prune-Refresh | | Originator | --------> | Forwarder | \---------------/ | \---------------/ ^ | ^ \ | / \ | / \ | / \ | / David Meyer, Sangeeta Mukherjee, Kurt Windisch [Page 3] Internet Draft draft-meyer-pim-dm-prune-refresh-00.txt September 1997 /---------------\ | No (S,G) | | Entry | \---------------/ Figure 1: State diagram for interfaces in the Prune Refresh protocol. If an interface has been pruned, it will be either originating Prune Refresh messages, or forwarding Prune refresh messages. When originating Prune Refreshes, the interface-specific PIM-DM prune- timer will be set such that it never expires. When forwarding Prune Refreshes, the (S,G) specific, per-interface prune-timer will be set to the TUNR upon receipt of each Prune Refresh. This ensures that under normal operation, the prune state will be kept alive until the next refresh is sent. Transition from the originating to forwarding Prune Refresh states occurs when a prune is received on some interface that converts the (S,G) entry to negative cache state, triggering transmission of a prune upstream. The opposite transition (forwarding to originating) occurs when another interface receives a graft that converts the (S,G) entry from negative cache state to forwarding state, triggering transmission of a graft upstream. If the interface is forwarding data, it will not originate or forward Prune Refresh messages. The data forwarding state is entered from either prune state as in normal PIM-DM (either by receipt of a graft message or IGMP host report). If an interface which is in data forwarding state receives a Prune message, the interface with transition into one of two states: Either there are other interfaces in forwarding state for (S,G), in which case it will become either a Prune Refresh originator (the interface is at the root of a pruned branch), or it the prune causes negative cache for (S,G), in which case the interface goes into Prune Refresh forwarding state (the router is in the middle of a pruned branch). When a router with no (S,G) state receives an (S,G) Prune Refresh on it's RPF interface, it builds the corresponding state (i.e., the router is "notified" that it is on a pruned branch). If the Prune Refresh is received on the RPF interface, the router creates (S,G) negative cache state and goes into the Prune Refresh forwarding state. Otherwise, the router creates (S,G) state which has the interface on which the Prune Refresh was received pruned and all others in forwarding state. In this case, the pruned interface is in Prune Refresh originating state. David Meyer, Sangeeta Mukherjee, Kurt Windisch [Page 4] Internet Draft draft-meyer-pim-dm-prune-refresh-00.txt September 1997 5.2. Prune Scheduling When an interface is scheduled to be pruned, the router at the root of a pruned (S,G) branch sets a new per-interface (S,G) Prune Refresh Timer, PRT(S,G). The most recently used timer period, LastPRT(S,G) is always recorded when setting the timer for each interface. When PRT(S,G) expires, a Prune Refresh message is sent on the interface. The (S,G)-Prune-Refresh contains a timer value which tells downstream routers when to delete the (S,G) state in the event that no further (S,G)-Prune-Refresh messages or data are received. Finally, each time a (S,G)-Prune-Refresh message is sent, the PRT(S,G) timer is reset to min(2*LastPRT(S,G),MaxPRT). This provides O(log MaxPRT) opportunities for a downstream neighbor to cancel the prune. 5.3. Sending a Prune Refresh A router will originate a (S,G)-Prune-Refresh message when one of its interfaces is the root of a the branch that is pruned for (S,G). Downstream routers forward the Prune Refresh without modification; in particular, downstream routers must not modify the TUNR value. When a router initially receives a (S,G)-Prune on an outgoing interface for which it is the (S,G)-forwarder, it sets its Prune Refresh Timer, PRT(S,G), to half the Holdtime from the Prune message and records this time in LastPRT(S,G). When the (S,G) Prune Refresh timer expires, the router sets PRT(S,G) = min(2*LastPRT(S,G),MaxPRT) and updates LastPRT(S,G) with the new timeout period. It then sends a Prune Refresh message to the ALL-PIM-ROUTERS group on the interface associated with the PRT(S,G) timer. The packet has the following values (see Packet Formats below): Encoded-Unicast-Source Address = S Encoded-Group Address = G Encoded-Unicast-Forwarder Address = forwarder IP address TUNR = A router MUST NOT set TUNR to be less than the default (S,G) timer as described in [PIM-DM]. A router should continue to rate limit (S,G)-Prune-Refreshes on a interface until its (S,G) state is deleted, or the router receives an (S,G)-Graft or IGMP host report on the interface. David Meyer, Sangeeta Mukherjee, Kurt Windisch [Page 5] Internet Draft draft-meyer-pim-dm-prune-refresh-00.txt September 1997 5.4. Receiving a Prune Refresh There are three cases to consider when receiving a (S,G)-Prune- Refresh. These cases correspond to the possibilities for a downstream router's (S,G) state and the interface on which the Prune Refresh was received. 5.4.1. Router has no (S,G) state When a router receives an (S,G)-Prune-Refresh and it has no existing (S,G) state, it creates the (S,G) entry. This implements the "Notification" feature described above. The router must determine its RPF interface with a lookup for S in its unicast routing tables. If the Prune Refresh message was received on the RPF interface, it creates the (S,G) entry with negative cache state, sets its (S,G) entry and prune timers to the TUNR value in the Prune Refresh message, and forwards the Prune Refresh message on all other interfaces. If the router receives the Prune Refresh message on a non-RPF interface, it creates the (S,G) entry with the receiving interface pruned, and all other outgoing interfaces in data forwarding state. 5.4.2. Router receives (S,G)-Prune-Refresh on its RPF interface When a router receives an (S,G)-Prune-Refresh on its RPF interface and has existing (S,G) state, it is receiving notification that it had been part of a pruned branch of the multicast tree. If the router has any interfaces in data forwarding state for (S,G), indicating possible downstream receivers, it must follow the usual grafting procedure, sending rate-limited (S,G)-Grafts on the incoming interface until an (S,G)-Graft-Ack is received. Otherwise, if the router has negative cache state for (S,G), it sets its (S,G) entry and prune timers to the TUNR value from the Prune Refresh packet and forwards the Prune Refresh on those outgoing interfaces for which it is the (S,G) forwarder. This implements the Prune State "Keep Alive" functionality described above. 5.4.3. Router receives (S,G)-Prune-Refresh on an outgoing interface When a router receives an (S,G)-Prune-Refresh on an outgoing interface, and has existing (S,G) state, parallel paths from the sender may be creating a routing loop. In this case, the response depends on whether the Prune Refresh was received on a multi-access David Meyer, Sangeeta Mukherjee, Kurt Windisch [Page 6] Internet Draft draft-meyer-pim-dm-prune-refresh-00.txt September 1997 or point-to-point interface. If the Prune Refresh was received on an outgoing interface on a multi-access network for which the router is not the forwarder, it updates its PRT(S,G) with the TUNR from (S,G)-Prune-Refresh message. If it is the forwarder for the network, it must start the Assert process. If the Prune Refresh was received on an outgoing point-to-point interface, the receiving interface is pruned if it doesn't already have prune state. The prune timer is then updated with the TUNR value from the Prune Refresh message and the Prune Refresh is not forwarded on any interfaces. 5.5. Parallel Paths PIM-DM uses Prune messages both to remove downstream branches of the active multicast tree that do not require the data and to remove point-to-point links that would form cycles due to parallel paths. The latter presents a special problem for the Prune Refresh protocol, which must differentiate between the two Prune semantics and behave appropriately. A typical loop scenario is illustrated below. A ------ B | | | | | | C ------ D In the above illustration, A, B, C, and D are routers connected by point-to-point links and having other interfaces (not shown) connecting leaf networks and other routers. If multicast data originating from a sender connected to A arrives at C and D simultaneously, data will be sent over the link connecting C and D from both directions, triggering symmetric prunes. However, subsequent Prune Refreshes sent over this link constitute a special case; they must not be forwarded since the multicast tree may be active downstream of C and D via the other links constituting the normal shortest-path tree. Prune Refresh easily detects this case. If an (S,G)-Prune-Refresh arrives on an outgoing point-to-point interface, then the same (S,G) data packets have traversed the link from both directions, indicating David Meyer, Sangeeta Mukherjee, Kurt Windisch [Page 7] Internet Draft draft-meyer-pim-dm-prune-refresh-00.txt September 1997 parallel paths coalescing at this link. In this case, we simply update the prune timer for the outgoing interface that received the Prune Refresh. The Prune Refresh is not forwarded. 5.6. Maintaining Invariants In order to prevent some types of blackouts, broadcast and prune protocols must maintain the property that prune state closer to the source times out before prune state closer to the leaves. It can be easily seen that the Prune Refresh mechanism described in this document maintains this property: Since Prune Refresh messages are propagated hop by hop down a pruned branch without modification by intervening routers, we can be assured that the (S,G) timer in a router that is closer to the root of the pruned branch will be smaller than those further downstream. 5.7. Receiving Data Packets on an RPF Interface If a router receives (S,G) data packets on its RPF interface for S, it sets its (S,G) timer to the default value as specified in [PIM- DM]. Since this document specifies that a router must not set TUNR to a value less that the default (S,G) timer value, the invariant is maintained. 5.8. Unicast Routing Changes As is the case with PIM-SM [RFC2117], an RPF check is done on all active (S,G) entries whenever unicast routing changes, and all affected incoming interfaces are updated. If a new incoming interface appears in the outgoing interface list, it is deleted from the outgoing interface list. The previous incoming interface may be added to the outgoing interface list. If the (S,G) entry is a negative cache entry, PRT(S,G) for the new outgoing interface is set to the (S,G) timer for the entry, and Prune Refresh messages are sent (rate-limited) on the new outgoing interface. David Meyer, Sangeeta Mukherjee, Kurt Windisch [Page 8] Internet Draft draft-meyer-pim-dm-prune-refresh-00.txt September 1997 6. Packet Formats This section describes the extensions to the PIM packet formats to support Prune Refresh. Refer to the PIM sparse-mode specification [RFC2117] for complete packet format details. This document specifies a new PIM Type, Prune-Refresh (type 9): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Addr length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PIM Ver PIM Version number is 2. Type Types for specific PIM messages. PIM Types are: 0 = Hello 1 = Register 2 = Register-Stop 3 = Join/Prune 4 = Bootstrap 5 = Assert 6 = Graft 7 = Graft-Ack 8 = Candidate-RP-Advertisement 9 = Prune-Refresh 6.1. Prune-Refresh Message Packet Format A Prune Refresh message is sent by the forwarder on a multi-access network to the ALL-PIM-ROUTERS group. The type of the packet is set to Prune-Refresh (9). Addresses are encoded as specified in [RFC2117]. The Encoded-Unicast Source Address is the address of the multicast group sender (S). The Encoded-Group Address is the group G David Meyer, Sangeeta Mukherjee, Kurt Windisch [Page 9] Internet Draft draft-meyer-pim-dm-prune-refresh-00.txt September 1997 which for which the prune is being refreshed. The Encoded-Unicast- Forwarder Address is the IP address of the (S,G) forwarder for the multi-access network. Finally, TUNR is the time until next the (S,G)-Prune-Refresh will be sent. The packet format is shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Group Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-Forwarder Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TUNR | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7. Additional Prune Refresh Overhead Requirements The method described here requires minimum additional overhead. In particular, it requires an additional message type (Prune-Refresh) and one additional timer (PRT(S,G)). There also two additional states in the PIM-DM state machine: Receiving Refresh and Sending Refresh. 8. Changes to Assert Processing Since Prune Refresh messages are sent only by the forwarder for the multi-access network, they can be used to periodically convey forwarder identity information to downstream routers. This property can be used to prevent "upstream switching", in which downstream router may switch its upstream router from its RPF neighbor to the Assert winner on a multi-access network. A downstream router can avoid periodic switching of its upstream neighbor by simply resetting its Assert timer on receipt of a Prune Refresh message. PIM-DM Assert messages can also be group-aggregated, since forwarder election is done based on the best path to a source. That is, the group does not influence the selection of the forwarder for a multi- access network. The following section specifies a simplified packet format for group aggregation of Assert messages. David Meyer, Sangeeta Mukherjee, Kurt Windisch [Page 10] Internet Draft draft-meyer-pim-dm-prune-refresh-00.txt September 1997 8.1. Assert Message Packet Format The main change in the Assert message is that the Encoded-Group Address [RFC2117] is removed from the PIM-DM Assert message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric Preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PIM Version PIM Version number is 2. PIM Type PIM Assert is type 5. Checksum The checksum is the 16-bit one's complement of the one's complement sum of the entire PIM message [RFC2117]. When computing the checksum, the checksum field is zeroed. Encoded-Unicast-Source Address Source address from multicast datagram that triggered the Assert packet to be sent. Metric Preference Preference value assigned to the unicast routing protocol that provided the route to Host address. Metric The unicast routing table metric. The metric is in units applicable to the unicast routing protocol used. David Meyer, Sangeeta Mukherjee, Kurt Windisch [Page 11] Internet Draft draft-meyer-pim-dm-prune-refresh-00.txt September 1997 8.2. Resetting the S-Assert-timer A router will reset its S-Assert-timer when it receives an (S,G)- Prune-Refresh on its RPF interface for S, since the prune refresh will have been sent by the forwarder for the multi-access network. 9. Conclusions The simple mechanism described in this document satisfies the objectives states above. In particular, it implements Prune State "Keep Alive" Prune "Alert" Prune "Notification" without adding significant overhead to the basic PIM-DM mechanism. In addition, this document specifies Group Assert aggregation for PIM Dense Mode. 10. Security Considerations Historically, routing protocols used within the Internet have lacked strong authentication mechanisms [RFC1704]. In the late 1980s, analysis revealed that there were a number of security problems in Internet routing protocols then in use [BELLOVIN89]. During the early 1990s it became clear that adversaries were selectively attacking various intra-domain and inter-domain routing protocols (e.g. via TCP session stealing of BGP sessions) [CERTCA9501, RFC1636]. More recently, cryptographic authentication mechanisms have been developed for RIPv2, OSPF, and the proprietary EIGRP routing protocols. BGP protection, in the form of a Keyed MD5 option for TCP, has also become widely deployed. At present, most multicast routing protocols lack strong cryptographic protection. One possible approach to this is to incorporate a strong cryptographic protection mechanism (e.g. Keyed HMAC MD5 [RFC2104]) within the routing protocol itself. Alternately, the routing protocol could be designed and specified to use the IP Authentication Header (AH) [RFC1825, RFC1826, RFC2085] to provide cryptographic authentication. Because the intent of any routing protocol is to propagate routing information to other parties, confidentiality is not generally required in routing protocols. In those few cases where local security policy might require confidentiality, the use of the IP David Meyer, Sangeeta Mukherjee, Kurt Windisch [Page 12] Internet Draft draft-meyer-pim-dm-prune-refresh-00.txt September 1997 Encapsulating Security Payload (ESP) [RFC1825, RFC1827] is recommended. Scalable dynamic multicast key management is an active research area at this time. Candidate technologies for scalable dynamic multicast key management include CBT-based key management [RFC1949] and the Group Key Management Protocol (GKMP) [GKMPID]. The IETF IP Security Working Group is actively working on GKMP extensions to the standards-track ISAKMP key management protocol being developed in the same working group. 11. References [BELLOVIN89] S. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Volume 19, Number 2, pp. 32-48, April 1989. [CERTCA9501] CERT, "IP Spoofing Attacks and Hijacked Terminal Connections", ftp://ftp.cert.org/cert_advisories/, January 1995. [DEERING89] Steve Deering, "Scalable Multicast Routing Protocol", Ph.D. Thesis, Stanford University, 1989. [GKMPID] H. Harney, "Group Key Management Protocol (GKMP)", draft-harney-gkmp-arch-01.txt && draft-harney-gkmp-spec-01.txt, August 1996, Informational RFC publication is pending. [PIM-DM] Deering, Steve, et. al., "Protocol Independent Multicast Dense Mode (PIM-DM): Protocol Specification", draft-ietf-idmr-PIM-DM-spec-06, August, 1997. [RFC1636] Braden, R., Clark, D., Crocker, S., and C. Huitema, "Report of IAB Workshop on Security in the Internet Architecture", RFC1636, June 1994. [RFC1704] N. Haller and R. Atkinson, "On Internet Authentication", RFC1704, October 1994. [RFC1825] Atkinson, R., "IP Security Architecture", August 1995. [RFC1826] Atkinson, R., "IP Authentication Header", August 1995. [RFC1827] Atkinson, R., "IP Encapsulating Security Payload", David Meyer, Sangeeta Mukherjee, Kurt Windisch [Page 13] Internet Draft draft-meyer-pim-dm-prune-refresh-00.txt September 1997 August 1995. [RFC1949] A. Ballardie, "Scalable Multicast Key Distribution", RFC1949, June 1996. [RFC2085] M. Oehler & R. Glenn, "HMAC-MD5 IP Authentication with Replay Prevention", February 1997. [RFC2104] H. Krawczyk, M. Bellare, & R. Canetti, "HMAC: Keyed Hashing for Message Authentication", RFC2104, February 1997. [RFC2117] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", June 1997 [WEI93] Liming Wei and Deborah Estrin, "A Comparison of Multicast Trees and Algorithms", USC Technical Report 93-560. 12. Acknowledgments The ideas contained in this document were first proposed by Steve Deering. Dino Farinacci also provided insightful comments on earlier versions of this document. 13. Author Information David Meyer, Sangeeta Mukherjee, Kurt Windisch [Page 14] Internet Draft draft-meyer-pim-dm-prune-refresh-00.txt September 1997 David Meyer University of Oregon 1225 Kincaid St. Eugene, OR 97403 Phone: (541) 346-1747 e-mail: meyer@antc.uoregon.edu Sangeeta Mukherjee Sun Microsystems, Inc e-mail: Sangeeta.Mukherjee@Eng.Sun.COM Kurt Windisch University of Oregon 1225 Kincaid St. Eugene, OR 97403 Phone: (541) 346-1698 e-mail: kurtw@antc.uoregon.edu Internet Draft draft-meyer-pim-dm-prune-refresh-00.txt September 1997 David Meyer, Sangeeta Mukherjee, Kurt Windisch [Page 15]