Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/idmr/idmr-minutes-94mar.txt

Text File | 1994-06-07 | 11KB | 219 lines

CURRENT_MEETING_REPORT_

Reported by Tony Ballardie/University College London

Minutes of the Inter-Domain Multicast Routing Working Group (IDMR)

The IDMR Working Group met twice at the 29th IETF in Seattle,
Washington.  Both sessions were chaired by Tony Ballardie.

The group has considered changing the name of IDMR to better reflect its
purpose and scope.  This will involve some additions to the charter,
although the overall goals of the IDMR charter will remain the same.  It
is proposed that the new name of the IDMR group be:  ``The Multicast
Working Group.''  The mailing list name will also be changed to
[e-mail].  However, this does not come into effect
immediately and is subject to approval by the Routing Area Director.
Notification will be sent to the list once the change has been approved.


First Session

An update of CBT was presented by Tony Ballardie.  This included
notification of state regarding implementation, as well as some new CBT
protocol features.  These include the implementation of ``fast
pruning''---a new version of IGMP for CBT which provides lower leave
latency (approximately 12 seconds) for CBT hosts.  This involved adding
a new IGMP LEAVE message to the IGMP protocol.

Another new CBT feature involves the capability of a CBT user to send
either CBT-style packets (which traverse a CBT shared tree) or
traditional IP-style multicast packets (which traverse a shortest-path
tree) by using a ``toggle'' the CBT user interface.  In order to take
advantage of this feature it is assumed that at least one DVMRP (or
MOSPF or PIM) router exists on the same subnet as the CBT host.  CBT
hosts and routers can both send and receive traditional IP-style
multicast packets.

A ``CBT Architecture Overview and Specification'' document will be
available shortly.  This will include details on interaction with
current IP multicast schemes, and a new scoping mechanism.

The first session concentrated on the PIM sparse mode and dense mode
specifications.  Deborah Estrin went through various aspects of the PIM
sparse mode specification.

Firstly, the mechanisms by which looping is prevented/detected on
multi-access subnetworks if reverse path (RP) and source trees overlap,
were explained.  There is both a prevention mechanism preventing the
looping scenario from arising, and a detection-recovery mechanism should
a looping situation nevertheless occur.  The first case takes advantage
of the fact that PIM JOIN/PRUNE messages are multicast onto a LAN, and
other routers on a LAN receiving these messages can take appropriate
action---usually by creating a negative cache entry, to prevent
unnecessary forwarding onto the LAN. The detection approach involves
explicit PIM ASSERT messages (multicast to the ``all-routers'' address)
which are sent whenever a data packet is received on an outgoing
interface for some (S, G) pair.  Receiving routers may delete the
arrival interface from their outgoing interface list for their (S, G)
entry (if they have one) according to certain rules, or if none applies,
a receiving router may itself send a PIM ASSERT, and the process repeats
itself.

The differences between PIM sparse and dense modes were also explained,
and the conditions under which each would be appropriate.  Dense mode is
appropriate if the network (or scope of operation) is uniformly
bandwidth rich (e.g., a campus network).  In this case, the preferred
mode of operation is data driven flooding and pruning in place of having
an RP/shared tree.  Sparse mode is used if the operational region in
question has bandwidth limitations/costs/constraints.  For example, for
wide-area inter-domain multicasting, flood-prune mode is unacceptable
and does not scale, particularly when groups are not uniformly dense.
In such cases RPs/shared trees are used, with the option for receivers
to switch to shortest-path trees (although it is not yet clear under
which conditions/criteria a receiver's first-hop router makes the
decision to make such a switch).

