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

Versions: 00 01 02 03 04 05

Internet Engineering Task Force        Inter-Domain Multicast Routing WG
INTERNET-DRAFT                                                 W. Fenner
draft-ietf-idmr-membership-reports-00.txt              November 12, 1997
                                                        Expires May 1998

             Domain Wide Multicast Group Membership Reports

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."

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).

Distribution of this document is unlimited.

                                Abstract

     When running a multi-level multicast routing protocol, upper layers
     need to know about group memberships in lower layers in a
     protocol-independent fashion.  Domain Wide Multicast Group
     Membership Reports allow this information to be learned in a
     fashion similar to IGMP[Fenn97] at the domain level.

This document is a product of the IDMR working group within the Internet
Engineering Task Force.  Comments are solicited and should be addressed
to the working group's mailing list at idmr@cs.ucl.ac.uk and/or the
author.







Fenner                      Expires May 1998                    [Page 1]


Internet Draft draft-ietf-idmr-membership-reports-00.txNovember 12, 1997


1.  Introduction

Domain-Wide Multicast Group Membership Reports (DWRs) are a group
membership protocol at the domain level.  When using a heirarchical
multicast routing protcol [Thya94],[Thal97], the inter-domain protocol
needs to learn of group memberships inside domains.  Although some
intra-domain routing protocols can provide this information easily to
the domain border routers, some cannot.  DWRs specify a protocol-
independent manner to learn group membership inside a domain.

This document specifies the DWR protocol, as used by border routers and
interior routers.  It specifies a behavior that can be used with any
intra-domain protocol, along with optimizations for certain intra-domain
protocols, and a transition scheme so that all interior routers need not
be updated.

2.  Packet Format

