< draft-ietf-bier-use-cases-02.txt		draft-ietf-bier-use-cases-03.txt >
	Network Working Group N. Kumar		Network Working Group N. Kumar
	Internet-Draft R. Asati		Internet-Draft R. Asati
	Intended status: Informational Cisco		Intended status: Informational Cisco
	Expires: July 29, 2016 M. Chen		Expires: January 8, 2017 M. Chen
	X. Xu		X. Xu
	Huawei		Huawei
	A. Dolganow		A. Dolganow
	Alcatel-Lucent		Alcatel-Lucent
	T. Przygienda		T. Przygienda
	Ericsson		Ericsson
	A. Gulko		A. Gulko
	Thomson Reuters		Thomson Reuters
	D. Robinson		D. Robinson
	id3as-company Ltd		id3as-company Ltd
	V. Arya		V. Arya
	DirecTV Inc		DirecTV Inc
	C. Bestler		C. Bestler
	Nexenta		Nexenta
	January 26, 2016		July 7, 2016
	BIER Use Cases		BIER Use Cases
	draft-ietf-bier-use-cases-02.txt		draft-ietf-bier-use-cases-03 .txt
	Abstract		Abstract
	Bit Index Explicit Replication (BIER) is an architecture that		Bit Index Explicit Replication (BIER) is an architecture that
	provides optimal multicast forwarding through a "BIER domain" without		provides optimal multicast forwarding through a "BIER domain" without
	requiring intermediate routers to maintain any multicast related per-		requiring intermediate routers to maintain any multicast related per-
	flow state. BIER also does not require any explicit tree-building		flow state. BIER also does not require any explicit tree-building
	protocol for its operation. A multicast data packet enters a BIER		protocol for its operation. A multicast data packet enters a BIER
	domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the		domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the
	BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs).		BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs).
	skipping to change at page 2, line 12 ¶		skipping to change at page 2, line 12 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on July 29, 2016.		This Internet-Draft will expire on January 8, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 43 ¶		skipping to change at page 2, line 43 ¶
	3. BIER Use Cases . . . . . . . . . . . . . . . . . . . . . . . 3		3. BIER Use Cases . . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Multicast in L3VPN Networks . . . . . . . . . . . . . . . 3		3.1. Multicast in L3VPN Networks . . . . . . . . . . . . . . . 3
	3.2. BUM in EVPN . . . . . . . . . . . . . . . . . . . . . . . 4		3.2. BUM in EVPN . . . . . . . . . . . . . . . . . . . . . . . 4
	3.3. IPTV and OTT Services . . . . . . . . . . . . . . . . . . 5		3.3. IPTV and OTT Services . . . . . . . . . . . . . . . . . . 5
	3.4. Multi-service, converged L3VPN network . . . . . . . . . 6		3.4. Multi-service, converged L3VPN network . . . . . . . . . 6
	3.5. Control-plane simplification and SDN-controlled networks 7		3.5. Control-plane simplification and SDN-controlled networks 7
	3.6. Data center Virtualization/Overlay . . . . . . . . . . . 7		3.6. Data center Virtualization/Overlay . . . . . . . . . . . 7
	3.7. Financial Services . . . . . . . . . . . . . . . . . . . 8		3.7. Financial Services . . . . . . . . . . . . . . . . . . . 8
	3.8. 4k broadcast video services . . . . . . . . . . . . . . . 9		3.8. 4k broadcast video services . . . . . . . . . . . . . . . 9
	3.9. Distributed Storage Cluster . . . . . . . . . . . . . . . 10		3.9. Distributed Storage Cluster . . . . . . . . . . . . . . . 10
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 11		3.10. HTTP-Level Multicast . . . . . . . . . . . . . . . . . . 11
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
	7.1. Normative References . . . . . . . . . . . . . . . . . . 12		7. Contributing Authors . . . . . . . . . . . . . . . . . . . . 13
	7.2. Informative References . . . . . . . . . . . . . . . . . 12		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		8.1. Normative References . . . . . . . . . . . . . . . . . . 14
			8.2. Informative References . . . . . . . . . . . . . . . . . 14
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	Bit Index Explicit Replication (BIER) [I-D.ietf-bier-architecture] is		Bit Index Explicit Replication (BIER) [I-D.ietf-bier-architecture] is
	an architecture that provides optimal multicast forwarding through a		an architecture that provides optimal multicast forwarding through a
	"BIER domain" without requiring intermediate routers to maintain any		"BIER domain" without requiring intermediate routers to maintain any
	multicast related per-flow state. BIER also does not require any		multicast related per-flow state. BIER also does not require any
	explicit tree-building protocol for its operation. A multicast data		explicit tree-building protocol for its operation. A multicast data
	packet enters a BIER domain at a "Bit-Forwarding Ingress Router"		packet enters a BIER domain at a "Bit-Forwarding Ingress Router"
	(BFIR), and leaves the BIER domain at one or more "Bit-Forwarding		(BFIR), and leaves the BIER domain at one or more "Bit-Forwarding
	skipping to change at page 11, line 40 ¶		skipping to change at page 11, line 40 ¶
	In a simple mapping of the MLD managed multicast groups, each		In a simple mapping of the MLD managed multicast groups, each
	Negotiating Group could be represented by a short Bitstring selected		Negotiating Group could be represented by a short Bitstring selected
	by a Set Identifier. The Set Indentier effectively becomes the		by a Set Identifier. The Set Indentier effectively becomes the
	Negotiating Group. To address the entire Negotiating Group you set		Negotiating Group. To address the entire Negotiating Group you set
	the Bitstring to all ones. To later address a subset of the group a		the Bitstring to all ones. To later address a subset of the group a
	subset Bitstring is used.		subset Bitstring is used.
	This allows a short fixed size BIER header to multicast to a very		This allows a short fixed size BIER header to multicast to a very
	large storage cluster.		large storage cluster.
			3.10. HTTP-Level Multicast
			Scenarios where a number of HTTP-level clients are quasi-
			synchronously accessing the same HTTP-level resource can benefit from
			the the dynamic multicast group formation enabled by BIER.
			For example, in the FLIPS (Flexible IP Services) solution by
			InterDigital, network attachment points (NAPs) provide a protocol
			mapping from HTTP to an efficient BIER-compliant transfer along a
			bit-indexed path between an ingress (here the NAP to which the
			clients connect) and an egress (here the NAP to which the HTTP-level
			server connects). This is accomplished with the following steps:
			o at the client NAP, the HTTP request is terminated at the HTTP
			level at a local HTTP proxy.
			o the HTTP request is published by the client NAP towards the FQDN
			of the server defined in the HTTP request
			* if no local BIER forwarding information exists to the server
			(NAP), a path computation entity (PCE) is consulted, which
			calculates a unicast path to the egress NAP (here the server
			NAP). The PCE provides the forwarding information to the
			client NAP, which in turn caches the result.
			+ if the local BIER forwarding information exists in the NAP-
			local cache, it is used instead.
			o Upon arrival of a client NAP request at the server NAP, the server
			NAP proxy forwards the HTTP request as a well-formed HTTP request
			locally to the server.
			* If no client NAP forwarding information exists for the reverse
			direction, this information is requested from the PCE. Upon
			arrival of such reverse direction forwarding information, it is
			stored in a local table for future use.
			o Upon arrival of any further client NAP request at the server NAP
			to an HTTP request whose response is still outstanding, the client
			NAP is added to an internal request table and the request is
			suppressed from being sent to the server.
			* If no client NAP forwarding information exists for the reverse
			direction, this information is requested from the PCE. Upon
			arrival of such reverse direction forwarding information, it is
			stored in a local table for future use.
			o Upon arrival of an HTTP response at the server NAP, the server NAP
			consults its internal request table for any outstanding HTTP
			requests to the same request
			the server NAP retrieves the stored BIER forwarding information
			for the reverse direction for all outstanding HTTP requests
			found above and determines the path information to all client
			NAPs through a binary OR over all BIER forwarding identifiers
			with the same SI field. This newly formed joint BIER multicast
			response identifier is used to send the HTTP response across
			the network, while the procedure is executed until all requests
			have been served.
			o Upon arrival of the HTTP response at a client NAP, it will be sent
			by the client NAP proxy to the locally connected client.
			A number of solutions exist to manage necessary updates in locally
			stored BIER forwarding information for cases of client/server
			mobility as well as for resilience purposes.
			Applications for HTTP-level multicast are manifold. Examples are
			HTTP-level streaming (HLS) services, provided as an OTT offering,
			either at the level of end user clients (connected to BIER-enabled
			NAPs) or site-level clients. Others are corporate intranet storage
			cluster solutions that utilize HTTP- level synchronization. In
			multi-tenant data centre scenarios such as outlined in Section 3.6.,
			the aforementioned solution can satisfy HTTP-level requests to
			popular services and content in a multicast delivery manner.
			BIER enables such solution through the bitfield representation of
			forwarding information, which is in turn used for ad-hoc multicast
			group formation at the HTTP request level. While such solution works
			well in SDN-enabled intra- domain scenarios, BIER would enable the
			realization of such scenarios in multi-domain scenarios over legacy
			transport networks without relying on SDN-controlled infrastructure.
	4. Security Considerations		4. Security Considerations
	There are no security issues introduced by this draft.		There are no security issues introduced by this draft.
	5. IANA Considerations		5. IANA Considerations
	There are no IANA consideration introduced by this draft.		There are no IANA consideration introduced by this draft.
	6. Acknowledgments		6. Acknowledgments
	The authors would like to thank IJsbrand Wijnands, Greg Shepherd and		The authors would like to thank IJsbrand Wijnands, Greg Shepherd and
	Christian Martin for their contribution.		Christian Martin for their contribution.
	7. References		7. Contributing Authors
	7.1. Normative References		Dirk Trossen
			InterDigital Inc
			Email: dirk.trossen@interdigital.com
			8. References
			8.1. Normative References
	[I-D.ietf-bier-architecture]		[I-D.ietf-bier-architecture]
	Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and		Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and
	S. Aldrin, "Multicast using Bit Index Explicit		S. Aldrin, "Multicast using Bit Index Explicit
	Replication", draft-ietf-bier-architecture-02 (work in		Replication", draft-ietf-bier-architecture-02 (work in
	progress), July 2015.		progress), July 2015.
	[I-D.ietf-bier-mvpn]		[I-D.ietf-bier-mvpn]
	Rosen, E., Sivakumar, M., Wijnands, I., Aldrin, S.,		Rosen, E., Sivakumar, M., Wijnands, I., Aldrin, S.,
	Dolganow, A., and T. Przygienda, "Multicast VPN Using		Dolganow, A., and T. Przygienda, "Multicast VPN Using
	BIER", draft-ietf-bier-mvpn-01 (work in progress), July		BIER", draft-ietf-bier-mvpn-01 (work in progress), July
	2015.		2015.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	7.2. Informative References		8.2. Informative References
	[I-D.ietf-l2vpn-evpn]		[I-D.ietf-l2vpn-evpn]
	Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J.		Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J.
	Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn-		Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn-
	evpn-11 (work in progress), October 2014.		evpn-11 (work in progress), October 2014.
	[I-D.ietf-spring-segment-routing]		[I-D.ietf-spring-segment-routing]
	Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,		Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
	and r. rjs@rob.sh, "Segment Routing Architecture", draft-		and r. rjs@rob.sh, "Segment Routing Architecture", draft-
	ietf-spring-segment-routing-04 (work in progress), July		ietf-spring-segment-routing-04 (work in progress), July
End of changes. 9 change blocks.
	14 lines changed or deleted		104 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/