An explanation was also given of hybrid dense mode/sparse mode
behaviour.  Each PIM router can have its interfaces independently
configured to operate either in sparse mode or dense mode (some of a
router's interfaces may be sparse, some may be dense).  A down stream
router knows the mode of its upstream neighbour by receiving PIM QUERY
messages.  JOIN messages are converted to PIM GRAFT messages if sent out
of a dense mode (DM) interface.  A GRAFT is converted to a PIM JOIN when
sent out of a sparse mode (SM) interface.

A question was raised regarding the negative effect of a large number of
control messages (periodic SM messages) which would arise given a very
large number of groups operating in SM. It was suggested that some form
of message aggregate would be a good idea for such a case.

A number of open issues were briefly mentioned, including how to
aggregate source information, whether it is worth having implicit join
mode vs.  periodic join mode, how RP identities are communicated to new
sources/receivers.

Dino Farinacci presented an update on PIM DM for the latter part of the
first session.  He presented the most significant changes with regards
to the latest DM specification, which mainly centered around explaining
the PIM ASSERT message processing for eliminating duplicates on a
multi-access subnet (see above).

Various DM open issues include:  how to interface pure DM clouds to
other multicast clouds such as DVMRP and MOSPF; how to get internal
group state to border routers (in particular how to fix entry points to
a cloud -- problem of data packets not being received on shortest
reverse path); interaction with DVMRP.

The state of PIM implementation is as follows:  a DM prototype is
complete; SM implementation is about to begin; interaction with DVMRP is
being worked on; CBONE (CiscoBONE) currently has 10 multicast routers on
it, consists of real links and tunnels; simulation and a SunOS
implementation of PIM DM is ongoing at USC.


Second Session

Steve Deering presented the details of a new version of the IGMP
protocol (IGMPv2), which is currently under development.  The motivation
for a new IGMP version is the need for lower leave latency---the time
between the last group member on a subnet relinquishing membership of a
particular group, and not receiving further traffic on that subnet for
the same group---it is deemed particularly important where high
bandwidth traffic is concerned.  Currently, leave latency is around 4.5
minutes.

Briefly, IGMPv2 involves an explicit LEAVE message which is heard by
``new'' routers.  On receipt of a LEAVE message, a new router sends a
new query which is addressed to the group (as specified in the LEAVE
message).  This new query includes in it a randomization interval over
which the group receivers on the subnet should randomize their response
(report) -- as with the old version, a group report will suppress other
reports for the same group.  By specifying a randomization interval in
the query, leave latency can be as low (or lower than) one second.

The new version is backwards compatible with the existing version.

Other changes proposed by Deering included the following:


   o Requiring changes to multicast service interface
      -  source-specific leave
      -  core/RP identification reports
      -  shared tree vs.  source-tree preference indicator in reports

   o Not requiring changes to multicast service interface
      -  host reception of prunes
      -  eliminate need for routers to be promiscuous to all IP
         multicasts


Finally, there was some general discussion on administrative scoping of
multicast addresses.  The problem that this tackles is being able to
effectively limit the scope of multicast packets (i.e., keep them within
a domain).  Limiting TTL value is not effective in this respect, and
does not prevent traffic coming in to a domain, although carefully
setting TTL can help prevent it from getting out.

Van Jacobson proposes allocating a block (64,000 address block) from the
upper portion of the IP multicast address space.  The reason for not
allocating more was that it is better to start small and grow, rather
than wasting addresses.

Sub-blocks would then be assigned to routing domains for use within
those domains.  Each domain would then have full control over its block
of addresses and could use and re-use them as it sees fit.  Border
routers would need to know the boundary of a domain's multicast address
space so as to know whether to forward packets or not.

Overlapping boundaries are potentially a problem -- this is the
motivation for assigning a larger block than 64K. Christian Huitema
expressed concern with the problem of being able to clearly define
boundaries and was sceptical about this approach.


Attendees

Susie Armstrong          [e-mail]
Tony Ballardie           [e-mail]
William Barns            [e-mail]
Stephen Batsell          [e-mail]
Jim Beers                [e-mail]
Ute Bormann              [e-mail]
Joesph Burrescia         [e-mail]
Ken Carlberg             [e-mail]
Stephen Casner           [e-mail]
Luo-Jen Chiang           [e-mail]
Matt Crawford            [e-mail]
David Crowe              [e-mail]
Deborah Estrin           [e-mail]
Jan Eveleth              [e-mail]
Dino Farinacci           [e-mail]
William Fenner           [e-mail]
William Fink             [e-mail]
Paul Francis             [e-mail]
Steve Fulling            [e-mail]
Ramesh Govindan          [e-mail]
Susan Hares              [e-mail]
Eric Hoffman             [e-mail]
Ronald Jacoby            [e-mail]
Robert Kummerfeld        [e-mail]
Fong-Ching Liaw          [e-mail]
Cheryl Madson            [e-mail]
David Marlow             [e-mail]
David Meyer              [e-mail]
Gilles-Andre Morin       [e-mail]
Peder Chr.  Noergaard    [e-mail]
Erik Nordmark            [e-mail]
Rex Pugh                 [e-mail]
Benny Rodrig             [e-mail]
Allyn Romanow            [e-mail]
Katsuhiro Sebayashi      [e-mail]
John Stewart             [e-mail]
Peter Sylvester          [e-mail]
Fumio Teraoka            [e-mail]
Dan Wood                 [e-mail]
Mary Jo Zukoski          [e-mail]