Subject: Internet Multicast Documentation, Oversight, and Coordination (IMDOC)?

From: David Meyer <[email-masked]>
Date: Thu, 10 Jul 2003 07:56:12 -0700

Here's something I've been discussing with the ADs
	(and hoping to learn the lessons of the MADDOGs
	"experience").  

	I put it on the mboned agenda, so we can also discuss this
	there. As always, comments greatly appreciated.

	Dave

---

        This note proposes the creation the Internet Multicast
	Documentation, Oversight, and Coordination (IMDOC)
	function. The IMDOC, residing in mboned, will serve as
	the locus of documentation, cross-coordination, and
	oversight function for the muticast activity in the IETF
	at large, and will create two crucial missing pieces of
	the multicast puzzle: (i). A comprehensive IETF multicast
	framework document, and (ii). the Internet Multicast
	Reference Architecture (IMRA). Both are discussed briefly
	below.

	IMDOC documents will be published in the mboned working
	group and will:

	(i).	Provide a comprehensive framework document. This
		document will cover all multicast issues under
		consideration within IETF, and will provide a
		systematic way determining when new working
		groups are needed. 

	(ii).	Provide the Internet Multicast Reference
		Architecture document. Importantly, the IMRA will
		cover both intra and inter-domain multicast
		architectures.  

	(iii).	Outline domain-specific problem spaces (for
		example, as was done in mboned with
		draft-ietf-mboned-imrp-some-issues-01.txt).   

        (iv).	Preserve the archival knowledge of what has
		worked and what hasn't, and why. This knowledge
		is currently folklore (or very ad hoc at best).   
 
	The IMDOC coordination and oversight functions will be
	organized by the mboned working group in conjunction with
	the appropriate working group chairs and area directors.

	The following list of areas (which are in scope for the
	IMDOC) is not intended to exhaustive, but rather to
	illustrate the requirement for oversight and
	coordination:   

	(i).	Addressing

		Including dynamic address assignment (malloc,
		etc), IANA issues (IPv4 and IPv6, e.g. RFC
		3171/BCP51), scoping mechanisms and
		methodologies, multicast address derivation
		(e.g. RFCs 2770 and 3138) and Unicast Based
		Addresses (IPv6).    

	(ii).	Source discovery

		Including in-band source discovery methods such as
		BSR (which touches pim) and embedded RP (which
		touches ipv6)), and out-of-band mechanisms such
		as proposed for SSM (which touches ssm), and
		their associated applications and APIs (which
		touches mmusic). Examples of documents in this
		area include RFC 3569.

	(iii).	Security    

		Including key exchange (which touches msec), and
		data encryption (which touches ipsec), as well as
		the general problem of a security architecture
		for multicast.

	(iv).	L2 aliasing

		For example, 802.x (which touches ipoib and
		others), IGMP/MLD Snooping, CGMP, PIM Snooping,
		and RGMP (which touches on MAGMA).

	(v).	Routing

                For example, BGP4+ and associated extensions
		which effect multicast, Multi-Topology IGPs. 

	(vi).	Forwarding

		Including discussions on all PIM forwarding
		modes, DVMPR, CBT, etc.  Also includes issues
		associated with RP mapping approached for PIM-SM,
		and general discussions on ASM vs. SSM models
		(covering bidirectional and unidirectional status
		as well)

	(vii).	Reliable Transport

		Including discussions on RMT generated building
		blocks as well as issues associated with
		PGM. Covers FEC, CC, etc. 

	(viii).	Session Control

		Will include issues associated with source and
		receiver control, example MSNIP, RTS/CTS issues,
		floor-control, etc.

	(ix).	Application Layer Issues

		Examples include BCPs for writing multicast
		applications (e.g. RFC 3170), discussions on
		default address use, traffic patterns (example
		implications of bursty traffic, low frequency
		traffic), and APIs for SSM.

	(x).	Tunneling
		
		Including any potential new dynamic tunneling
		proposals which come from Last Mile Multicast, etc.

	(xi).	VPN
		
		Both L2 (pwe3, l2vpn), and L3 (ppvpn, l3vpn)

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: "Seok Joo Koh" <[email-masked]>
Date: Fri, 11 Jul 2003 01:26:47 +0900