DWR packets are sent as IGMP packets (IP protocol #2) when using IPv4.
It's not yet clear what IPv6 type will be used, or if they should have
their own IP protocol number which can be the same for v4 and v6.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    IGMP type  |    DWR type   |          checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Response Time         |             MBZ               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


2.1.  IGMP Type: 8 bits

     The IGMP type field is defined to be 0xXX.

2.2.  DWR Type: 8 bits

     The following DWR types are defined:

                 Type                   Name
                 ___________________________________________
                 0x00   Domain-Wide Query
                 0x01   Domain-Wide Membership Report
                 0x02   Domain-Wide Leave
                 0x03   Non-authoritative Domain-Wide Leave*







_________________________
  * Note that the requirement for  a  Non-authoritative






Internet Draft draft-ietf-idmr-membership-reports-00.txNovember 12, 1997


2.3.  checksum

     IP-style checksum over the whole packet, zeroed for computing
     checksum.  This checksum MUST be computed when transmitting
     packets, and MUST be verified when receiving.

2.4.  Response Time

     The time, in units of 100ms, allowed for responses.  Varying this
     field allows tuning the burstiness of DWR traffic at the cost of
     higher latencies.

2.5.  MBZ

     This field must be zeroed on transmission and ignored on reception.

2.6.  Data

     This field consists of the rest of the packet.  It may consist of
     one of two forms; a Group Address:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Group Address                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     >>>Include mask with group???  TBD<<< or an option header:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | option number |    MBZ    |S|I|          Option Length        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Option Data...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     The two forms may be told apart because option numbers are assigned
     in the range [0,223], the first byte of an IPv4 group address is in
     the range [224,239], and the first byte of an IPv6 group address is
     255.



_________________________
DWL has been questioned.




Fenner                      Expires May 1998                    [Page 3]


Internet Draft draft-ietf-idmr-membership-reports-00.txNovember 12, 1997


     2.6.1.  Data Description

     2.6.1.1.  Group Address

          The group address being reported or queried.

     2.6.1.2.  Option Number

          The number of the option.

     2.6.1.3.  MBZ

          Must be zeroed on transmission and ignored on reception.

     2.6.1.4.  I

          Ignore this entry for group membership purposes if the option
          is not recognized.

     2.6.1.5.  S

          Ignore this entry for report suppression purposes (on Replies
          or Leaves) or for reply purposes (on Queries) if the option is
          not recognized.

     2.6.1.6.  Option Length

          The number of words, excluding the initial word, of option
          data following the option header.

     2.6.1.7.  Option Data

          Option Length words of data.

     2.6.2.  Option Processing

          Options which precede any group addresses are called Global
          Options.  Options which follow a group address are associated
          with that group address and are called Group Options.  Groups
          with options attached should be ignored as if they were not
          present if there are unrecognized Group Options with the S bit
          set.  Packets with Global Options should be ignored as if they
          were not received if there are unrecognized Global Options
          with the S bit set.

     2.6.3.  Defined Options

          One envisioned use for options is to expand DWR's to include



Fenner                      Expires May 1998                    [Page 4]


Internet Draft draft-ietf-idmr-membership-reports-00.txNovember 12, 1997


          IGMPv3 source-specific information, using the S and I bits to
          provide full backwards compatibility.

          2.6.3.1.  Unicast-reply

               This option has the S bit turned off (e.g. may be ignored
               if not understood) [but it's in the original spec so
               should be implemented].  If a query is received with this
               option, the reply should be unicasted to the source of
               the query.  If the option carries a unicast address, it
               is the address to be unicasted to.

               If a unicast address is specified in the option, the
               option MUST be ignored if the receiver does not have an
               IPSEC[Atki95] relationship with the source of the packet.

3.  Message Descriptions

3.1.  Domain-Wide Query

     A Domain-Wide Query is sent periodically by one of the domain's
     border routers.  >>>Querier Election TBD<<<.  The default period is
     >>>TBD<<<, and MUST be configurable.  Domain-Wide Query messages
     are sent to the well-known Domain-Wide Query multicast group.  This
     group is in the range of addresses that are scoped to a single
     domain, which has not yet been allocated by the IANA.

     A Domain-Wide Query with no additional data is a request for
     knowledge of all multicast group memberships in the domain.  The
     Domain-Wide Query may be restricted by including groups or options
     in the data portion of the packet.  If group addresses or DWR
     options are specified in the packet, the Query is restricted to
     those groups or other options as specified in the packet.

3.2.  Domain-Wide Report

     A Domain-Wide Report is sent by a router in response to a Domain-
     Wide Query message, or in response to the appearance of a new group
     member in the domain.  The latter messages are called "Unsolicited"
     Domain-Wide Reports.

     A Domain-Wide Report message includes a list of group memberships
     and other options in the additional data portion of the packet.

3.3.  Domain-Wide Leave

     A Domain-Wide Leave is sent by a router when it knows that there
     are no more members in the domain of a group or groups.  The group



Fenner                      Expires May 1998                    [Page 5]


Internet Draft draft-ietf-idmr-membership-reports-00.txNovember 12, 1997


     or groups listed in the additional data portion of the packet are
     considered by the border routers to have no more members.

3.4.  Non-Authoritative Domain-Wide Leave

     There are tradeoffs to providing a Non-Authoritative Domain-Wide
     Leave message.  A Non-Authoritative Domain-Wide Leave is sent by a
     router when it has no more members of the group but cannot be sure
     there are no more members in the domain, and causes the elected
     border router to send a Domain-Wide Query message for the group(s)
     mentioned in the Non-Authoritative Domain-Wide Leave message.  This
     adds to the time before the border routers can signal that there
     are no group members inside the domain.  With DVMRP and PIM-DM (the
     two current multicast routing protocols that would require a Non-
     Authoritative Domain-Wide Leave), it is possible for the border
     routers to notice that all sources for the group have been pruned
     to all border routers, and determine that there are no internal
     members in that way.  However, if there are no active senders, this
     method doesn't work.  In certain Inter-Domain multicast routing
     protocols, group members in domains cause state to exist whether
     there are active senders or not, so it is advantageous to know as
     soon as possible (e.g. this is an argument for N-A D-W L).  The
     disadvantage is yet more protocol mechanism (mostly involving more
     timers on the border routers) and more protocol activity inside
     domains requiring this message.

4.  Interior Router Behavior

4.1.  General Behavior

     This section describes the general behavior of interior routers, or
     of proxies running inside domains.  Some of these behaviors may be
     optimized when running multicast routing protocols with more
     centralized knowledge of group memberships inside the domain; these
     optimizations will be described later.

     If a router has not yet been upgraded to perform domain-wide
     reports, a proxy may be placed on each of its connected networks.
     This proxy must partipicate in the networks's group membership
     protocol (e.g.  IGMPv2[Fenn97]).  For example, it may perform only
     the duties of a Non-Querier in IGMPv2, which allow it to passively
     learn all of the group members on a network.  The proxy can then
     respond to Domain-Wide Query messages just as the interior router
     would.

4.1.1.  Reception of Queries

     All routers in the domain join the Domain-Wide Query well-known



Fenner                      Expires May 1998                    [Page 6]


Internet Draft draft-ietf-idmr-membership-reports-00.txNovember 12, 1997


     multicast group.  Upon reception of a Domain-Wide Query message, a
     router sets a timer to a value randomly chosen from the range (0,
     Response time] as specified in the packet.  The Data section of the
     Query should be saved to be used when the timer expires.

4.1.2.  Transmission of Reports

     Upon the expiry of a Domain-Wide Query timer, a router assembles a
     packet containing the list of group memberships on subnets directly
     connected to this router, excluding those that were suppressed by
     previous reports, and send this message to the Domain-Wide Report
     well-known multicast group.  If the Domain-Wide Query contained a
     list of groups or options, the Report should be restricted to those
     groups in the list in the Query message.

4.1.3.  Reception of Reports

     All routers in the domain join the Domain-Wide Report well-known
     multicast group in order to perform suppression, as follows.  Upon
     reception of a Domain-Wide Report message, a router processes the
     list of groups in the message.  For each group, if the group has
     unrecognized options, it should be skipped if any of the
     unrecognized options have their S bit set.  Otherwise, if the
     router has attached members of the group, it should mark that
     record as being suppressed by another report, and record the
     existence of this group membership in the domain.  This record MUST
     time out after >>>XXX<<<, and MUST be cancelled by reception of a
     Domain-Wide Leave or Non-Authoritative Domain-Wide Leave message
     mentioning this group.

4.1.4.  Reception of Leaves

     Upon the reception of a Domain-Wide Leave, a router should process
     the list of groups in the message.  For each group, if the group
     has unrecognized options, it should be skipped if any of the
     unrecognized options have their S bit set.  Otherwise, the router
     should remove its record of the existence of another group
     membership in the domain.

4.1.5.  Transmission of Leaves

     A router sends a Non-Authoritative Leave when all directly-attached
     group members leave the group.  This message MAY be suppressed if
     some other router was the last to report group membership with a
     DWR.






Fenner                      Expires May 1998                    [Page 7]


Internet Draft draft-ietf-idmr-membership-reports-00.txNovember 12, 1997


4.2.  Optimizations

     In explicit group membership protocols like PIM, CBT and MOSPF,
     there is a set of routers smaller than "all routers in the domain"
     which knows of group memberships in the domain.  This section
     describes the optimizations possible when running a protocol like
     this.

     In PIM and CBT, only RP's and Cores must participate.  MOSPF is a
     special case, in that all routers in the MOSPF domain know of all
     group memberships in the domain.  In this case, the DWR protocol
     may degenerate to a virtual protocol run entirely inside the
     elected border router.

4.2.1.  Reception of a Query Message

     Only participating interior routers must join the Domain-Wide Query
     well-known multicast group.

4.2.2.  Transmission of a Report Message

     Report messages contain all memberships that this router knows
     about (e.g. in MOSPF, it's all memberships in the domain; in PIM,
     it's all groups that I'm the RP for).

4.2.3.  Reception of a Report Message

     If there is no overlap of the groups being reported by each
     participant, the interior routers need not join the Domain-Wide
     Report well-known multicast group so will not receive Report
     messages.  E.g.  if R1 and R2 each handle one half of the multicast
     group address space, there is no need for them to join the Domain-
     Wide Report group.

4.2.4.  Reception of a Leave Message

     As with Reports, if there is no overlap, the interior routers need
     not join the DWR group so will not receive these messages.

4.2.5.  Transmission of a Leave Message

     If it is possible to know when the last member in the domain goes
     away, send authoritative Domain-Wide Leave messages, instead of
     Non-Authoritative Domain-Wide Leave messages.

5.  Unsolicited messages

     When a new group member appears in the domain, a Report message



Fenner                      Expires May 1998                    [Page 8]


Internet Draft draft-ietf-idmr-membership-reports-00.txNovember 12, 1997


     SHOULD be transmitted (called an Unsolicited Report).  Interior
     routers MAY track the presence of group members inside the domain;
     a router which is doing this SHOULD suppress its unsolicited Report
     if it knows of another group member inside the domain.

6.  Border Router Behavior

6.1.  Send Periodic Queries

     The elected border router should send periodic Queries.

6.2.  Querier Election

     All border routers should join the Domain-Wide Queries well-known
     multicast group, in order to perform Querier Election.  All routers
     start up thinking they are the elected Querier.  If a router hears
     a DWQ from a router with a lower IP address, it elects that router
     as Querier.  It is recommended to have an IPSEC[Atki95]
     relationship among the domain border routers so that Querier
     Election can not be fouled by a forged packet.

6.3.  Send Group-Specific Queries in response to Non-Authoritative
Leaves

6.4.  Request Unicast Replies

     If a Border Router wishes to reduce the amount of DWR multicast
     traffic in a domain, it may add the "Reply via Unicast" option to
     its DWQ's.  This has the advantage of reducing the amount of state
     kept inside the domain for forwarding packets destined to the DWR-
     reply multicast group, at the cost of eliminating suppression.  The
     border router must multicast DWR's sumarrizing the replies it got
     via multicast to the DWR-reply multicast group when the response
     interval is over.

7.  Miscellaneous issues

7.1.  Unsolicited Reports

     What about unsolicited reports when there's no domain-wide querier?
     Does a router wait to hear a query before it sends its unsolicited
     DWR's?  If not, how do we protect the current MBone which has no
     domain boundaries against unsolicited reports?  If so, what about a
     router that has just rebooted?

7.2.  Non-authoritative leave messages

     In DVMRP and PIM-DM domains, where a router knows that its



Fenner                      Expires May 1998                    [Page 9]


Internet Draft draft-ietf-idmr-membership-reports-00.txNovember 12, 1997


     directly-attached group member has left a group but does not know
     whether or not there is another member in the domain.  Therefore,
     it could send a non-authoritative leave message which solicits a
     group-specific query from the querying border router, similar to
     Leave messages in IGMPv2[Fenn97].

     Some argue that it's possible to implement this functionality with
     the natural Prune messages inside the domain -- if a group gets
     pruned for all sources all the way to the border routers, then the
     border routers could send an authoritative leave message, and there
     would be no need for non-authoritative messages (which simplifies
     the protocol).  However, a) the border routers have to agree that
     they have all received Prune messages, which is potentially
     complicated, and b) it's possible for all DVMRP or PIM-DM state to
     time out for a quiescent sender, so there are no prunes sent when
     the last group member in the domain leaves the group.  Although
     it's true that no traffic is flowing, and when traffic does flow
     prunes will occur and the border routers will notice and send an
     authoritative domain-wide leave as above, the fact that this domain
     is a member of the group will take state in the next-level
     multicast routing protocol.  Non-authoritiative leaves allow the
     removal of said state when the last member leaves, which is
     potentially much sooner than the next traffic to the group.

