Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/idmr/idmr-minutes-95dec.txt

Text File | 1996-06-03 | 13KB | 256 lines

CURRENT MEETING REPORT


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

Reported by Bill Fenner, Xerox PARC and Tony Ballardie, University
College London


First Session

Deborah Estrin spoke first about interoperability mechanisms between
PIM sparse mode and a multicast backbone, whether it be level two or
current DVMRP.  All groups use local RP's, and the border routers join
towards the local RPs in order to inject traffic into the backbone.  A
single designated border router registers externally-sourced packets to
the internal RP.  Internal RPs advertise themselves on a special
bootstrap group whose RP is elected via PIM Query messages.  Open
issues here include whether to explicitly notify the designated border
router of group memberships inside the domain or to do "flood and
prune," and how to use a domain of this type for transit traffic.

Deborah then spoke about how to connect such domains with a PIM-SM
backbone.  The changes in this case are limited to the local RPs.  When
there is a PIM-SM backbone, there is a hierarchy of RPs; it is not yet
clear if two levels of hierarchy are enough or if we need more.  Join
messages are modified to include a hierarchy level and crossing tree
branches are handled by having the highest level branch "win."  If a
level one Join message meets a level 2 tree branch, it doesn't change the
incoming interface.  The local RPs join to the next level RPs.  Candidate
RP lists are distributed using the same bootstrap mechanism as in the
local domain.

Mark Handley then spoke about Hierarchical PIM, or HPIM.  HPIM is
similar to Deborah's scheme (and Deborah's scheme was derived from
Mark's proposal), but Mark expects HPIM to have five to six levels of
hierarchy.  Each RP knows its own level and knows the candidate RP
list for the next level up.  The group address can be hashed into the list
of RP's to determine the RP for that group.  This gets rid of the
requirement of storing RP/group mappings.  The candidate-RP list is not
meant to change often, but when it does, the old RP joins to the new RP
to keep the tree intact and initiates transfers of its receivers to the new
RP.

HPIM also makes the following "gratuitous" changes to PIM, which are
not directly related to the hierarchy of RPs.  Join messages establish bi-
directional forwarding state, not unidirectional, and they get ACK'd.
RP failure is determined by timeouts and is handled by using an
alternate hash function to determine a fallback RP.  If there are local
receivers to a domain, a sender in the same domain uses their (bi-
directional) state; if not then it sends a "sender join" hop-by-hop
towards the RP until it hits the tree; "sender join" state is
unidirectional.  The loop avoidance mechanism can result in
unnecessary traffic flow but is relatively simple.

Outstanding issues include that there is potentially too much
configuration of the hierarchy and RPs; however, there may be a way
to automatically configure such things.  The hash function can lead to a
sub-optimal top level RP, but since tree links are bidirectional you can
potentially prune off the top-level RP.  More thinking needs to be done
on the topics of changing RP's dynamically based on traffic load, and on
RP selection algorithms.

The second half of the meeting was on providers' experiences with
deploying PIM in their networks.  First, Matt Crawford from Fermilab
spoke about his experiences with PIM and High Energy Physics.  HEP
generally has large collaborations, and these collaborations meet
several times per week using multicast conferencing tools.  In addition,
there are accelerator controllers which can multicast their readings,
allowing multiple users to see results at once.

Matt said that he liked PIM because all he had to do was turn it on in
his routers and it "just worked," and because he owns many routers but
few workstations.  Steve Deering stood up and commented that Matt
would probably have the same experience with any multicast routing
protocol implemented in a router, and that the choice of PIM was
simply predicated by the brand of router.  Matt more or less agreed.

Petri Helenius from Santa Monica Software spoke about MBONE
deployment in Finland.  PIM Dense Mode is deployed throughout
Finland, and DVMRP pruning is implemented at DVMRP
interoperability points, meaning that multicast should prune all the
way back to Sweden.  The emphasis was again that they had country-
wide multicast reachability without requiring "kernel hackers" at
each site.

The issues that Petri brought up included that PIM-DM is wasteful on
state on sparse-membership groups, NBMA issues have not yet been
resolved, and the need for configuration guidelines for DVMRP
interoperation and for suggested topologies.

David Meyer from University of Oregon then spoke about having a
multi-homed campus.  He wanted to have ubiquitous multicast
integrated with the existing infrastructure, as well as redundant
external connectivity and integration, with Internet service providers.
His network uses sparse mode PIM, but has the problem that his unicast
topology is too rich, and PIM can't (yet?) RPF over a multipath link, so
even if he has multiple T1's between two sites he can only use one.  He
glues sparse mode domains together with dense mode domains to work
around policy and RP placement issues.  He is providing multicast to 200
subnets, and it is nearly ubiquitous in his network.


Second Session

Day two began with a presentation on multicast traceroute, released
recently as an IDMR Internet-Draft.  All MBONE users were strongly
encouraged to implement mtrace since it makes debugging problems so
much easier. Currently, it is estimated 58% of the MBONE implements
'mtrace.'

'mtrace' has been designed to operate with the assumption that the
underlying multicast routing protocol is based on RPF.  Hence, a call was
made to the designers of shared tree protocols (CBT, PIM-SM) for
feedback on whether/how 'mtrace' can work with shared trees.

A call was made requesting that IGMPv2 be moved forward to proposed
standard. There were no objections. However, it is currently unclear
whether this will actually move forward to proposed standard, or be
published as an informational RFC. The Routing Area Director should
decide on the best course of action, given that the group voiced no
objections regarding its standardization.

