[These minutes were compiled by Tony Ballardie]

The IDMR working group met during one 2-hour session in Orlando.

Joel Halpern presented the motivation behind Simple Multicast (SM),
a relatively new inter-domain multicast proposal. The basic
premise was that we should be prepared step back and re-evaluate
some of the design decisions made during the days of PIM and
CBT development to see if some of the design constraints which 
we then saw as unsurmountable or invalid can be made acceptable, 
particularly if the end-result will/might be better. 

It is widely acknowledged that bi-directional shared trees scale 
best overall for Internet-wide multicasting. For single-source type 
distribution shared trees can be used by placing the core at the 
source, thus emulating a source tree, both in terms of its delay 
properties and robustness. Whilst bi-directional shared trees incur 
the least state overhead for Internet-wide multicasting, they are
not necessarily suited to all applications, motivating the requirement 
to remain flexible in supporting different distribution models.

One of the above-mentioned constraints relates to the host service 
model (the nature of the host's involvement in joining a group); 
there was, and remains, fairly strong resistance to change 
this model - particularly in view of the need to continue supporting 
different/existing distribution models (tree types). SM need not 
involve changes to the host service model, but SM would probably 
involve changing the host API (which is needed by BGMP/MASC too);
these changes comprise the host passing a group's core as well
as class-D address across the API, both of which are discovered
by a means orthogonal to the SM protocol. Both the core and
group form an 8-byte group-identifier which must be carried
in data packets - the question is how best to do this?
Essentially there are two possibilities: use an IP option
(this seemed to be the least favoured approach because of
it's potential impact on forwarding performance); or carry
the information in its own "shim" header immediately behind
the IP header. This was the approach that seems more favourable. 
This method allows for the carrying of additional semantic 
information - for example, a single bit can indicate whether 
a packet's TTL is expected reach zero; if it does, it's most 
likely a looped packet and action can then be taken to remove
the loop from the tree.

The proposed transition plan was discussed. The "shim" header
on control packets (joins, acks etc.) need and must only be 
processed by SM-capable routers, giving rise to an auto-tunnelling 
capability. Data packets, whilst carrying the "shim" header 
containing <class-D, core>, are IP source addressed by the traffic 
originating host, and IP destination addressed to the core, though 
when they hit a SM router whose adjacent next-hop is not SM-capable, 
the router translates the IP dest address to the next-SM-capable 
hop. A comment was made that this might not be a good idea because 
it doesn't allow the remote tunnel end-point to verify where the 
traffic entered the tunnel, as is possible with encapsulated 
(IP-in-IP) tunnels. A comment was also made suggesting that making 
the deployment of tunnels "easy" was not a good idea because the 
goal of multicast vendors is to get rid of tunnels. 

Other comments included:

        - non-member senders don't join a tree, and so
          do not receive on-tree "heartbeats" which
          filter down  from the core, so they have no
          idea if the core is alive before sending.

        - implications of changing the IP multicast API,
          which requires host changes. 

        - will debugging/diagnosing problems be harder
          given that the group-id is now at a higher layer?
          Most of the current diagnostic tools would probably
          need some minor mods to accommodate SM.

Graeme Brown (BT Labs, UK) gave a presentation detailing
the implementation and testing experience with CBT on
the FreeBSD platform. The implementation is publicly 
available from ftp://ftp.labs.bt.com/Internet-Research/
Various test scenarios were illustrated, including
fail-over tests, all of which have proven successful.
The BT  Labs CBT network has been successfully connected to
the MBONE (as a stub domain) via their PIM connection to the 
MBONE. This is achieved by having the CBT core(s) act as a 
host on its interface to PIM - IGMP group membership report(s) 
pull the data for the relevant group(s) to the core for 
distribution on the CBT tree(s). 

Some of BT's future CBT work items were outlined - these
include continued expansion of the network, inclusion of
SNMP, a v6 implementation, and a PIM/DVMRP/CBT Border
Router (in a single box).

Mark Handley gave a brief status report on BGMP work
in the absence of Rusty Eddy (ISI). He noted that the
implementation work is progressing according to plan,
but did not give an indication as to when it might be
available. Mark solicited input from the community re.
inter-domain multicast issues, particularly from ISPs.

Manolo Sola presented Static Multicast. This scheme
involves reserving a portion of the Class-D address
space (e.g. 225.0.0.0/8) for so-called "static allocation".
This scheme involves the use of DNS to map a group
name (URL), discovered arbitrarily, to a group address
and any other relevant group parameters such as
RP/Core(s). For address allocation, the scheme correlates 
a domain's unicast prefix (e.g. 131.112/16) with the
static multicast prefix, so in the above example the
domain would be allocated 225.131.112/24. As such it
is possible to derive which (unicast) domain is using which 
multicast prefix. 

With regards to interconnecting domain-local trees to
an inter-domain tree, the BR/Core/RP in a domain queries
DNS to discover other BR/Core/RPs. An explicit join is
then sent to the nearest (according to unicast routing)
peer BR/Core/RP. 

Comments about this scheme included: 

        - there is a high cost in creating many small
          teleconference-type groups (impact on DNS,
          unclear which user and/or computer interactions
          are involved) 

        - it's unclear whether inter-domain joins will
          always converge on a single RP (potential for
          loops).