Network Working Group
Internet Draft Deborah Estrin (USC)
Ahmed Helmy (USC)
David Thaler (UMICH)
draft-ietf-mboned-pmbr-spec-00.txt Feb 3, 1997
PIM Multicast Border Router (PMBR) specification for connecting PIM-
SM domains to a DVMRP Backbone
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. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
``working'' draft'' or ``work in progress.''
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
Estrin,Helmy,Thaler [Page 1]
Internet Draft PMBR specification Feb 1997
1 Assumptions
This document specifies the behavior of PIM-SM Multicast Border
Routers (PMBRs) that connect PIM-SM to DVMRP networks. We assume that
the reader is familiar with the PIM-SM protocol
specification.[Estrin96]
The following assumptions are made regarding the PMBR architecture
and connectivity:
1 The PMBR is located at the boundary of a PIM-SM multicast
domain, and connects the domain to a multicast domain that
does not run PIM-SM. In this document we focus on
connectivity to DVMRP speaking domains.
2 The PMBR implements the multicast protocols of the
multicast domains to which its interfaces are connected; in
this document this implies PIM-SM and DVMRP. Any PMBR
implementation can be logically viewed as having two
components; one implementing PIM-SM and another
implementing DVMRP.
3 Only one multicast protocol is implemented per interface;
mixed multicast protocol LANs on the border are not
permitted. Interfaces are classified as either PIM-SM or
DVMRP interfaces. Each component owns the interfaces
corresponding to its type. The PIM-SM component is
responsible for adding or deleting PIM-SM interfaces from
iif and oif entries of the multicast routing table, and
similarly the DVMRP component is responsible for adding and
deleting DVMRP interfaces.
4 The multicast backbone is running DVMRP.
5 A PMBR is used at all interconnection points between PIM-SM
and DVMRP regions.
2 Overview and example
The PMBR has two primary roles. First it must pull down packets
generated within the PIM-SM domain and inject them into the
Estrin,Helmy,Thaler [Page 2]
Internet Draft PMBR specification Feb 1997
DVMRP backbone. Second, it must import packets generated
outside the PIM-SM domain so that they can be delivered to group
members inside the PIM-SM domain, using PIM-SM mechanisms.
Furthermore, in case of transit networks, the PMBR acts to pass
the multicast traffic through the PIM domain.
3 Detailed Message Processing
This section discusses, in more detail, the message processing
in each of the PMBR components. Only deviations from the
standard behaviors, or additions thereto, are discussed. The
assumed standard behavior for PIM-SM and DVMRP is described in
PIM-SMv2 spec [Estrin96] and DVMRP spec [Pusateri96],
respectively. We assume that the forwarding entries are only
(S,G) forwarding entries. The internal communication protocol
between the components is assumed to support the internal signal
types: `Join', `Prune', `Creation', and `Deletion Request'
signals. All these internal signals are (S,G) specific. (The
internal communication protocol between the components of the
PMBR is not specified in this document, and is an implementation
issue.)
3.1 The PIM-SM Component
3.1.1 Receiving Bootstrap messages
Upon receiving a Bootstrap message, the PIM-SM Component does
the following:
1 The received Bootstrap message is processed as in standard
PIM (see section `Receiving and Forwarding Bootstrap' in
PIM-SMv2 spec).
2 If the Bootstrap message is accepted, a (*,*,RP) state is
set up for every new RP in the RP-Set whose mask indicates
that the RP supports non-local groups (for example,
239.X.X.X is considered locally scoped and PMBRs do not set
(*,*,RP) state for RPs supporting only that portion of the
address space). The (*,*,RP) states trigger (*,*,RP) Joins
towards the corresponding RPs.
(*,*,RP) Joins are periodically sent off of the (*,*,RP)
entries, as in
standard PIM. (*,*,RP) entries at the PMBRs are not deleted if
the
Estrin,Helmy,Thaler [Page 3]
Internet Draft PMBR specification Feb 1997
(*,*,RP) entry timer expires; they are deleted only when the
corresponding RP is removed from the RP-Set.
3.1.2 Receiving data packets from a PIM-SM interface
When a data packet is received on a PIM-SM interface:
1 The PIM-SM component processes the data packet as in
standard PIM,
2 If the packet for (S,G) is accepted, there was no previous
(S,G) entry, and `G' is a non-local group, then a new (S,G)
forwarding entry is created. In this case an internal
`Creation' signal is sent to the DVMRP component.
3 The packet is forwarded to the outgoing interface list
(oiflist) of the new entry (including the oifs added by the
DVMRP component, if any).
3.1.3 Receiving Register-Stop
Register-Stop messages are processed as in standard PIM (see
section
`Sending Registers and Receiving Register-Stops' in PIM-SMv2
spec).
Further, if the (S,G) forwarding entry oiflist becomes null
(an
entry set up for sending Registers is not considered a null
oiflist entry,
since this indicates a virtual encapsulation interface), and
the iif
is a DVMRP interface, an internal `Prune' is sent to the DVMRP
component.
3.1.4 Receiving PIM Join/Prune messages
When a PIM Join/Prune message is received on a PIM-SM interface:
1 The PIM-SM component processes the Join/Prune as in
standard PIM
2 If any affected (S,G) forwarding entry's oiflist changed
from null to non-null and a DVMRP interface as iif, an
Estrin,Helmy,Thaler [Page 4]
Internet Draft PMBR specification Feb 1997
internal `Join' is sent to the DVMRP component.
3 If the last oif is deleted from any (S,G) forwarding entry,
whose iif is a DVMRP interface, an internal `Prune' is sent
to the DVMRP component, for the corresponding entry(ies).
3.1.5 Receiving PIM Asserts
When a PIM Assert is received on a PIM-SM interface:
1 The PIM-SM component processes the Assert as in standard
PIM
2 If due to the Assert processing, the last oif is deleted
from any (S,G) forwarding entry(ies); where S is reached
via DVMRP interface, an internal `Prune' signal is sent to
the DVMRP component, for the corresponding entry(ies).
3.1.6 Register-bit timer expiry
When the Register-bit timer expires for an (S,G) entry, for
which iif is a DVMRP interface:
1 The PIM-SM component modifies the (S,G) forwarding entry to
support unicasting Registers with the Border-bit set, to
the corresponding RP.
2 If the forwarding entry had null oiflist, an internal
`Join' is sent to the DVMRP component.
3.1.7 (S,G) forwarding entry timeout
When a (S,G) entry timer expires in the PIM-SM component, an
internal `Deletion Request' signal is sent to the DVMRP
component.
3.1.8 Switching to the Shortest Path Tree (SPT)
Switching to the SPT is done according to standard PIM. In this
context the PMBR acts as a DR for external receivers. In
addition, if there is a (S,G) entry for which S is reached via
Estrin,Helmy,Thaler [Page 5]
Internet Draft PMBR specification Feb 1997
a PIM-SM interface, and the oiflist includes DVMRP interfaces,
the PMBR may switch to the SPT.
3.1.9 Receiving Internal Join
When the PIM-SM component receives an internal Join, the Join is
processed as a standard PIM (S,G) Join. However, instead of
restarting the oif timer, the entry timer for the corresponding
entry is restarted.
3.1.10 Receiving Internal Prune
The internal Prune is handled by the PIM-SM component as a
standard PIM (S,G) Prune.
3.1.11 Receiving Internal Creation Signal
When the PIM-SM component receives a `Creation' signal for
(S,G), if S is reached via a DVMRP interface, the PIM-SM
component modifies the (S,G) forwarding entry to support sending
PIM Registers with the Border bit set, to the corresponding RP.
3.1.12 Receiving Internal Deletion Request Signal
If the entry timer for the (S,G) forwarding entry has expired in
the PIM-SM component the entry is deleted.
3.1.13 Routing Updates For PIM-SM transit domains we require that
the PIM-SM component (as well as all PIM internal routers),
implement the DVMRP routing information exchange protocol to
support consistant RPF computation on both sides of the PIM-SM
domain. The PIM-SM component exchanges routing updates with the
DVMRP component of the PMBR, according to standard DVMRP.
3.2 The DVMRP Component
3.2.1 Receiving data packets from a DVMRP interface
Upon receiving data packets from a DVMRP interface,
the following actions are taken:
1 The DVMRP component processes the packet according to DVMRP
rules.
2 If a packet for (S,G) is accepted, for which there was no
previous (S,G) state, a (S,G) state is created, and an
internal `Creation' signal is sent to the PIM-SM component.
Estrin,Helmy,Thaler [Page 6]
Internet Draft PMBR specification Feb 1997
3 The packet is forwarded to the oiflist of the new entry
(including oifs added by the PIM-SM component, if any).
3.2.2 Receiving DVMRP (S,G) Prunes
When a DVMRP Prune message for (S,G) is received on a DVMRP
interface, the DVMRP component performs the following:
1 The DVMRP component processes the Prune message according
to DVMRP rules.
2 If the oiflist for the corresponding entry becomes null,
and the iif for the entry is a PIM-SM interface, an
internal `Prune' signal is sent to the PIM-SM component.
3.2.3 Receiving DVMRP (S,G) Graft
When a DVMRP Graft message is received on a DVMRP interface, for
a source reached via a PIM-SM interface, the DVMRP component
performs the following:
1 The DVMRP component processes the Graft message according
to DVMRP rules.
2 If the matching entry previously had null oiflist, an
internal `Join' is sent to the PIM-SM component.
3.2.4 (S,G) Prune timeout
When an interface Prune timer expires, for a (S,G) entry; where
S is reached via a PIM-SM interface, the DVMRP component
performs the following:
1 The timeout is processed as in standard DVMRP
2 If the forwarding entry previously had a null oiflist, an
internal `Join' is sent to the PIM-SM component.
Estrin,Helmy,Thaler [Page 7]
Internet Draft PMBR specification Feb 1997
3.2.5 Receiving Internal Join
The internal Join is treated as a DVMRP Graft.
3.2.6 Receiving Internal Prune
The internal Prune is treated as a DVMRP Prune.
3.2.7 Receiving Internal Creation signal
When the DVMRP component receives an internal `Creation' signal
for a (S,G) forwarding entry, the following is performed:
1 All dependent downstream DVMRP interfaces, for the given
source, are added to the oiflist of the corresponding
forwarding entry, as specified by DVMRP.
2 If S is reached via a DVMRP interface, a DVMRP Graft is
sent upstream.
3.2.8 Receiving Internal Deletion Request signal
If the entry timer has expired in the DVMRP component, the entry
is deleted.
4 References
[Estrin96] Protocol Independent Multicast Sparse-Mode (PIM-SM):
Protocol
Specification.
D. Estrin, D. Farinacci, A. Helmy, D. Thaler,
S. Deering, M. Handley, V. Jacobson, G. Liu, P.
Sharma, L. Wei,
December 1997
[Pusateri96] Distance Vector Multicast Routing (DVMRP): Protocol
Specification. Tomas Pusateri,
September 1996
Estrin,Helmy,Thaler [Page 8]
Expire in six months