7.3.  Elect Reporters?

     In order to help with suppression in a domain, a Querier might
     choose to elect a "Designated Reporter" for a group for a certain
     duration.  The Designated Reporter is the only router which should
     send Reports for the designated group(s) for the designated time.
     All others should act as though they have been suppressed for the
     designated time.  The Querier should cancel a router's Designated
     Reporter status when that router sends a Leave message, or when it
     hasn't heard a reply from that router for <N> Query intervals.
     When cancelling a router's Designated Reporter status, a Querier
     should send a Group-Specific Query for the group(s) in question and
     can optionally elect one of the responders as the new Designated
     Reporter.

7.4.  Both I and S?

     Both I and S bits are required.  Consider a Border Router B, and
     interior routers X and Y.  X understands and generates the source-
     specific membership option, and Y does not.  If there were only one
     bit, X should set it so that Y's whole-group membership report was
     not suppressed by X's source-specific membership report.  However,
     if B doesn't understand a source-specific membership report and X
     is the only member in the domain, B will ignore X's source-specific



Fenner                      Expires May 1998                   [Page 10]


Internet Draft draft-ietf-idmr-membership-reports-00.txNovember 12, 1997


     membership report.  This motivates the seperate S bit.

     The seperate I bit was originally motivated by the idea of routers
     announcing group/RP mappings using DWR's and an option (while
     routers may not necessarily have members, they might still want to
     announce the mapping).  With the evolution of PIM and CBT this
     particular use is no longer required but is perhaps general enough
     to motivate inclusion of the bit for future use.

8.  Acknowledgements

     The ideas of unicasting DWR replies and of electing a "designated
     reporter" came from a discussion on the IDMR mailing list with
     Jeffrey Zhang and Yunzhou Li of Bay Networks.  This discusison is
     still ongoing =)

9.  Security Considerations

     Many same as IGMPv2[Fenn97]

9.1.  Unicast Responses

     Sending a DWQ requesting a unicast response can cause many DWR's to
     be unicasted to the sender.  Requiring IPSEC authentication on the
     DWQ only if it requests unicast to a different address may not be
     strong enough - for example, someone at the other end of a slow
     link may swamp the link by sending a DWQ.

10.  Author's Address


   William C. Fenner
   Xerox PARC
   3333 Coyote Hill Road
   Palo Alto, CA 94304
   Phone: +1 650 812 4816
   Email: fenner@parc.xerox.com














Fenner                      Expires May 1998                   [Page 11]


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