draft-ietf-mpls-multicast-06.txt		draft-ietf-mpls-multicast-07.txt
	Network Working Group D. Ooms, B. Sales		Network Working Group D. Ooms, B. Sales
	Internet Draft Alcatel		Internet Draft Alcatel
	Expiration Date: May 2002 W. Livens		Expiration Date: July 2002 W. Livens
	Colt Telecom		Colt Telecom
	A. Acharya		A. Acharya
	IBM		IBM
	F. Griffoul		F. Griffoul
	Ulticom		Ulticom
	F. Ansari		F. Ansari
	Bell Labs		Bell Labs
	November 2001		January 2002
	Framework for IP Multicast in MPLS		Framework for IP Multicast in MPLS
	draft-ietf-mpls-multicast-06.txt		draft-ietf-mpls-multicast-07.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 3, line 34		skipping to change at page 3, line 34
	RSVP Resource reSerVation Protocol		RSVP Resource reSerVation Protocol
	SPT-bit Shortest Path Tree [DEER]		SPT-bit Shortest Path Tree [DEER]
	SSM Source Specific Multicast		SSM Source Specific Multicast
	TCP Transmission Control Protocol		TCP Transmission Control Protocol
	UDP User Datagram Protocol		UDP User Datagram Protocol
	VC Virtual Circuit		VC Virtual Circuit
	VCI Virtual Circuit Identifier		VCI Virtual Circuit Identifier
	VP Virtual Path		VP Virtual Path
	VPI Virtual Path Identifier		VPI Virtual Path Identifier
	Changes:
	02->05 (problem in IETF db): incorporate WG last call comments
	05->06: no changes
	1. Introduction		1. Introduction
	In an MPLS cloud the routes are determined by a L3 routing protocol.		In an MPLS cloud the routes are determined by a L3 routing protocol.
	These routes can then be mapped onto L2 paths to enhance network		These routes can then be mapped onto L2 paths to enhance network
	performance. Besides this, MPLS offers a vehicle for enhanced		performance. Besides this, MPLS offers a vehicle for enhanced
	network services such as QoS/CoS, traffic engineering, etc.		network services such as QoS/CoS, traffic engineering, etc.
	Current unicast routing protocols generate a same (optimal) shortest		Current unicast routing protocols generate a same (optimal) shortest
	path in steady state for a certain (source, destination)-pair. Remark		path in steady state for a certain (source, destination)-pair. Remark
	that unicast protocols can behave slightly different with regard to		that unicast protocols can behave slightly different with regard to
	skipping to change at page 11, line 42		skipping to change at page 11, line 29
	goes around a loop, copies of the packet may be emitted from the loop		goes around a loop, copies of the packet may be emitted from the loop
	if branches exist in the loop.		if branches exist in the loop.
	Currently loop detection is a configurable option in LDP and a		Currently loop detection is a configurable option in LDP and a
	decision on the mechanism for loop prevention is postponed.		decision on the mechanism for loop prevention is postponed.
	3.8. Mapping of characteristics on existing protocols		3.8. Mapping of characteristics on existing protocols
	The above characteristics are summarized in Table 1 for a non-		The above characteristics are summarized in Table 1 for a non-
	exhaustive list of existing IP multicast routing protocols: DVMRP		exhaustive list of existing IP multicast routing protocols: DVMRP
	[PUSA], MOSPF [MOY], CBT [BALL], PIM-DM [DEER], PIM-SM [DEE2], SSM		[PUSA], MOSPF [MOY], CBT [BALL], PIM-DM [ADAM], PIM-SM [DEER], SSM
	[HOLB], SM [PERL].		[HOLB], SM [PERL].
	+------------------+------+------+------+------+------+------+------+		+------------------+------+------+------+------+------+------+------+
	| |DVMRP |MOSPF |CBT |PIM-DM|PIM-SM|SSM |SM |		| |DVMRP |MOSPF |CBT |PIM-DM|PIM-SM|SSM |SM |
	+------------------+------+------+------+------+------+------+------+		+------------------+------+------+------+------+------+------+------+
	|Aggregation |no |no |no |no |no |no |no |		|Aggregation |no |no |no |no |no |no |no |
	+------------------+------+------+------+------+------+------+------+		+------------------+------+------+------+------+------+------+------+
	|Flood & Prune |yes |no |no |yes |no |no |option|		|Flood & Prune |yes |no |no |yes |no |no |option|
	+------------------+------+------+------+------+------+------+------+		+------------------+------+------+------+------+------+------+------+
	|Tree Type |source|source|shared|source|both |source|shared|		|Tree Type |source|source|shared|source|both |source|shared|
	skipping to change at page 26, line 19		skipping to change at page 25, line 47
	Implicit label distribution is not applicable if the FEC-to-label		Implicit label distribution is not applicable if the FEC-to-label
	binding has been advertised prior to traffic arrival, e.g. explicit		binding has been advertised prior to traffic arrival, e.g. explicit
	routing (i.e. if all the information necessary to identify the FEC is		routing (i.e. if all the information necessary to identify the FEC is
	not present in the packet).		not present in the packet).
	Explicit distribution allows pre-establishment (before the arrival of		Explicit distribution allows pre-establishment (before the arrival of
	data) of LSPs with topology or request driven triggers.		data) of LSPs with topology or request driven triggers.
	11. Security Considerations		11. Security Considerations
	This document raises no security issues.		In general, the use of multicast in an mpls environment poses no
			extra security issues beyond the ones that already exist in multicast
			and mpls protocols as such.
			The protocols described in this document are however not suited to
			cross administrative boundaries.
			When the multicast tree is determined by an existing multicast
			routing protocol (this is the assumption made in this document,
			except for the Explict Routing section), clearly no additional
			security issues are introduced w.r.t. the shape of the tree (e.g.
			unauthorized joining, tapping, blackholing, injecting traffic, ...).
			These security issues should have been addressed in the
			specifications of the multicast routing protocols.
			In the MPLS context it is possible that control messages trigger L2
			resource allocations (e.g. LSPs). If security flaws would still be
			present in the existing protocols (which possibly are not too harmful
			in its original context) the abusive sending of such control messages
			can yield more severe DoS attacks.
			In case of an "explicit routed" tree that is calculated centrally,
			sufficient authentication must be done on the control messages that
			set up the tree in the network nodes.
	12. Acknowledgements		12. Acknowledgements
	The authors would like to thank Eric Rosen, Piet Van Mieghem, Philip		The authors would like to thank Eric Rosen, Piet Van Mieghem, Philip
	Dumortier, Hans De Neve, Jan Vanhoutte, Alex Mondrus and Gerard		Dumortier, Hans De Neve, Jan Vanhoutte, Alex Mondrus and Gerard
	Gastaud for the fruitful discussions and/or their thorough revision		Gastaud for the fruitful discussions and/or their thorough revision
	of this document.		of this document.
	References		Normative References
			Since this is an informational framework document (describing possible
			solutions, without selecting a particular one), there are no normative
			references.
			Informative References
	[ACHA] A. Acharya, R. Dighe and F. Ansari, "IP Switching Over Fast ATM		[ACHA] A. Acharya, R. Dighe and F. Ansari, "IP Switching Over Fast ATM
	Cell Transport (IPSOFACTO) : Switching Multicast flows", IEEE		Cell Transport (IPSOFACTO) : Switching Multicast flows", IEEE
	Globecom '97.		Globecom '97.
	[AWDU] D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow and V. Sriniva-		[ADAM] A. Adams, J. Nicholas, W. Siadak, Protocol Independent Multicast
	san, "Extensions to RSVP for LSP Tunnels", Work In Progress		Version 2 Dense Mode Specification", Work In Progress.
	[ANDE] L. Andersson, P. Doolan, N. Feldman, A. Fredette and R. Thomas,		[ANDE] L. Andersson, P. Doolan, N. Feldman, A. Fredette and R. Thomas,
	"LDP specification", RFC3036, January 2001.		"LDP specification", RFC3036, January 2001.
			[AWDU] D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow and V. Sriniva-
			san, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC3209,
			December 2001
	[BALL] A. Ballardie, "Core Based Trees (CBT) Multicast Routing Archi-		[BALL] A. Ballardie, "Core Based Trees (CBT) Multicast Routing Archi-
	tecture", RFC2201, September 1997.		tecture", RFC2201, September 1997.
	[CONT] A. Conta, P. Doolan, A. Malis, "Use of Label Switching on Frame		[CONT] A. Conta, P. Doolan, A. Malis, "Use of Label Switching on Frame
	Relay Networks", RFC3034, January 2001.		Relay Networks", RFC3034, January 2001.
	[CRAW] E. Crawley, Editor, L. Berger, S. Berson, F. Baker, M. Borden		[CRAW] E. Crawley, Editor, L. Berger, S. Berson, F. Baker, M. Borden
	and J. Krawczyk, "A Framework for Integrated Services and RSVP		and J. Krawczyk, "A Framework for Integrated Services and RSVP
	over ATM", RFC2382, August 1998.		over ATM", RFC2382, August 1998.
	[DAVI] B. Davie, J. Lawrence, K. McCloghrie, Y. Rekhter, E. Rosen, G.		[DAVI] B. Davie, J. Lawrence, K. McCloghrie, Y. Rekhter, E. Rosen, G.
	Swallow and P. Doolan, "MPLS using LDP and ATM VC switching",		Swallow and P. Doolan, "MPLS using LDP and ATM VC switching",
	RFC3035, January 2001.		RFC3035, January 2001.
	[DEER] S. Deering, D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S.		[DEER] S. Deering, D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S.
	Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma and L Wei,		Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma and L Wei,
	"Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol		"Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
	Specification", RFC 2117, June 1997.		Specification", RFC 2117, June 1997.
	[DEE2] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, Protocol		[FARI] D. Farinacci, Y. Rekhter, E. Rosen and T. Qian, "Using PIM to
	Independent Multicast Version 2 Dense Mode Specification", Work		Distribute MPLS Labels for Multicast Routes", Work In Progress.
	In Progress.
	[FARI] D. Farinacci, Y. Rekhter and E. Rosen, "Using PIM to Distribute
	MPLS Labels for Multicast Routes", Work In Progress.
	[FENN] W. Fenner, "Internet Group Management Protocol, IGMP, version		[FENN] W. Fenner, "Internet Group Management Protocol, IGMP, version
	2", RFC 2236, November 1997.		2", RFC 2236, November 1997.
	[GARR] M. Garrett and M. Borden, "Interoperation of Controlled-Load		[GARR] M. Garrett and M. Borden, "Interoperation of Controlled-Load
	Service and Guaranteed Service with ATM", RFC2381, August 1998.		Service and Guaranteed Service with ATM", RFC2381, August 1998.
	[HOLB] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", Work		[HOLB] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", Work
	In Progress.		In Progress.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/