One document matched: draft-ietf-idmr-membership-reports-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 06:04:12 |