< draft-wang-bier-rh-bier-00.txt		draft-wang-bier-rh-bier-01.txt >
	BIER Working Group W. Wang		BIER Working Group W. Wang
	Internet-Draft A. Wang		Internet-Draft A. Wang
	Intended status: Standards Track China Telecom		Intended status: Standards Track China Telecom
	Expires: April 28, 2022 October 25, 2021		Expires: April 28, 2022 October 25, 2021
	Routing Header Based BIER Information Encapsulation		Routing Header Based BIER Information Encapsulation
	draft-wang-bier-rh-bier-00		draft-wang-bier-rh-bier-01
	Abstract		Abstract
	This draft proposes one new encapsulation schema of Bit Index		This draft proposes one new encapsulation schema of Bit Index
	Explicit Replication (BIER) information to transfer the multicast		Explicit Replication (BIER) information to transfer the multicast
	packets within the IPv6 network. By defining a new IPv6 Routing		packets within the IPv6 network. By defining a new IPv6 Routing
	Header type, it keeps the original source address and destination		Header type, it keeps the original source address and destination
	address unchanged in forwarding process. The encapsulation schema		address unchanged in forwarding process. The encapsulation schema
	can make full use of the existing IPv6 quality assurance methods to		can make full use of the existing IPv6 quality assurance methods to
	provide high-quality multicast service.		provide high-quality multicast service.
	skipping to change at page 2, line 12 ¶		skipping to change at page 2, line 12 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions used in this document . . . . . . . . . . . . . . 3		2. Conventions used in this document . . . . . . . . . . . . . . 3
	3. BIER Routing Header . . . . . . . . . . . . . . . . . . . . . 3		3. BIER Routing Header . . . . . . . . . . . . . . . . . . . . . 3
	4. The transmission process of packets with BIER Routing Header 5		4. The transmission process of packets with BIER Routing Header 4
	4.1. All devices in BIER domain support BIER Routing Header . 5		4.1. All devices in BIER domain support BIER Routing Header . 5
	4.2. Some devices in BIER domain do not support BIER Routing		4.2. Some devices in BIER domain do not support BIER Routing
	Header . . . . . . . . . . . . . . . . . . . . . . . . . 7		Header . . . . . . . . . . . . . . . . . . . . . . . . . 6
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 9		5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	7. Normative References . . . . . . . . . . . . . . . . . . . . 9		7. Normative References . . . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	Bit Index Explicit Replication (BIER) is a new multicast technology		Bit Index Explicit Replication (BIER) is a new multicast technology
	based on IPv6 defined in [RFC8279]. In BIER domain, the set of		based on IPv6 defined in [RFC8279]. In BIER domain, the set of
	destination nodes of multicast message is mapped into a BitString and		destination nodes of multicast message is mapped into a BitString and
	encapsulated into the BIER header. The position of each bit in the		encapsulated into the BIER header. The position of each bit in the
	BitString represents an BFER. Compared with the traditional		BitString represents an BFER. Compared with the traditional
	multicast technology, the nodes in BIER domain do not need to		multicast technology, the nodes in BIER domain do not need to
	skipping to change at page 3, line 22 ¶		skipping to change at page 3, line 22 ¶
	high-quality multicast service.		high-quality multicast service.
	2. Conventions used in this document		2. Conventions used in this document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119] .		document are to be interpreted as described in [RFC2119] .
	3. BIER Routing Header		3. BIER Routing Header
	In RFC8020, the format of IPv6 Routing Header is defined, as shown in		One new IPv6 Routing Header is defined according to RFC8200[RFC8200].
	Figure 1.		The message format is shown in Figure 1.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Header | Hdr Ext Len | Routing Type | Segments Left |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	. .
	. type-specific data .
	. .
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: The format of IPv6 Routing Header
	Where:
	o Next Header(8 bits): indicating the message header type
	immediately after the routing header.
	o HDR Ext Len(8 bits): indicating the length of the routing header.
	o Routing Type(8 bits): TBD. Identifying the newly defined Routing
	Header to encode BIER information.
	o Segments Left(8 bits): indicating the number of explicitly listed
	intermediate nodes to be accessed before reaching the final
	destination. It is not used here for the time being, and all are
	set to 0.
	o Type-specific data(variable): Its format is determined by the
	routing type. The length should ensure that the complete routing
	header is an integer multiple of 8 octets.
	We define a new Routing Header type: BIER Routing Header to carry
	BIER related information. The message format of the newly defined
	Routing Header type is shown in Figure 2.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Header | Hdr Ext Len | Routing Type | Segment Left |		| Next Header | Hdr Ext Len | Routing Type | Segment Left |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| BIFT-id | Ver | TTL |		| BIFT-id | Ver | TTL |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| BSL | Entropy | DSCP |OAM|		| BSL | Entropy | DSCP |OAM|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| BFIR-id |Rsv| Reserved |		| BFIR-id |Rsv| Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	. .		. .
	. BitString .		. BitString .
	. .		. .
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: The format of BIER Routing Header		Figure 1: The format of BIER Routing Header
	Where:		Where:
			o Next Header(8 bits): indicating the message header type
			immediately after the routing header.
			o HDR Ext Len(8 bits): indicating the length of the routing header.
			o Routing Type(8 bits): TBD. Identifying the newly defined Routing
			Header to encode BIER information.
			o Segments Left(8 bits): indicating the number of explicitly listed
			intermediate nodes to be accessed before reaching the final
			destination. It is not used here for the time being, and all are
			set to 0.
	o BIFT-id(20 bits): each < SD, Si, BSL > is assigned a BIFT-id.		o BIFT-id(20 bits): each < SD, Si, BSL > is assigned a BIFT-id.
	o Ver(4 bits): identifying the version of the BIER header. When an		o Ver(4 bits): identifying the version of the BIER header. When an
	unsupported BIER header version is received, the BFR needs to		unsupported BIER header version is received, the BFR needs to
	discard the packet and record the error.		discard the packet and record the error.
	o TTL(8 bits): indicating the lifetime of the message. It is used		o TTL(8 bits): indicating the lifetime of the message. It is used
	to prevent ring. The processing process is the same as that in		to prevent ring. The processing process is the same as that in
	non MPLS networks.		non MPLS networks.
	skipping to change at page 6, line 45 ¶		skipping to change at page 6, line 27 ¶
	Packet 3		Packet 3
	+----------------------------+		+----------------------------+
	Inner | Source IP Address = A |		Inner | Source IP Address = A |
	IPv6 +----------------------------+		IPv6 +----------------------------+
	Header | Destination IP Address = F |		Header | Destination IP Address = F |
	+----------------------------+		+----------------------------+
	BIER | BitString = 00000100 |		BIER | BitString = 00000100 |
	Routing+----------------------------+		Routing+----------------------------+
	Header		Header
	Figure 3: All devices in BIER domain support BIER Routing Header		Figure 2: All devices in BIER domain support BIER Routing Header
	The topology is shown in Figure 3, device A-F support BIER Routing		The topology is shown in Figure 3, device A-F support BIER Routing
	Header resolution. The packet need to be transmitted from A to F.		Header resolution. The packet need to be transmitted from A to F.
	The change of the Header has been given in the Figure. Each device		The change of the Header has been given in the Figure. Each device
	will perform the following steps after receiving the packet:		will perform the following steps after receiving the packet:
	1. Checking whether there is BIFT corresponding to the BIFT-id		1. Checking whether there is BIFT corresponding to the BIFT-id
	locally. If yes, proceed to step 2; otherwise, discard the packet.		locally. If yes, proceed to step 2; otherwise, discard the packet.
	2. Checking whether the direct-connected device support BIER Routing		2. Checking whether the direct-connected device support BIER Routing
	Header. If yes, forwarding the packet according to the BIFT related		Header. If yes, forwarding the packet according to the BIFT related
	to the BIFT-id; otherwise, see sectionSection 4.2 for detail		to the BIFT-id; otherwise, see sectionSection 4.2 for detail
	procedures.		procedures.
	skipping to change at page 8, line 26 ¶		skipping to change at page 8, line 4 ¶
	+----------------------------+		+----------------------------+
	BIER | BitString = 00001100 |		BIER | BitString = 00001100 |
	Routing+----------------------------+		Routing+----------------------------+
	Header		Header
	Packet 3		Packet 3
	+----------------------------+		+----------------------------+
	IPv6 | Source IP Address = A |		IPv6 | Source IP Address = A |
	Header +----------------------------+		Header +----------------------------+
	| Destination IP Address = F |		| Destination IP Address = F |
	BIER +----------------------------+		BIER +----------------------------+
	Routing| BitString = 00000100 |		Routing| BitString = 00000100 |
	Header +----------------------------+		Header +----------------------------+
	Figure 4: Some devices in BIER domain do not support BIER Routing Header		Figure 3: Some devices in BIER domain do not support BIER Routing Header
	The topology is shown in Figure 4, all devices expect device C		The topology is shown in Figure 4, all devices expect device C
	support BIER Routing Header resolution. The packet need to be		support BIER Routing Header resolution. The packet need to be
	transmitted from A to F. The change of the Header has been given in		transmitted from A to F. The change of the Header has been given in
	the Figure 4. When it is found that device C does not support BIER		the Figure 4. When it is found that device C does not support BIER
	Routing Header resolution, device A will perform the following steps		Routing Header resolution, device A will perform the following steps
	after receiving the packet:		after receiving the packet:
	1. Calculating the IPv6 address of next hop device that supports		1. Calculating the IPv6 address of next hop device that supports
	BIER Routing Header.		BIER Routing Header.
	skipping to change at page 9, line 38 ¶		skipping to change at page 9, line 17 ¶
	Zhu, Y., Qin, Z., Shin, M., Mishra, G., and X. Geng,		Zhu, Y., Qin, Z., Shin, M., Mishra, G., and X. Geng,
	"Encapsulation for BIER in Non-MPLS IPv6 Networks", draft-		"Encapsulation for BIER in Non-MPLS IPv6 Networks", draft-
	xie-bier-ipv6-encapsulation-10 (work in progress),		xie-bier-ipv6-encapsulation-10 (work in progress),
	February 2021.		February 2021.
	[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,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
			[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
			(IPv6) Specification", STD 86, RFC 8200,
			DOI 10.17487/RFC8200, July 2017,
			<https://www.rfc-editor.org/info/rfc8200>.
	[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,		[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
	Przygienda, T., and S. Aldrin, "Multicast Using Bit Index		Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
	Explicit Replication (BIER)", RFC 8279,		Explicit Replication (BIER)", RFC 8279,
	DOI 10.17487/RFC8279, November 2017,		DOI 10.17487/RFC8279, November 2017,
	<https://www.rfc-editor.org/info/rfc8279>.		<https://www.rfc-editor.org/info/rfc8279>.
	Authors' Addresses		Authors' Addresses
	Wei Wang		Wei Wang
	China Telecom		China Telecom
	Beiqijia Town, Changping District		Beiqijia Town, Changping District
	Beijing, Beijing 102209		Beijing, Beijing 102209
	China		China
	Email: weiwang94@foxmail.com		Email: weiwang94@foxmail.com
	Aijun Wang		Aijun Wang
	China Telecom		China Telecom
End of changes. 12 change blocks.
	47 lines changed or deleted		31 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/