[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

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


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/