A CBT protocol update was given. The protocol has been considerably
streamlined since the previous draft release (June 1995).  A new draft
indicating the very latest proposed changes should be submitted within
the next week. At this stage, the CBT designers consider the protocol to
remain stable (as far as the functional spec is concerned). However, it
remains to be fully specified how CBT interoperates with DVMRP (and
other protocols for that matter).  The CBT designers are working on this
and expect to announce an interoperability document shortly.

The following is a summary of the CBT protocol updates:

o  Multi-access LAN designated router (DR) election has been re-
invented.  The CBT default DR is the same router as the IGMP
querier. Hence, no protocol is required for CBT DR election.

This assumes that any CBT-capable subnetwork has only the CBT
multicast protocol running over it. If this assumption is not made, then
the IGMP querier could be a multicast router of another scheme. For this
scenario, interoperability between CBT and all other protocols needs to
be defined. The working group is currently trying to establish a
protocol-independent mechanism for interoperability to avoid each
protocol having to define interoperability mechanisms between each
other protocol.  For the moment then, it is safe to assume that any one
subnetwork is running only a single multicast routing protocol.

o  The core tree (the part of the CBT tree linking all cores together) is
now built "on-demand."  This requires that all group members and
potential new members to agree on the identity of only the
primary core router. The primary core, together with a list of
alternate (secondary) cores is distributed throughout the network
by some T.B.D. mechanism (e.g. hpim, <core,grp> advertisements,
etc.).

The on-demand core tree building works as follows: any secondary core
that receives a join, first acks the join, then sends a join-request, code
rejoin, to the primary core so the tree becomes fully connected.  The
primary core only ever listens for incoming joins; it never need join any
entity itself.

o  Native mode.

This assumes CBT routers operate in a CBT-only "cloud", i.e.
multicast routers of other schemes are not active within the same
cloud. This allows for much faster packet switching times, also
helped by the fact that no RPF check is necessary.

o  Maintenance message "aggregates."

Rather than have a CBT-ECHO-REQUEST/REPLY sent for each
child/parent on a per group basis, the protocol now aggregates
these messages so that only a single request/response pair is sent
for any child-parent pair. This is especially attractive in those
parts of the network where links are likely to be shared across
groups. Considerable bandwidth savings are possible with this
mechanism.

o  Rejoins and loop-detection.

The dual mechanisms of rejoining and loop detection has been
made simpler and more straightforward.  The new scheme means
that a rejoining node first receives an ack before it (rather than
the node sending the ack) generates a rejoin-nactive (loop
detection packet). This new technique avoids the router sending
the ack performing any packet 'translation'.

o  Proxy-ack.

Although discussed in the draft (spec) released immediately prior
to IDMR Dallas, it was discussed in a meeting of the CBT
designers immediately prior to the IDMR meetings, and decided
that there was a case where proxy-acks should not be used.  They
are no longer present in the protocol.

Overall, the CBT protocol has been streamlined considerably.  There
are now far fewer control messages, resulting in a further simplified
protocol engine.  An aggregated join mechanism is currently being
worked through such that, subsequent to a router/link failure, groups
with overlapping core(s) can send a single 'aggregated' join to re-
establish connectivity, rather than have each group generate a join
individually.

One approach to how multi-protocol interoperability can be achieved
at the L1/L2 hierarchical boundary was presented. The technique
involves a L2 encapsulation, but does not require any exchange of routing
information between L1 and L2.  This contributes significantly to the
simplicity of the approach. However, ideally, it is considered very
desirable to have an L1/L2 interface that requires no encapsulation,
and therefore the group is rethinking it╒s (previously announced)
approach to hierarchical multicast. Nevertheless, the encapsulation
approach will be released as an IDMR Internet-Draft.

Finally, a pragmatic approach to bi-level multicast in the DIS
environment was presented. This work has been conducted at BBN under
ARPA's "Real-time Information Transfer and Networking" program in
support of distributed simulation.

DIS applications are not like teleconferencing applications; DIS
assumes very large numbers of groups (10^4 or more), and requires very
low join latency (< 0.5 secs or less).

The bi-level environment consists of a "constructed multicast service
(CMS)" built on top of an "underlying multicast service (UMS)."  The
CMS provides control traffic which is data to the UMS. Bi-level
routers peer directly with each other. Bi-level routers (BLRs) use IGMP
to determine CMS groups. This state is sent to all other BLRs so each
BLR knows where group members are located. UMS groups are used to
distribute data for CMS groups-BLRs join both UMS groups and CMS
groups.

The communication between BLRs about BLR group memberships needs
to have a high degree of reliability. Joins/leaves use sequence
numbering and timestamps. Each BLR sends MD5 hash messages to
upstream neighbour summarizing its current state. Rather than "hard
state" or "soft state", the state is said to be "firm"; it is like soft-state
in that it is sent periodically; it is like hard state in that deltas are
sent.  However, unlike soft state, the information sent is a
cryptographically strong checksum of the desired state, rather than
the entire state.

A bi-level multicast prototype has been implemented and tested.  The
UMS was provided by Bay Networks routers using DVMRP connected by
ATM, linking six sites in the DC area. A simulation exercise was
carried out using ca. 700 multicast groups. Some sites had 2000 join
events over ca. 30 mins, which averages out at about one join per second.

Official documentation from BBN ([e-mail]) should be
forthcoming  shortly, describing the concepts and protocol of bi-level
multicasting in detail.

Once again, the DIS demonstrated the reality of the need for a  next-
generation multicast protocol that can better support its requirements.