< draft-thaler-multicast-interop-02.txt   draft-thaler-multicast-interop-03.txt >
Inter-Domain Multicast Routing (IDMR) D. Thaler Inter-Domain Multicast Routing (IDMR) D. Thaler
Internet Engineering Task Force Microsoft Internet Engineering Task Force Microsoft
INTERNET-DRAFT 13 March 1998 INTERNET-DRAFT 31 July 1998
draft-thaler-multicast-interop-02.txt Expires: September, 1998 draft-thaler-multicast-interop-03.txt Expires: January, 1999
Interoperability Rules for Multicast Routing Protocols Interoperability Rules for Multicast Routing Protocols
<draft-thaler-multicast-interop-02.txt> <draft-thaler-multicast-interop-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the To view the entire list of current Internet-Drafts, please check
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow the "1id-abstracts.txt" listing contained in the Internet-Drafts
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
ftp.isi.edu (US West Coast). (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
Abstract Abstract
The rules described in this document will allow efficient interoperation The rules described in this document will allow efficient interoperation
among multiple independent multicast routing domains. Specific among multiple independent multicast routing domains. Specific
instantiations of these rules are given for the DVMRP, MOSPF, PIM-DM, instantiations of these rules are given for the DVMRP, MOSPF, PIM-DM,
and PIM-SM multicast routing protocols, as well as for IGMP-only links. PIM-SM, and CBT multicast routing protocols, as well as for IGMP-only
links. Future versions of these protocols, and any other multicast
routing protocols, may describe their interoperability procedure by
stating how the rules described herein apply to them.
Introduction Copyright Notice Copyright (C) The Internet Society (1998). All Rights
Reserved.
1. Introduction
To allow sources and receivers inside multiple autonomous multicast To allow sources and receivers inside multiple autonomous multicast
routing domains (or "regions") to communicate, the domains must be routing domains (or "regions") to communicate, the domains must be
connected by multicast border routers (MBRs). To prevent black holes or connected by multicast border routers (MBRs). To prevent black holes or
routing loops among domains, we assume that these domains are organized routing loops among domains, we assume that these domains are organized
into one of the following topologies: into one of the following topologies:
o A tree (or star) topology (figure 1) with a backbone domain at the o A tree (or star) topology (figure 1) with a backbone domain at the
root, stub domains at the leaves, and possibly "transit" domains as root, stub domains at the leaves, and possibly "transit" domains as
branches between the root and the leaves. Each pair of adjacent branches between the root and the leaves. Each pair of adjacent
skipping to change at line 82 skipping to change at page 2, line 52
Figure 1: Tree Topology of Domains Figure 1: Tree Topology of Domains
o An arbitrary topology, in which a higher level (inter-domain) o An arbitrary topology, in which a higher level (inter-domain)
routing protocol, such as HDVMRP [1] or BGMP [9], is used to routing protocol, such as HDVMRP [1] or BGMP [9], is used to
calculate paths among domains. Each pair of adjacent domains is calculate paths among domains. Each pair of adjacent domains is
connected by one or more MBRs. connected by one or more MBRs.
Section 2 describes rules allowing interoperability between existing Section 2 describes rules allowing interoperability between existing
multicast routing protocols [2,3,4,5,6], and reduces the multicast routing protocols [2,3,4,5,6], and reduces the
interoperability problem from O(N^2) potential protocol interactions, to interoperability problem from O(N^2) potential protocol interactions, to
just N (1 per protocol) instantiations of the same set of invariant just N (1 per protocol) instantiations of the same set of invariant
rules. This document specifically applies to Multicast Border Routers rules. This document specifically applies to Multicast Border Routers
(MBRs) which meet the following assumptions: (MBRs) which meet the following assumptions:
o The MBR consists of two or more active multicast routing o The MBR consists of two or more active multicast routing
components, each running an instance of some multicast routing components, each running an instance of some multicast routing
protocol. No assumption is made about the type of multicast protocol. No assumption is made about the type of multicast
routing protocol (e.g., broadcast-and-prune vs. explicit-join) any routing protocol (e.g., broadcast-and-prune vs. explicit-join) any
component runs, or the nature of a "component". Multiple component runs, or the nature of a "component". Multiple
components running the same protocol are allowed. components running the same protocol are allowed.
o The router is configured to forward packets between two or more o The router is configured to forward packets between two or more
independent domains. The router has one or more active interfaces independent domains. The router has one or more active interfaces
in each domain, and one component per domain. The router also has in each domain, and one component per domain. The router also has
exactly one inter-domain component, which we cover in Section 3. an inter-component "alert dispatcher", which we cover in Section 3.
o Only one multicast routing protocol is active per interface (we do o Only one multicast routing protocol is active per interface (we do
not consider mixed multicast protocol LANs). Each interface on not consider mixed multicast protocol LANs). Each interface on
which multicast is enabled is thus "owned" by exactly one of the which multicast is enabled is thus "owned" by exactly one of the
components. components.
o All components share a common forwarding cache of (S,G) entries, o All components share a common forwarding cache of (S,G) entries,
which are created when data packets are received, and can be which are created when data packets are received, and can be
deleted at any time. Only the component owning an interface may deleted at any time. Only the component owning an interface may
change information about that interface in the forwarding cache. change information about that interface in the forwarding cache.
skipping to change at line 141 skipping to change at page 4, line 13
itself. itself.
We describe all interactions between components in terms of "alerts". We describe all interactions between components in terms of "alerts".
The nature of an alert is implementation-dependent (e.g., it may consist The nature of an alert is implementation-dependent (e.g., it may consist
of a simple function call, writing to shared memory, use of IPC, or some of a simple function call, writing to shared memory, use of IPC, or some
other method) but alerts of some form exist in every model. Similarly, other method) but alerts of some form exist in every model. Similarly,
the originator of an alert is also implementation-dependent; for the originator of an alert is also implementation-dependent; for
example, alerts may be originated by a component effecting a change, by example, alerts may be originated by a component effecting a change, by
an independent arbiter, or by the kernel. an independent arbiter, or by the kernel.
1.1. Specification Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
2. Requirements 2. Requirements
To insure that a MBR fitting the above assumptions exhibits correct To insure that a MBR fitting the above assumptions exhibits correct
interdomain routing behavior, each MBR component MUST adhere to the interdomain routing behavior, each MBR component MUST adhere to the
following rules: following rules:
Rule 1: All components must agree on which component owns the incoming Rule 1: All components must agree on which component owns the incoming
interface (iif) for a forwarding cache entry. This component, interface (iif) for a forwarding cache entry. This component,
which we call the "iif owner" is determined by the inter-domain which we call the "iif owner" is determined by the dispatcher
component (see Section 3). The incoming component may select (see Section 3). The incoming component may select ANY
ANY interface it owns as the iif according to its own rules. interface it owns as the iif according to its own rules.
When a routing change occurs which causes the iif to change to an When a routing change occurs which causes the iif to change to an
interface owned by a different component, both the component previously interface owned by a different component, both the component previously
owning the entry's iif and the component afterwards owning the entry's owning the entry's iif and the component afterwards owning the entry's
iif MUST notice the change (so the first can prune upstream and the iif MUST notice the change (so the first can prune upstream and the
second can join/graft upstream, for example). Typically, noticing such second can join/graft upstream, for example). Typically, noticing such
changes will happen as a result of normal protocol behavior. changes will happen as a result of normal protocol behavior.
Rule 2: The component owning an interface specifies the criteria for Rule 2: The component owning an interface specifies the criteria for
which packets received on that interface are to be accepted or which packets received on that interface are to be accepted or
dropped (e.g., whether to perform an RPF check, and what scoped dropped (e.g., whether to perform an RPF check, and what scoped
boundaries exist on that interface). Once a packet is accepted, boundaries exist on that interface). Once a packet is accepted,
however, it is processed according to the forwarding rules of however, it is processed according to the forwarding rules of
all components. all components.
Furthermore, some multicast routing protocols (e.g. PIM) also require
the ability to react to packets received on the "wrong" interface. To
support these protocols, an MBR must allow a component to place any of
its interfaces in "WrongIf Alert Mode". If a packet arrives on such an
interface, and is not accepted according to Rule 2, then the component
owning the interface MUST be alerted [(S,G) WrongIf alert]. Typically,
WrongIf alerts must be rate-limited.
Rule 3: Whenever a new (S,G) forwarding cache entry is to be created Rule 3: Whenever a new (S,G) forwarding cache entry is to be created
(e.g., upon accepting a packet destined to a non-local group), (e.g., upon accepting a packet destined to a non-local group), all
all components MUST be alerted [(S,G) Creation alert] so that components MUST be alerted [(S,G) Creation alert] so that they can set
they can set the forwarding state on their own outgoing the forwarding state on their own outgoing interfaces (oifs) before the
interfaces (oifs) before the packet is forwarded. packet is forwarded.
Note that (S,G) Creation alerts are not necessarily generated by one of Note that (S,G) Creation alerts are not necessarily generated by one of
the protocol components themselves. the protocol components themselves.
Rule 4: When a component removes the last oif from an (S,G) forwarding Rule 4: When a component removes the last oif from an (S,G) forwarding
cache entry whose iif is owned by another component, or when cache entry whose iif is owned by another component, or when
such an (S,G) forwarding cache entry is created with an empty such an (S,G) forwarding cache entry is created with an empty
oif list, the component owning the iif MUST be alerted [(S,G) oif list, the component owning the iif MUST be alerted [(S,G)
Prune alert] (so it can send a prune, for example). Prune alert] (so it can send a prune, for example).
Rule 5: When the first oif is added to an (S,G) forwarding cache entry Rule 5: When the first oif is added to an (S,G) forwarding cache entry
whose iif is owned by another component, the component owning whose iif is owned by another component, the component owning
the iif MUST be alerted [(S,G) Join alert] (so it can send a the iif MUST be alerted [(S,G) Join alert] (so it can send a
join or graft, for example). join or graft, for example).
skipping to change at line 252 skipping to change at page 6, line 39
Although this may be done in any implementation-dependent method, one Although this may be done in any implementation-dependent method, one
example would be to maintain a common table (which we call the example would be to maintain a common table (which we call the
Component-Group Table) indexed by group-prefix, listing which components Component-Group Table) indexed by group-prefix, listing which components
are interested in each group(prefix). Thus, any components which are are interested in each group(prefix). Thus, any components which are
wildcard receivers for externally-reached sources (i.e., those whose RPF wildcard receivers for externally-reached sources (i.e., those whose RPF
interface is owned by another component) would be listed in all entries interface is owned by another component) would be listed in all entries
of this table, including a default entry. This table is thus loosely of this table, including a default entry. This table is thus loosely
analogous to a forwarding cache of (*,G) entries, except that no analogous to a forwarding cache of (*,G) entries, except that no
distinction is made between incoming and outgoing interfaces. distinction is made between incoming and outgoing interfaces.
3. Inter-Domain Components 3. Alert Dispatchers
We assume that each MBR has one inter-domain component. Any such We assume that each MBR has an "alert dispatcher". The dispatcher is
component is responsible for selecting, for each (S,G) entry in the responsible for selecting, for each (S,G) entry in the shared forwarding
shared forwarding cache, the component owning the iif. It is also cache, the component owning the iif. It is also responsible for
responsible for selecting to which component(s) a given alert should be selecting to which component(s) a given alert should be sent.
sent.
3.1. The "Interop" Component 3.1. The "Interop" Dispatcher
We describe here rules that may be used in the absence of any inter- We describe here rules that may be used in the absence of any inter-
domain multicast routing protocol, to enable interoperability in a tree domain multicast routing protocol, to enable interoperability in a tree
topology of domains. If an inter-domain multicast routing protocol is topology of domains. If an inter-domain multicast routing protocol is
in use, its component should be used instead of the Interop component in use, another dispatcher should be used instead. The Interop
described here. The Interop component does not own any interfaces. dispatcher does not own any interfaces.
To select the iif of an (S,G) entry, the iif owner is the component To select the iif of an (S,G) entry, the iif owner is the component
owning the next-hop interface towards S in the multicast RIB. owning the next-hop interface towards S in the multicast RIB.
The "iif owner" of (*,G) and (*,*) entries is the Interop component. The "iif owner" of (*,G) and (*,*) entries is the Interop dispatcher
This allows the Interop component to receive relevant alerts without itself. This allows the Interop dispatcher to receive relevant alerts
without owning any interfaces.
owning any interfaces.
3.1.1. Processing Alerts 3.1.1. Processing Alerts
If the Interop component receives an (S,G) Creation alert, it adds no If the Interop dispatcher receives an (S,G) Creation alert, it adds no
interfaces to the entry's oif list, since it owns none. interfaces to the entry's oif list, since it owns none.
When the Interop component receives a (*,G) Prune alert, the following When the Interop dispatcher receives a (*,G) Prune alert, the following
actions are taken, depending on the number of components N which want to actions are taken, depending on the number of components N which want to
receive data for G. If N has just changed from 2 to 1, a (*,G) Prune receive data for G. If N has just changed from 2 to 1, a (*,G) Prune
alert is sent to the remaining component. If N has just changed from 1 alert is sent to the remaining component. If N has just changed from 1
to 0, a (*,G) Prune alert is sent to ALL intra-domain components other to 0, a (*,G) Prune alert is sent to ALL components other than the 1.
than the 1.
When the Interop component receives a (*,G) Join alert, the following When the Interop dispatcher receives a (*,G) Join alert, the following
actions are taken, depending on the number of components N which want to actions are taken, depending on the number of components N which want to
receive data for G. If N has just changed from 0 to 1, a (*,G) Join receive data for G. If N has just changed from 0 to 1, a (*,G) Join
alert is sent to ALL intra-domain components other than the 1. If N has alert is sent to ALL components other than the 1. If N has just changed
just changed from 1 to 2, a (*,G) Join alert is sent to the original (1) from 1 to 2, a (*,G) Join alert is sent to the original (1) component.
component.
3.2. BGMP 3.2. "BGMP" Dispatcher
This dispatcher can be used with an inter-domain multicast routing
protocol (such as BGMP) which allows global (S,G) and (*,G) trees.
The iif owner of an (S,G) entry is the component owning the next-hop The iif owner of an (S,G) entry is the component owning the next-hop
interface towards S in the multicast RIB. interface towards S in the multicast RIB.
The iif owner of a (*,G) entry is the component owning the next-hop The iif owner of a (*,G) entry is the component owning the next-hop
interface towards G in the multicast RIB. interface towards G in the multicast RIB.
4. Intra-Domain Components 3.2.1. Processing Alerts
This dispatcher simply forwards all (S,G) and (*,G) alerts to the iif
owner of the associated entry.
4. Multicast Routing Protocol Components
In this section, we describe how the rules in section 2 apply to current
versions of various protocols. Future versions, and additional
protocols, should describe how these rules apply in a separate document.
4.1. DVMRP 4.1. DVMRP
In this section we describe how the rules in section 2 apply to DVMRP. In this section we describe how the rules in section 2 apply to DVMRP.
We assume that the reader is familiar with normal DVMRP behavior as We assume that the reader is familiar with normal DVMRP behavior as
specified in [2]. specified in [2].
As with all broadcast-and-prune protocols, DVMRP components are As with all broadcast-and-prune protocols, DVMRP components are
automatically wildcard receivers for internally-reached sources. Unless automatically wildcard receivers for internally-reached sources. Unless
some form of Domain-Wide-Reports (DWRs) [10] (synonymous with Regional- some form of Domain-Wide-Reports (DWRs) [10] (synonymous with Regional-
skipping to change at line 329 skipping to change at page 8, line 29
some form of DWRs. some form of DWRs.
One simple heuristic to approximate DWRs is to assume that if there are One simple heuristic to approximate DWRs is to assume that if there are
any internally-reached members, then at least one of them is a sender. any internally-reached members, then at least one of them is a sender.
With this heuristic, the presense of any (S,G) state for internally- With this heuristic, the presense of any (S,G) state for internally-
reached sources can be used instead. Sending a data packet to a group reached sources can be used instead. Sending a data packet to a group
is then equivalent to sending a DWR for the group. is then equivalent to sending a DWR for the group.
4.1.1. Generating Alerts 4.1.1. Generating Alerts
A (*,*) Join alert is sent to the iif owner of the (*,*) entry (e.g.,
the Interop dispatcher) when the first component becomes a wildcard
receiver for external sources. This may occur when a DVMRP component
starts up which does not support some form of DWRs.
A (*,*) Prune alert is sent to the iif owner of the (*,*) entry (e.g.,
the Interop dispatcher) when all components are no longer wildcard
receivers for external sources. This may occur when a DVMRP component
which does not support some form of DWRs shuts down.
An (S,G) Prune alert is sent to the component owning the iif for a An (S,G) Prune alert is sent to the component owning the iif for a
forwarding cache entry whenever the last oif is removed from the entry, forwarding cache entry whenever the last oif is removed from the entry,
and the iif is owned by another component. In DVMRP, this may happen and the iif is owned by another component. In DVMRP, this may happen
when: when:
o A DVMRP (S,G) Prune message is received on the logical interface. o A DVMRP (S,G) Prune message is received on the logical interface.
An (S,G) Join alert is sent to the component owning the iif for a An (S,G) Join alert is sent to the component owning the iif for a
forwarding cache entry whenever the first logical oif is added to an forwarding cache entry whenever the first logical oif is added to an
entry, and the iif is owned by another component. In DVMRP, this may entry, and the iif is owned by another component. In DVMRP, this may
happen when any of the following occur: happen when any of the following occur:
o The oif's prune timer expires, or o The oif's prune timer expires, or
o A DVMRP (S,G) Graft message is received on the logical interface, o A DVMRP (S,G) Graft message is received on the logical interface,
or or
o IGMP [7] notifies DVMRP that directly-connected members of G now o IGMP [7] notifies DVMRP that directly-connected members of G now
exist on the interface. exist on the interface.
When it is known, for a group G, that there are no longer any members in When it is known, for a group G, that there are no longer any members in
the DVMRP domain which receive data for externally-reached sources from the DVMRP domain which receive data for externally-reached sources from
the local router, a (*,G) Prune alert is sent to the "iif owner" for the local router, a (*,G) Prune alert is sent to the "iif owner" for
(*,G) according to the Inter-domain component. In DVMRP, this may (*,G) according to the dispatcher. In DVMRP, this may happen when:
happen when: o The DWR for G times out, or
o The DWR for G times out.
o The members-are-senders approximation is being used and the last o The members-are-senders approximation is being used and the last
(S,G) entry for G is timed out. (S,G) entry for G is timed out.
When it is first known that there are members of a group G in the DVMRP When it is first known that there are members of a group G in the DVMRP
domain, a (*,G) Join alert is sent to the "iif owner" of (*,G). In domain, a (*,G) Join alert is sent to the "iif owner" of (*,G). In
DVMRP, this may happen when either of the following occurs: DVMRP, this may happen when either of the following occurs:
o A DWR is received for G. o A DWR is received for G, or
o The members-are-senders approximation is being used and a data o The members-are-senders approximation is being used and a data
packet for G is received on one of the component's interfaces. packet for G is received on one of the component's interfaces.
4.1.2. Processing Alerts 4.1.2. Processing Alerts
When a DVMRP component receives an (S,G) Creation alert, it adds all the When a DVMRP component receives an (S,G) Creation alert, it adds all the
component's interfaces to the entry's oif list (according to normal component's interfaces to the entry's oif list (according to normal
DVMRP behavior) EXCEPT: DVMRP behavior) EXCEPT:
o the iif, o the iif,
o interfaces without local members of the entry's group, and for o interfaces without local members of the entry's group, and for
skipping to change at line 415 skipping to change at page 10, line 27
An MOSPF component acts as a wildcard receiver for internally-reached An MOSPF component acts as a wildcard receiver for internally-reached
sources if and only if any other component is a wildcard receiver for sources if and only if any other component is a wildcard receiver for
externally-reached sources. An MOSPF component acts as a wildcard externally-reached sources. An MOSPF component acts as a wildcard
receiver for externally-reached sources only if internally-reached receiver for externally-reached sources only if internally-reached
domains exist which do not support some form of Domain-Wide-Reports domains exist which do not support some form of Domain-Wide-Reports
(DWRs) [10]. Since MOSPF floods membership information throughout the (DWRs) [10]. Since MOSPF floods membership information throughout the
domain, MOSPF itself is considered to support a form of DWRs natively. domain, MOSPF itself is considered to support a form of DWRs natively.
4.2.1. Generating Alerts 4.2.1. Generating Alerts
A (*,*) Join alert is sent to the iif owner of the (*,*) entry (e.g.,
the Interop dispatcher) when the first component becomes a wildcard
receiver for external sources. This may occur when an MOSPF component
starts up and decides to act in this role.
A (*,*) Prune alert is sent to the iif owner of the (*,*) entry (e.g.,
the Interop dispatcher) when all components are no longer wildcard
receivers for external sources. This may occur when an MOSPF component
which was acting in this role shuts down.
When it is known that there are no longer any members of a group G in When it is known that there are no longer any members of a group G in
the MOSPF domain, a (*,G) Prune alert is sent to the "iif owner" for the MOSPF domain, a (*,G) Prune alert is sent to the "iif owner" for
(*,G) according to the Inter-domain component. In MOSPF, this may (*,G) according to the dispatcher. In MOSPF, this may happen when
happen when either: either:
o IGMP notifies MOSPF that there are no longer any directly-connected o IGMP notifies MOSPF that there are no longer any directly-connected
group members on an interface, or group members on an interface, or
o Any router's group-membership-LSA for G is aged out. o Any router's group-membership-LSA for G is aged out.
When it is first known that there are members of a group G in the MOSPF When it is first known that there are members of a group G in the MOSPF
domain, a (*,G) Join alert is sent to the "iif owner" of (*,G), domain, a (*,G) Join alert is sent to the "iif owner" of (*,G),
according to the Inter-domain component. In MOSPF, this may happen when according to the dispatcher. In MOSPF, this may happen when any of the
any of the following occur: following occur:
o IGMP notifies MOSPF that directly-connected group members now exist o IGMP notifies MOSPF that directly-connected group members now exist
on the interface, or on the interface, or
o A group-membership-LSA is received for G. o A group-membership-LSA is received for G.
4.2.2. Processing Alerts 4.2.2. Processing Alerts
When an MOSPF component receives an (S,G) Creation alert, it calculates When an MOSPF component receives an (S,G) Creation alert, it calculates
the shortest path tree for the MOSPF domain, and adds the downstream the shortest path tree for the MOSPF domain, and adds the downstream
interfaces to the entry's oif list according to normal MOSPF behavior. interfaces to the entry's oif list according to normal MOSPF behavior.
skipping to change at line 480 skipping to change at page 12, line 7
some form of DWRs. some form of DWRs.
One simple heuristic to approximate DWRs is to assume that if there are One simple heuristic to approximate DWRs is to assume that if there are
any internally-reached members, then at least one of them is a sender. any internally-reached members, then at least one of them is a sender.
With this heuristic, the presense of any (S,G) state for internally- With this heuristic, the presense of any (S,G) state for internally-
reached sources can be used instead. Sending a data packet to a group reached sources can be used instead. Sending a data packet to a group
is then equivalent to sending a DWR for the group. is then equivalent to sending a DWR for the group.
4.3.1. Generating Alerts 4.3.1. Generating Alerts
A (*,*) Join alert is sent to the iif owner of the (*,*) entry (e.g.,
the Interop dispatcher) when the first component becomes a wildcard
receiver for external sources. This may occur when a PIM-DM component
starts up which does not support some form of DWRs.
A (*,*) Prune alert is sent to the iif owner of the (*,*) entry (e.g.,
the Interop dispatcher) when all components are no longer wildcard
receivers for external sources. This may occur when a PIM-DM component
which does not support some form of DWRs shuts down.
A (S,G) Prune alert is sent to the component owning the iif for a A (S,G) Prune alert is sent to the component owning the iif for a
forwarding cache entry whenever the last oif is removed from the forwarding cache entry whenever the last oif is removed from the
forwarding cache entry, and the iif is owned by another component. In forwarding cache entry, and the iif is owned by another component. In
PIM-DM, this may happen when: PIM-DM, this may happen when:
o A PIM (S,G) Join/Prune message with S in the prune list is received o A PIM (S,G) Join/Prune message with S in the prune list is received
on a point-to-point interface. on a point-to-point interface.
o The Oif-Timer in an (S,G) route table entry expires. o The Oif-Timer in an (S,G) route table entry expires.
o A PIM (S,G) Assert message from a preferred neighbor is received on o A PIM (S,G) Assert message from a preferred neighbor is received on
the interface. the interface.
skipping to change at line 502 skipping to change at page 12, line 39
the iif is owned by another component. In PIM-DM, this may happen when the iif is owned by another component. In PIM-DM, this may happen when
any of the following occur: any of the following occur:
o The oif's prune timer expires, or o The oif's prune timer expires, or
o A PIM-DM (S,G) Graft message is received on the interface, or o A PIM-DM (S,G) Graft message is received on the interface, or
o IGMP notifies PIM-DM that directly-connected group members now o IGMP notifies PIM-DM that directly-connected group members now
exist on the interface. exist on the interface.
When it is known that there are no longer any members of a group G in When it is known that there are no longer any members of a group G in
the PIM-DM domain which receive data for externally-reached sources from the PIM-DM domain which receive data for externally-reached sources from
the local router, a (*,G) Prune alert is sent to the "iif owner" for the local router, a (*,G) Prune alert is sent to the "iif owner" for
(*,G) according to the Inter-domain component. In PIM-DM, this may (*,G) according to the dispatcher. In PIM-DM, this may happen when:
happen when:
o The DWR for G times out. o The DWR for G times out.
o The members-are-senders approximation is being used and PIM-DM's o The members-are-senders approximation is being used and PIM-DM's
last (S,G) entry for G is timed out. last (S,G) entry for G is timed out.
When it is first known that there are members of a group G in the PIM-DM When it is first known that there are members of a group G in the PIM-DM
domain, a (*,G) Join alert is sent to the "iif owner" of (*,G), domain, a (*,G) Join alert is sent to the "iif owner" of (*,G),
according to the Inter-domain component. In PIM-DM, this may happen according to the dispatcher. In PIM-DM, this may happen when either of
when either of the following occurs: the following occurs:
o A DWR is received for G. o A DWR is received for G.
o The members-are-senders approximation is being used and a data o The members-are-senders approximation is being used and a data
packet for G is received on one of the component's interfaces. packet for G is received on one of the component's interfaces.
4.3.2. Processing Alerts 4.3.2. Processing Alerts
When a PIM-DM component receives an (S,G) Creation alert, it adds the When a PIM-DM component receives an (S,G) Creation alert, it adds the
component's interfaces to the entry's oif list (according to normal component's interfaces to the entry's oif list (according to normal
PIM-DM behavior) EXCEPT: PIM-DM behavior) EXCEPT:
o the iif, o the iif,
o leaf networks without local members of the entry's group, o leaf networks without local members of the entry's group,
o and interfaces with scoped boundaries covering the group. o and interfaces with scoped boundaries covering the group.
When a PIM-DM component receives an (S,G) Prune alert, and the When a PIM-DM component receives an (S,G) Prune alert, and the
forwarding cache entry's oiflist is empty, it sends a PIM-DM (S,G) Prune forwarding cache entry's oiflist is empty, it sends a PIM-DM (S,G) Prune
message to the upstream neighbor according to normal PIM-DM behavior. message to the upstream neighbor according to normal PIM-DM behavior.
skipping to change at line 584 skipping to change at page 14, line 22
via an interface owned by another component, the iif should always point via an interface owned by another component, the iif should always point
towards S and not towards the RP for G. In addition, the Border-bit is towards S and not towards the RP for G. In addition, the Border-bit is
set in all PIM Register messages for this entry. set in all PIM Register messages for this entry.
Finally, the PIM-SM component acts as a DR for externally-reached Finally, the PIM-SM component acts as a DR for externally-reached
receivers in terms of being able to switch to the shortest-path tree for receivers in terms of being able to switch to the shortest-path tree for
internally-reached sources. internally-reached sources.
4.4.1. Generating Alerts 4.4.1. Generating Alerts
A (*,*) Join alert is sent to the iif owner of the (*,*) entry (e.g.,
the Interop dispatcher) when the first component becomes a wildcard
receiver for external sources. This may occur when a PIM-SM component
starts up and decides to act in this role.
A (*,*) Prune alert is sent to the iif owner of the (*,*) entry (e.g.,
the Interop dispatcher) when all components are no longer wildcard
receivers for external sources. This may occur when a PIM-SM component
which was acting in this role shuts down.
A (S,G) Prune alert is sent to the component owning the iif for a A (S,G) Prune alert is sent to the component owning the iif for a
forwarding cache entry whenever the last oif is removed from the entry forwarding cache entry whenever the last oif is removed from the entry
and the iif is owned by another component. In PIM-SM, this may happen and the iif is owned by another component. In PIM-SM, this may happen
when: when:
o A PIM (S,G) Join/Prune message with S in the prune list is received o A PIM (S,G) Join/Prune message with S in the prune list is received
on a point-to-point interface, or on a point-to-point interface, or
o A PIM (S,G) Assert from a preferred neighbor was received on the o A PIM (S,G) Assert from a preferred neighbor was received on the
interface, or interface, or
o A PIM Register-Stop message is received for (S,G), or o A PIM Register-Stop message is received for (S,G), or
o The interface's Oif-Timer for PIM's (S,G) route table entry o The interface's Oif-Timer for PIM's (S,G) route table entry
skipping to change at line 598 skipping to change at page 14, line 46
o A PIM (S,G) Join/Prune message with S in the prune list is received o A PIM (S,G) Join/Prune message with S in the prune list is received
on a point-to-point interface, or on a point-to-point interface, or
o A PIM (S,G) Assert from a preferred neighbor was received on the o A PIM (S,G) Assert from a preferred neighbor was received on the
interface, or interface, or
o A PIM Register-Stop message is received for (S,G), or o A PIM Register-Stop message is received for (S,G), or
o The interface's Oif-Timer for PIM's (S,G) route table entry o The interface's Oif-Timer for PIM's (S,G) route table entry
expires. expires.
o The Entry-Timer for PIM's (S,G) route table entry expires. o The Entry-Timer for PIM's (S,G) route table entry expires.
When it is known that there are no longer any members of a group G in When it is known that there are no longer any members of a group G in
the PIM-SM domain which receive data for externally-reached sources from the PIM-SM domain which receive data for externally-reached sources from
the local router, a (*,G) Prune alert is sent to the "iif owner" for the local router, a (*,G) Prune alert is sent to the "iif owner" for
(*,G) according to the Inter-domain component. In PIM-SM, this may (*,G) according to the dispatcher. In PIM-SM, this may happen when:
happen when:
o A PIM (*,G) Join/Prune message with G in the prune list is received o A PIM (*,G) Join/Prune message with G in the prune list is received
on a point-to-point interface, or on a point-to-point interface, or
o A PIM (*,G) Assert from a preferred neighbor was received on the o A PIM (*,G) Assert from a preferred neighbor was received on the
interface, or interface, or
o IGMP notifies PIM-SM that directly-connected members no longer o IGMP notifies PIM-SM that directly-connected members no longer
exist on the interface. exist on the interface.
o The Entry-Timer for PIM's (*,G) route table entry expires. o The Entry-Timer for PIM's (*,G) route table entry expires.
A (S,G) Join alert is sent to the component owning the iif for a A (S,G) Join alert is sent to the component owning the iif for a
forwarding cache entry whenever the first logical oif is added to an forwarding cache entry whenever the first logical oif is added to an
entry and the iif is owned by another component. In PIM-SM, this may entry and the iif is owned by another component. In PIM-SM, this may
happen when any of the following occur: happen when any of the following occur:
o A PIM (S,G) Join/Prune message is received on the interface, or o A PIM (S,G) Join/Prune message is received on the interface, or
o The Register-Suppression-Timer for (S,G) expires, or o The Register-Suppression-Timer for (S,G) expires, or
o The Entry-Timer for an (S,G) negative-cache state route table entry o The Entry-Timer for an (S,G) negative-cache state route table entry
expires. expires.
When it is first known that there are members of a group G in the PIM-SM When it is first known that there are members of a group G in the PIM-SM
domain, a (*,G) Join alert is sent to the "iif owner" of (*,G), domain, a (*,G) Join alert is sent to the "iif owner" of (*,G),
according to the Inter-domain component. In PIM-SM, this may happen according to the dispatcher. In PIM-SM, this may happen when any of the
when any of the following occur: following occur:
o A PIM (*,G) Join/Prune message is received on the interface, or o A PIM (*,G) Join/Prune message is received on the interface, or
o A PIM (*,*,RP) Join/Prune message is received on the interface, or o A PIM (*,*,RP) Join/Prune message is received on the interface, or
o (*,G) negative cache state expires, or o (*,G) negative cache state expires, or
o IGMP notifies PIM that directly-connected group members now exist o IGMP notifies PIM that directly-connected group members now exist
on the interface. on the interface.
4.4.2. Processing Alerts 4.4.2. Processing Alerts
When a PIM-SM component receives an (S,G) Creation alert, it does a When a PIM-SM component receives an (S,G) Creation alert, it does a
longest match search ((S,G), then (*,G), then (*,*,RP)) in its multicast longest match search ((S,G), then (*,G), then (*,*,RP)) in its multicast
skipping to change at line 646 skipping to change at page 15, line 44
the oiflist is also modified to support sending PIM Registers with the the oiflist is also modified to support sending PIM Registers with the
Border-bit set to the corresponding RP. Border-bit set to the corresponding RP.
When a PIM-SM component receives an (S,G) Prune alert, and the When a PIM-SM component receives an (S,G) Prune alert, and the
forwarding cache entry's oiflist is empty, then for each PIM (S,G) state forwarding cache entry's oiflist is empty, then for each PIM (S,G) state
entry covered, it sends an (S,G) Join/Prune message with S in the prune entry covered, it sends an (S,G) Join/Prune message with S in the prune
list to the upstream neighbor according to normal PIM-SM behavior. list to the upstream neighbor according to normal PIM-SM behavior.
When a PIM-SM component receives a (*,G) Prune alert, it sends a (*,G) When a PIM-SM component receives a (*,G) Prune alert, it sends a (*,G)
Join/Prune message with G in the prune list to the upstream neighbor Join/Prune message with G in the prune list to the upstream neighbor
towards the RP for G, according to normal PIM-SM behavior. towards the RP for G, according to normal PIM-SM behavior.
When a PIM-SM component receives an (S,G) Join alert, it sends an (S,G) When a PIM-SM component receives an (S,G) Join alert, it sends an (S,G)
Join/Prune message to the next-hop neighbor towards S, and resets the Join/Prune message to the next-hop neighbor towards S, and resets the
(S,G) Entry-timer, according to normal PIM-SM behavior. (S,G) Entry-timer, according to normal PIM-SM behavior.
When a PIM-SM component receives a (*,G) Join alert, then it sends a When a PIM-SM component receives a (*,G) Join alert, then it sends a
(*,G) Join/Prune message to the next-hop neighbor towards the RP for G, (*,G) Join/Prune message to the next-hop neighbor towards the RP for G,
and resets the (*,G) Entry-timer, according to normal PIM-SM behavior. and resets the (*,G) Entry-timer, according to normal PIM-SM behavior.
When a PIM-SM component receives a (*,*) Join alert, then it sends When a PIM-SM component receives a (*,*) Join alert, then it sends
(*,*,RP) Join/Prune messages towards each RP. (*,*,RP) Join/Prune messages towards each RP.
When a PIM-SM component receives a (*,*) Prune alert, then it sends a When a PIM-SM component receives a (*,*) Prune alert, then it sends a
(*,*,RP) Prune towards each RP. (*,*,RP) Prune towards each RP.
7. CBTv2
In this section we describe how the rules in section 2 apply to CBTv2.
We assume that the reader is familiar with normal CBTv2 behavior as
specified in [5]. We note that, like MOSPF, CBTv2 allows joining and
pruning entire groups, but not individual sources within groups.
Interoperability between a single CBTv2 stub domain and a DVMRP backbone
is outlined in [8]. Briefly, CBTv2 MBR components are statically
configured such that, whenever an external route exists between two or
more MBRs, one is designated as the primary, and the others act as non-
forwarding (to prevent duplicate packets) backups. Thus, a CBTv2
domain must not serve as transit between two domains if another route
between them exists.
We now describe how a CBTv2 implementation may extend this to
interoperate with all other multicast routing protocols. A CBTv2
component acts as a wildcard receiver for internally-reached sources if
and only if any other component is a wildcard receiver for externally-
reached sources. It does this by sending JOIN-REQUESTs for all non-
local group ranges to all known cores, as described in [8].
Unless some form of Domain-Wide-Reports (DWRs) [10] are added to CBTv2
in the future, all CBTv2 components act as wildcard receivers for
externally-reached sources. If DWRs are available for the domain, then
a CBTv2 component acts as a wildcard receiver for externally-reached
sources only if internally-reached domains exist which do not support
some form of DWRs.
7.1. Generating Alerts
A (*,*) Join alert is sent to the iif owner of the (*,*) entry (e.g.,
the Interop dispatcher) when the first component becomes a wildcard
receiver for external sources. This may occur when a PIM-SM component
starts up and decides to act in this role.
A (*,*) Prune alert is sent to the iif owner of the (*,*) entry (e.g.,
the Interop dispatcher) when all components are no longer wildcard
receivers for external sources. This may occur when a PIM-SM component
which was acting in this role shuts down.
When the last oif is removed from the core tree for G, a (*,G) Prune
alert is sent to the "iif owner" for (*,G) according to the dispatcher.
Since CBTv2 always sends all data to the core, the only time this can
occur after the entry is created is when the MBR is the core. In this
case, the last oif is removed from the entry when:
o A QUIT-REQUEST is received on the logical interface, and there are
no directly-connected members present on the interface, or
o IGMP notifies CBT that there are no longer directly-connected
members present on the interface, and the interface is not a CBT
child interface for group G.
When the first CBT outgoing interface is added to an existing core tree,
a (*,G) Join alert is sent to the "iif owner" of (*,G) according to the
dispatcher. Since CBTv2 always sends all data to the core, the only
time these can occur, other than when the entry is created, is when the
MBR is the core. In this case, the first logical oif is added to an
entry when:
o A JOIN-REQUEST for G is received on the interface, or
o IGMP notifies CBT that directly-connected group members now exist
on the interface.
7.2. Processing Alerts
When a CBTv2 component receives an (S,G) Creation alert, and the router
is functioning as the designated BR, any CBT interfaces which are on the
tree for G are added to the forwarding cache entry's oif list (according
to normal CBTv2 behavior).
When a CBTv2 component receives an (S,G) Prune alert, the alert is
ignored, since CBTv2 cannot prune specific sources. Thus, it will
continue to receive packets from S since it must receive packets from
other sources in group G.
When a CBTv2 component receives a (*,G) Prune alert, and the router is
not the primary core for G, and the only CBT on-tree interface is the
interface towards the core, it sends a QUIT-REQUEST to the next-hop
neighbor towards the core, according to normal CBTv2 behavior.
When a CBTv2 component receives either an (S,G) Join alert or a (*,G)
Join alert, and the router is not the primary core for G, and the router
is not already on the core-tree for G, it sends a CBT (*,G) JOIN-REQUEST
to the next-hop neighbor towards the core, according to normal CBTv2
behavior.
4.5. IGMP-only links 4.5. IGMP-only links
In this section we describe how the rules in section 2 apply to a link In this section we describe how the rules in section 2 apply to a link
which is not within any routing domain, and hence no routing protocol which is not within any routing domain, and hence no routing protocol
messages are exchanged and the interface is not owned by any multicast messages are exchanged and the interface is not owned by any multicast
routing protocol component. We assume that the reader is familiar with routing protocol component. We assume that the reader is familiar with
normal IGMP behavior as specified in [7]. We note that IGMPv2 allows normal IGMP behavior as specified in [7]. We note that IGMPv2 allows
joining and pruning entire groups, but not individual sources within joining and pruning entire groups, but not individual sources within
groups. groups.
An IGMP-only "component" may only own a single interface; hence an An IGMP-only "component" may only own a single interface; hence an
IGMP-only domain only consists of a single link. Since an IGMP-only IGMP-only domain only consists of a single link. Since an IGMP-only
component can only act as a wildcard receiver for internally-reached component can only act as a wildcard receiver for internally-reached
sources if all internally-reached sources are directly-connected, then sources if all internally-reached sources are directly-connected, then
either the IGMP-only domain (link) must be a stub domain, or else there either the IGMP-only domain (link) must be a stub domain, or else there
must be no other components which are wildcard receivers for must be no other components which are wildcard receivers for
externally-reached sources. An IGMP-only component itself acts as a externally-reached sources.
wildcard receiver for externally-reached sources if any internally-
reached domains exist which do not support some form of DWRs.
4.5.1. Generating Alerts 4.5.1. Generating Alerts
When it is known that there are no longer any directly-connected members When it is known that there are no longer any directly-connected members
of a group G on the IGMP-only interface, a (*,G) Prune alert is sent to of a group G on the IGMP-only interface, a (*,G) Prune alert is sent to
the "iif owner" for (*,G) according to the Inter-domain component. In the "iif owner" for (*,G) according to the dispatcher. In IGMP, this
IGMP, this may happen when: may happen when:
o The group membership times out. o The group membership times out.
When it is first known that there are directly-connected members of a When it is first known that there are directly-connected members of a
group G on the interface, a (*,G) Join alert is sent to the "iif owner" group G on the interface, a (*,G) Join alert is sent to the "iif owner"
of (*,G), according to the dispatcher. In IGMP, this may happen when
of (*,G), according to the Inter-domain component. In IGMP, this may any of the following occur:
happen when any of the following occur:
o A Membership Report is received for G. o A Membership Report is received for G.
4.5.2. Processing Alerts 4.5.2. Processing Alerts
When an IGMP-only component receives an (S,G) Creation alert, and there When an IGMP-only component receives an (S,G) Creation alert, and there
are directly-connected members of G present on its interface, it adds are directly-connected members of G present on its interface, it adds
the interface to the entry's oif list. the interface to the entry's oif list.
When an IGMP-only component receives an (S,G) Prune alert, the alert is When an IGMP-only component receives an (S,G) Prune alert, the alert is
ignored, since IGMP can only prune entire groups at a time. ignored, since IGMP can only prune entire groups at a time.
skipping to change at line 724 skipping to change at page 19, line 15
When an IGMP-only component receives either an (S,G) Join alert or a When an IGMP-only component receives either an (S,G) Join alert or a
(*,G) Join alert, and the component was not previously a member of G on (*,G) Join alert, and the component was not previously a member of G on
the IGMP-only interface (and the component is not a wildcard receiver the IGMP-only interface (and the component is not a wildcard receiver
for internally reached sources), it joins the group on the interface, for internally reached sources), it joins the group on the interface,
causing it to send an unsolicited Membership Report according to normal causing it to send an unsolicited Membership Report according to normal
IGMP behavior. IGMP behavior.
When an IGMP-only component receives a (*,*) Join alert, it enters When an IGMP-only component receives a (*,*) Join alert, it enters
promiscuous multicast mode. promiscuous multicast mode.
5. References 5. Security Considerations
All operations described herein are internal to multicast border
routers. The rules described herein do not change the security issues
underlying individual multicast routing protcols. Allowing different
protocols to interact, however, means that security weaknesses of any
particular protocol may also apply to the other protocols as a result.
6. References
[1] Ajit S. Thyagarajan and Stephen E. Deering. Hierarchical [1] Ajit S. Thyagarajan and Stephen E. Deering. Hierarchical
distance-vector multicast routing for the MBone. In "Proceedings distance-vector multicast routing for the MBone. In "Proceedings
of the ACM SIGCOMM", pages 60--66, October 1995. of the ACM SIGCOMM", pages 60--66, October 1995.
[2] T. Pusateri. Distance vector multicast routing protocol. Internet [2] T. Pusateri. Distance vector multicast routing protocol. Internet
Draft, October 1997. Available from Draft, March 1998. Available from ftp://ds.internic.net/internet-
ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-dvmrp-v3- drafts/draft-ietf-idmr-dvmrp-v3-06.ps.
05.ps.
[3] J. Moy. Multicast extensions to OSPF. RFC 1584, July 1993. [3] J. Moy. Multicast extensions to OSPF. RFC 1584, July 1993.
[4] Estrin, Farinacci, Helmy, Thaler, Deering, Handley, Jacobson, Liu, [4] Estrin, Farinacci, Helmy, Thaler, Deering, Handley, Jacobson, Liu,
Sharma, and Wei. Protocol independent multicast-sparse mode (PIM- Sharma, and Wei. Protocol independent multicast-sparse mode (PIM-
SM): Protocol specification. RFC 2117, June 1997. SM): Protocol specification. RFC 2362, June 1998.
[5] A. Ballardie. Core based trees (CBT version 2) multicast routing: [5] A. Ballardie. Core based trees (CBT version 2) multicast routing:
Protocol specification. RFC 2189, September 1997. Protocol specification. RFC 2189, September 1997.
[6] Estrin, Farinacci, Helmy, Jacobson, and Wei. Protocol independent [6] Estrin, Farinacci, Helmy, Jacobson, and Wei. Protocol independent
multicast (PIM), dense mode protocol specification. Internet multicast (PIM), dense mode protocol specification. Internet
Draft, May 1997. Available from ftp://ds.internic.net/internet- Draft, May 1997. Available from ftp://ds.internic.net/internet-
drafts/draft-ietf-idmr-pim-dm-spec-05.ps. drafts/draft-ietf-idmr-pim-dm-spec-05.ps.
[7] W. Fenner. Internet Group Management Protocol, Version 2. RFC [7] W. Fenner. Internet Group Management Protocol, Version 2. RFC
2236, November 1997. 2236, November 1997.
[8] A. J. Ballardie. Core Based Tree (CBT) Multicast Border Router [8] A. J. Ballardie. Core Based Tree (CBT) Multicast Border Router
Specification. Internet Draft, November 1997. Available from Specification. Internet Draft, November 1997. Available from
ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-cbt-br-spec- ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-cbt-br-spec-
01.txt.
01.txt.
[9] D. Thaler, D. Estrin, and D. Meyer. Border Gateway Multicast [9] D. Thaler, D. Estrin, and D. Meyer. Border Gateway Multicast
Protocol (BGMP): Protocol Specification. Internet Draft, October Protocol (BGMP): Protocol Specification. Internet Draft, October
1997. Available from ftp://ds.internic.net/internet-drafts/draft- 1997. Available from ftp://ds.internic.net/internet-drafts/draft-
ietf-idmr-gum-01.txt. ietf-idmr-gum-01.txt.
[10] W. Fenner. Domain Wide Multicast Group Membership Reports, [10] W. Fenner. Domain Wide Multicast Group Membership Reports,
Internet Draft, November 1997. Available from Internet Draft, November 1997. Available from
ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-membership- ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-membership-
reports-00.txt. reports-00.txt.
6. Security Considerations
Security considerations are not discussed in this document. All
operations described herein are internal to multicast border routers.
7. Address of Author 7. Address of Author
Dave Thaler Dave Thaler
Microsoft Microsoft
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
Phone: (425) 703-8835 Phone: (425) 703-8835
Email: thalerd@eecs.umich.edu Email: thalerd@eecs.umich.edu
8. Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE."
 End of changes. 50 change blocks. 
82 lines changed or deleted 226 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/