draft-ietf-mpls-multicast-04.txt		draft-ietf-mpls-multicast-05.txt
	Network Working Group D. Ooms, B. Sales		Network Working Group D. Ooms, B. Sales
	Internet Draft Alcatel		Internet Draft Alcatel
	Expiration Date: June 2001 W. Livens		Expiration Date: July 2001 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
	December 2000		January 2001
	Framework for IP Multicast in MPLS		Framework for IP Multicast in MPLS
	draft-ietf-mpls-multicast-04.txt		draft-ietf-mpls-multicast-05.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 2, line 17		skipping to change at page 2, line 17
	1. Introduction		1. Introduction
	2. Layer 2 characteristics		2. Layer 2 characteristics
	3. Taxonomy of IP multicast routing protocols in the context of MPLS		3. Taxonomy of IP multicast routing protocols in the context of MPLS
	3.1. Aggregation		3.1. Aggregation
	3.2. Flood & Prune		3.2. Flood & Prune
	3.3. Source/Shared trees		3.3. Source/Shared trees
	3.4. Co-existence of Source and Shared Trees		3.4. Co-existence of Source and Shared Trees
	3.5. Uni/Bi-directional Shared Trees		3.5. Uni/Bi-directional Shared Trees
	3.6. Encapsulated multicast data		3.6. Encapsulated multicast data
	3.7. Loop-free-ness		3.7. Loop-free-ness
	3.8. RPF Check		3.8. Mapping of characteristics on existing protocols
	3.9. Mapping of characteristics on existing protocols
	4. Mixed L2/L3 forwarding in a single node		4. Mixed L2/L3 forwarding in a single node
	5. Taxonomy of IP multicast LSP triggers		5. Taxonomy of IP multicast LSP triggers
	5.1. Request driven		5.1. Request driven
	5.1.1. General		5.1.1. General
	5.1.2. Multicast routing messages		5.1.2. Multicast routing messages
	5.1.3. Resource reservation messages		5.1.3. Resource reservation messages
	5.2. Topology driven		5.2. Topology driven
	5.3. Traffic driven		5.3. Traffic driven
	5.3.1. General		5.3.1. General
	5.3.2. An implementation example		5.3.2. An implementation example
	skipping to change at page 3, line 24		skipping to change at page 3, line 23
	LSR Label Switching Router		LSR Label Switching Router
	LSRd Downstream LSR		LSRd Downstream LSR
	LSRu Upstream LSR		LSRu Upstream LSR
	MOSPF Multicast OSPF		MOSPF Multicast OSPF
	mp2mp multipoint-to-multipoint		mp2mp multipoint-to-multipoint
	p2mp point-to-multipoint		p2mp point-to-multipoint
	PIM-DM Protocol Independent Multicast-Dense Mode		PIM-DM Protocol Independent Multicast-Dense Mode
	PIM-SM Protocol Independent Multicast-Sparse Mode		PIM-SM Protocol Independent Multicast-Sparse Mode
	QoS Quality of Service		QoS Quality of Service
	RP Rendezvous Point		RP Rendezvous Point
	RPF Reverse Path Forwarding		RPT-bit RP Tree bit [DEER]
	RSVP Resource reSerVation Protocol		RSVP Resource reSerVation Protocol
			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 - clean up references - changes to section of Explicit
	Routing - added SSM to multicast protocol taxonomy
	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 5, line 17		skipping to change at page 5, line 15
	Following characteristics are considered:		Following characteristics are considered:
	- Aggregation		- Aggregation
	- Flood & Prune		- Flood & Prune
	- Source/Shared trees		- Source/Shared trees
	- Co-existence of Source and Shared Trees		- Co-existence of Source and Shared Trees
	- Uni/Bi-directional shared trees		- Uni/Bi-directional shared trees
	- Encapsulated multicast data		- Encapsulated multicast data
	- Loop-free-ness		- Loop-free-ness
	- RPF check
	The discussion of these characteristics will not lead to the		The discussion of these characteristics will not lead to the
	selection of one superior multicast routing protocol. It is not		selection of one superior multicast routing protocol. It is not
	impossible that different IP multicast routing protocols will be		impossible that different IP multicast routing protocols will be
	deployed in the Internet.		deployed in the Internet.
	3.1. Aggregation		3.1. Aggregation
	In unicast different destination addresses are aggregated to one		In unicast different destination addresses are aggregated to one
	entry in the routing table, yielding one FEC and one LSP.		entry in the routing table, yielding one FEC and one LSP.
	skipping to change at page 11, line 38		skipping to change at page 11, line 25
	Multicast routing protocols which depend on a unicast routing		Multicast routing protocols which depend on a unicast routing
	protocol suffer from the same transient loops as the unicast		protocol suffer from the same transient loops as the unicast
	protocols do, however the effect of loops will be much worse in the		protocols do, however the effect of loops will be much worse in the
	case of multicast. The reason being, each time a multicast packet		case of multicast. The reason being, each time a multicast packet
	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. RPF Check		3.8. Mapping of characteristics on existing protocols
	Some protocols perform a Reverse Path Forwarding (RPF) check on the
	received multicast packets. This mechanism checks whether the packet
	is received on the interface which is on the shortest path to the
	source (or root). This mechanism can introduce problems when
	explicit routing is used (see section 7). Indeed, explicit routing
	can construct a tree yielding another incoming interface than the
	RPF-compatible one.
	3.9. 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 [DEER], PIM-SM [DEE2], 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 |
	+------------------+------+------+------+------+------+------+------+		+------------------+------+------+------+------+------+------+------+
	skipping to change at page 12, line 26		skipping to change at page 12, line 4
	|Tree Type |source|source|shared|source|both |source|shared|		|Tree Type |source|source|shared|source|both |source|shared|
	+------------------+------+------+------+------+------+------+------+		+------------------+------+------+------+------+------+------+------+
	|State Co-existence|no |no |no |no |yes |no |no |		|State Co-existence|no |no |no |no |yes |no |no |
	+------------------+------+------+------+------+------+------+------+		+------------------+------+------+------+------+------+------+------+
	|Uni/Bi-directional|N/A |N/A |bi |N/A |uni |uni |bi |		|Uni/Bi-directional|N/A |N/A |bi |N/A |uni |uni |bi |
	+------------------+------+------+------+------+------+------+------+		+------------------+------+------+------+------+------+------+------+
	|Encapsulation |no |no |yes |no |yes |no |yes |		|Encapsulation |no |no |yes |no |yes |no |yes |
	+------------------+------+------+------+------+------+------+------+		+------------------+------+------+------+------+------+------+------+
	|Loop Free |no |no |no |no |no |no |no |		|Loop Free |no |no |no |no |no |no |no |
	+------------------+------+------+------+------+------+------+------+		+------------------+------+------+------+------+------+------+------+
	|RPF check |yes |yes |no |yes |yes |yes |no |
	+------------------+------+------+------+------+------+------+------+
	Table 1. Taxonomy of IP Multicast Routing Protocols		Table 1. Taxonomy of IP Multicast Routing Protocols
	From Table 1 one can derive e.g. that DVMRP will consume a lot of		From Table 1 one can derive e.g. that DVMRP will consume a lot of
	labels when the Flood & Prune L3 tree is mapped onto a L2 tree.		labels when the Flood & Prune L3 tree is mapped onto a L2 tree.
	Furthermore since DVMRP uses source trees it experiences no merging		Furthermore since DVMRP uses source trees it experiences no merging
	problem when label switching is applied. The table can be		problem when label switching is applied. The table can be
	interpreted in the same way for the other protocols.		interpreted in the same way for the other protocols.
	4. Mixed L2/L3 forwarding in a single node		4. Mixed L2/L3 forwarding in a single node
	skipping to change at page 14, line 6		skipping to change at page 13, line 16
	Table.		Table.
	Although the mixed L2/L3 forwarding requires processing of the		Although the mixed L2/L3 forwarding requires processing of the
	traffic at L3, the load on the L3 forwarding engine is generally less		traffic at L3, the load on the L3 forwarding engine is generally less
	than in a pure L3 node.		than in a pure L3 node.
	Supporting this 'mixed L2/L3 forwarding' feature has following		Supporting this 'mixed L2/L3 forwarding' feature has following
	advantages:		advantages:
	a) Assume LSR A (Figure 8) is an MPLS edge node for the branch		a) Assume LSR A (Figure 8) is an MPLS edge node for the branch
	towards LSR B and an MPLS root node for the branch towards LSR C.		towards LSR B and an MPLS core node for the branch towards LSR C.
	The mixed L2/L3 forwarding allows that the branch towards C is not		The mixed L2/L3 forwarding allows that the branch towards C is not
	disturbed by a return to L3 in LSR A.		disturbed by a return to L3 in LSR A.
	+-------------+		+-------------+
	| MPLS cloud |		| MPLS cloud |
	| N |		| N |
	| / \ |		| / \ |
	| / \ |		| / \ |
	| / \ |		| / \ |
	| A N |		| A N |
	skipping to change at page 20, line 35		skipping to change at page 20, line 18
	Piggybacking is just one possible component of an MPLS multicast		Piggybacking is just one possible component of an MPLS multicast
	solution.		solution.
	7. Explicit routing		7. Explicit routing
	Explicit routing for unicast refers to overriding the unicast routing		Explicit routing for unicast refers to overriding the unicast routing
	table by using LSPs.		table by using LSPs.
	A first way to interpret "multicast explicit routing" is overriding		A first way to interpret "multicast explicit routing" is overriding
	the tree established by the multicast routing protocol by another LSP		the tree established by the multicast routing protocol by another LSP
	tree (e.g. a centrally calculated Steiner tree). In this		tree (e.g. a Steiner tree calculated by an offline tool). In this
	interpretation the current 'shortest path' multicast routing protocol		interpretation the current 'shortest path' multicast routing protocol
	becomes obsolete and can be replaced by label advertisement messages		becomes obsolete and can be replaced by label advertisement messages
	that follow an explicit route which is e.g. calculated by an offline		that follow an explicit route (e.g. a branch of the Steiner tree).
	tool.
	A second way of interpreting "multicast explicit routing" is that		A second way of interpreting "multicast explicit routing" is that the
	multicast routing protocols use the explicit unicast routes to		known multicast routing protocols are running, but that the messages
	construct trees. This approach requires that the RPF check also		generated by these protocols use explicit unicast routes (instead of
	takes the explicit path into account.		the IGP shortest path routes) to construct trees.
	8. QoS/CoS		8. QoS/CoS
	8.1. DiffServ		8.1. DiffServ
	The Differentiated Services approach can be applied to multicast as		The Differentiated Services approach can be applied to multicast as
	well. It introduces finer stream granularities (DiffServ Codepoint		well. It introduces finer stream granularities (DiffServ Codepoint
	(DSCP) as an extra differentiator). A sender can construct one or		(DSCP) as an extra differentiator). A sender can construct one or
	more trees with different DSCPs.		more trees with different DSCPs.
	These (S, G, DSCP) or (*, G, DSCP) trees can be mapped very easily		These (S, G, DSCP) or (*, G, DSCP) trees can be mapped very easily
	onto LSPs when the traffic driven trigger is used. In this case one		onto LSPs when the traffic driven trigger is used. In this case one
	can create LSPs with different attributes for the various DSCPs.		can create LSPs with different attributes for the various DSCPs.
	Note however that these LSPs still use the same route as long as the		Note however that these LSPs still use the same route as long as the
	tree construction mechanism itself does not take the DSCP as an		tree construction mechanism itself does not take the DSCP as an
	skipping to change at page 22, line 13		skipping to change at page 21, line 41
	1) Each LSR on the multi-access link memorizes all the advertised		1) Each LSR on the multi-access link memorizes all the advertised
	labels on the link, even if it has not received a join for the		labels on the link, even if it has not received a join for the
	associated group. If an LSR is added to the multi-access link it has		associated group. If an LSR is added to the multi-access link it has
	to retrieve this information from another LSR on the link or in case		to retrieve this information from another LSR on the link or in case
	of soft state label advertisement it can wait a certain time before		of soft state label advertisement it can wait a certain time before
	it can allocate labels itself. If LSRs allocate a label 'at the same		it can allocate labels itself. If LSRs allocate a label 'at the same
	moment' the LSR with the highest IP address could keep it, while the		moment' the LSR with the highest IP address could keep it, while the
	other LSRs withdraw the label.		other LSRs withdraw the label.
	2) Each LSR gets its own label range to allocate labels from. A		2) Each LSR gets its own label range to allocate labels from. A
	mechanism for label partitioning is described in [FAR2]. If an LSR		mechanism for label partitioning is described in [FARI]. If an LSR
	is added to the multi-access link the label ranges have to be		is added to the multi-access link the label ranges have to be
	negotiated again and possibly existing LSPs are teared down and are		negotiated again and possibly existing LSPs are teared down and are
	reconstructed with other labels.		reconstructed with other labels.
	3) Per multi-access link one LSR could be elected to be responsible		3) Per multi-access link one LSR could be elected to be responsible
	for label allocation. When an LSR needs a label, it can request it		for label allocation. When an LSR needs a label, it can request it
	from this Label Allocation LSR.		from this Label Allocation LSR.
	Unlike the unicast case, a multicast stream can have more than one		Unlike the unicast case, a multicast stream can have more than one
	downstream LSR which all have to use the same label. Two solutions		downstream LSR which all have to use the same label. Two solutions
	skipping to change at page 26, line 38		skipping to change at page 26, line 22
	References		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-		[AWDU] D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow and V. Sriniva-
	san, "Extensions to RSVP for LSP Tunnels", Work In Progress		san, "Extensions to RSVP for LSP Tunnels", 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,
	"Label Distribution Protocol", Work In Progress.		"LDP specification", RFC3036, January 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.
	[CALL] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow and A.
	Viswanathan, "A Framework for Multiprotocol Label Switching",
	Work In Progress.
	[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", Work In Progress.		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 ATM VC switching", Work In		Swallow and P. Doolan, "MPLS using LDP and ATM VC switching",
	Progress.		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		[DEE2] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, Protocol
	Independent Multicast Version 2 Dense Mode Specification", Work		Independent Multicast Version 2 Dense Mode Specification", Work
	In Progress.		In Progress.
	[FARI] D. Farinacci, Y. Rekhter and E. Rosen, "Using PIM to Distribute		[FARI] D. Farinacci, Y. Rekhter and E. Rosen, "Using PIM to Distribute
	MPLS Labels for Multicast Routes", Work In Progress.		MPLS Labels for Multicast Routes", Work In Progress.
	[FAR2] D. Farinacci and Y. Rekhter, "Partitioning Label Space among
	Multicast Routers on a Common Subnet", 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.
	[MOY] J. Moy, "Multicast extensions to OSPF", RFC 1584, March 1994.		[MOY] J. Moy, "Multicast extensions to OSPF", RFC 1584, March 1994.
	[NAGA] K. Nagami, N. Demizu, H. Esaki, Y. Katsube and P. Doolan, "VCID		[NAGA] K. Nagami, N. Demizu, H. Esaki, Y. Katsube and P. Doolan, "VCID
	Notification over ATM link for LDP", Work In Progress.		Notification over ATM link for LDP", RFC3038, January 2001.
	[PERL] R. Perlman, C-Y. Lee, A. Ballardie, J. Crowcroft, Z. Wang, T.		[PERL] R. Perlman, C-Y. Lee, A. Ballardie, J. Crowcroft, Z. Wang, T.
	Maufer, "Simple Multicast", Work In Progress.		Maufer, "Simple Multicast", Work In Progress.
	[PUSA] T. Pusateri, "Distance Vector Multicast Routing Protocol", Work		[PUSA] T. Pusateri, "Distance Vector Multicast Routing Protocol", Work
	In Progress.		In Progress.
	[PAXS] V. Paxson, "End-to-End Routing Behavior in the Internet",		[PAXS] V. Paxson, "End-to-End Routing Behavior in the Internet",
	IEEE/ACM Transactions on Networking 5(5), pp. 601-615.		IEEE/ACM Transactions on Networking 5(5), pp. 601-615.
	[ROSE] E. Rosen, Y. Rekhter, D. Tappan, D. Farinacci, G. Fedorkow, T.		[ROSE] E. Rosen, Y. Rekhter, D. Tappan, D. Farinacci, G. Fedorkow, T.
	Li, A. Conta, "MPLS Label Stack Encoding", Work In Progress.		Li, A. Conta, "MPLS Label Stack Encoding", RFC3032, January
			2001.
	Authors Addresses		Authors Addresses
	Dirk Ooms		Dirk Ooms
	Alcatel Corporate Research Center		Alcatel Corporate Research Center
	Fr. Wellesplein 1, 2018 Antwerpen, Belgium.		Fr. Wellesplein 1, 2018 Antwerp, Belgium.
	Phone : 32 3 2404732		Phone : 32 3 2404732
	Fax : 32 3 2409879		Fax : 32 3 2409879
	E-mail: Dirk.Ooms@alcatel.be		E-mail: Dirk.Ooms@alcatel.be
	Bernard Sales		Bernard Sales
	Alcatel Corporate Research Center		Alcatel Corporate Research Center
	Fr. Wellesplein 1, 2018 Antwerpen, Belgium.		Fr. Wellesplein 1, 2018 Antwerp, Belgium.
	Phone : 32 3 2409574		Phone : 32 3 2409574
	E-mail: Bernard.Sales@alcatel.be		E-mail: Bernard.Sales@alcatel.be
	Wim Livens		Wim Livens
	Colt Telecom		Colt Telecom
	Zweefvliegtuigstraat 10, 1130 Brussel, Belgium		Zweefvliegtuigstraat 10, 1130 Brussels, Belgium
	Phone : 32 2 7901705		Phone : 32 2 7901705
	Fax : 32 2 7901711		Fax : 32 2 7901711
	E-mail: WLivens@colt-telecom.be		E-mail: WLivens@colt-telecom.be
	Arup Acharya		Arup Acharya
	IBM TJ Watson Research Center		IBM TJ Watson Research Center
	30 Saw Mill River Road, Hawthorne		30 Saw Mill River Road, Hawthorne
	NY 10532		NY 10532
	Phone : 1 914 784 7481		Phone : 1 914 784 7481
	E-mail: arup@us.ibm.com		E-mail: arup@us.ibm.com
	Frederic Griffoul		Frederic Griffoul
	Ulticom, Inc.		Ulticom, Inc.
	Les Algorithmes, 2000 Route des Lucioles, BP29		Les Algorithmes, 2000 Route des Lucioles, BP29
	skipping to change at page 28, line 48		skipping to change at page 28, line 22
	Ulticom, Inc.		Ulticom, Inc.
	Les Algorithmes, 2000 Route des Lucioles, BP29		Les Algorithmes, 2000 Route des Lucioles, BP29
	06901 Sophia-Antipolis, FRANCE		06901 Sophia-Antipolis, FRANCE
	E-mail: griffoul@ulticom.com		E-mail: griffoul@ulticom.com
	Furquan Ansari		Furquan Ansari
	Bell Labs		Bell Labs
	101 Crawfords Corner Rd., Holmdel, NJ 07733		101 Crawfords Corner Rd., Holmdel, NJ 07733
	Phone : 1 732 949 5149		Phone : 1 732 949 5149
	Fax : 1 732 332 6511		Fax : 1 732 332 6511
	E-mail: furquan@dnrc.bell-labs.comy		E-mail: furquan@dnrc.bell-labs.com
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/