Dave,

Sounds great and a brief question below.

> proposals which come from Last Mile Multicast, etc.

Don't we need to include Overlay Multicast (or Application-Level Multicast)
as an example ?
I think it could be considered as an enhancement of the traditional IP
multicast model, and
it may also address the tunneling issue described above.

Overlay multicast may be considered as an inter-domain multicast scheme, in
which
each domain uses ASM or SSM, and the unicast (tunnelled or not) will be used
between different domains.
In overlay multicast model, the control (or signaling) messages will be
based on the UDP/TCP transport.

Thanks,

Seok J. Koh

---

From: "Seok Joo Koh" <[email-masked]>
Date: Fri, 11 Jul 2003 01:26:47 +0900

Dave,

Thanks,

Seok J. Koh

---

From: Dave Price <[email-masked]>
Date: Thu, 10 Jul 2003 16:26:30 +0100

Dear All,

> 	there. As always, comments greatly appreciated. 

excellent. I'll not be at the meeting, but this proposal
strikes me as a really good idea.

Dave Price
-- 
Dave Price, Technical Director, Telematics Group
Email: [email-masked] PHONE: +44 1970 622428 FAX: +44 1970 622455
Post: Computer Science, University of Wales,
      Penglais, Aberystwyth, WALES, UK, SY23 3DB.

---

From: Dave Price <[email-masked]>
Date: Thu, 10 Jul 2003 16:26:30 +0100

Dear All,

Dave Price

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 10 Jul 2003 15:19:31 -0400

Dave,

I think you've got a great list of multicast issues and mboned would
be a good place to continue with this.  My first reaction was that
this may be too complete a list and you should concentrate on the
subset of the items that are deemed most important to or considered
barriers to further multicast deployment.

On the original topic of multicast deployment, there were some
assertions that there is financial disincentives for a tier-1 to
deploy multicast.  I have a few comments on that.  First, if multicast
is not offerred and it happens anyway through unicast replication,
then adding multicast does remove a burden from the core.  If
replication is distributed anyway and not laid out according to
topology (p2p stuff, for example), then the savings is greater.  OTOH
if some sort of service is essentially broadcast as multiple unicast
and is huge in volume, lack of multicast provides a visible revenue
source for the provider, the fat pipe to the source.  It was this
(possibly flawed) logic that has motivated some commercial multicast
service where only select participants could be senders and charges
for this priviledge were quite high (high enough in the one case I
have in mind that service penetration was minimal).  Somewhere in the
middle is the multiparty conference, with more than two or three but
no more than a dozen or so participants.  Unicast replication at a
single site can be viable for a small number of satelite sites, but
for larger conferences can become infeasible.  It is these many
smaller scale multicast groups that it would be good to provide on the
same flat rate basis as today's unicast, while avoiding carrying large
scale broadcasts for free.

The topic of counting leaf nodes came up.  For a tier-1 provider, it
is sufficient and perhaps more relevant to know only the number of
exit points from that provider that a sender is reaching.  How much
branching occurs beyond the tier-1 provider is inconsequential to the
tier-1 provider.  The good news is that collection this information is
something that can be confined to the single provider if protocol
support existed to do so.  From the provider's business standpoint, it
may be sufficient to limit bandwidth and this bounds (number of exit
points to the provider) for lower service levels including any default
(comes without charge or a fixed extra) flat rate service and offer a
higher service level in which the sender bandwidth and exit point
count limits are set higher.  This would allow flat rate low usage
multicast such as small conferencing but still provide the means to
generate revenues appropriate to higher bandwidth and wider spread
multicast, such as VOD.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 10 Jul 2003 15:19:31 -0400

Dave,

Curtis