BIER Working Group W. Wang Internet-Draft A. Wang Intended status: Standards Track China Telecom Expires:April 28,July 2, 2022October 25,December 29, 2021 Routing Header Based BIER Information Encapsulationdraft-wang-bier-rh-bier-02draft-wang-bier-rh-bier-03 Abstract This draft proposes one new encapsulation schema of Bit Index Explicit Replication (BIER) information to transfer the multicast packets within the IPv6 network. By using a new type of IPv6 Routing Headertypeto forward the packet, the original source address and destination address of the multicast packet is kept unchanged along the forwarding path. Such encapsulation schema can make full use of the existing IPv6 quality assurance solutions to provide high-quality multicast service. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire onApril 28,July 2, 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . 3 3. BIER Routing Header . . . . . . . . . . . . . . . . . . . . . 3 4. Multicast Packet Forwarding Procedures . . . . . . . . . . . 5 4.1. Alldevicesnodes in BIER domain support BIER Routing Header .5. 6 4.2. Somedevicesnodes in BIER domain do not support BIER Routing Header . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . .89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . .89 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . .910 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .910 1. Introduction Bit Index Explicit Replication (BIER) is a new multicast technology based on IPv6 defined in [RFC8279]. In BIER domain, the set of destination nodes of multicast message is mapped into a BitString and encapsulated into the BIER header. The position of each bit in the BitString represents an BFER. Compared with the traditional multicasttechnology,technologies, the nodes in BIER domain do not need to maintain a multicast tree and keep the multicast flow state for each multicast flow. Currently, there are two methods for encapsulating BIER information based on IPv6 in IETF:BIERn6([I-D.ietf-bier-bierin6])BIERin6([I-D.ietf-bier-bierin6]) and BIERv6([I-D.xie-bier-ipv6-encapsulation]). BIERin6 carries BIER information by defining a new IPv6 next header type. During the forwarding process, the source address and destination address in the header will be changed. BIERv6 carries bier related information by defining an newoptiontype of destination options header (i.e. bier option). The source address in the header remains unchanged but the destination address will be changed along the forwarding path. The differences between the above two BIER encapsulation and forwarding schemes are unfavorable for the development of BIER and its derivatives. In addition, when there is error in the forward process of the multicast packet, the change of source address and destination address during transmission will increase the difficulty of fault location and traceability. This draft proposes a BIER information transmission scheme without changing the multicast source and destination addresses. The relevant BIER information is encapsulated within the newly defined IPv6 Routing Header type, each intermediate BIER router will route the multicast packet based on the BitString information and its associated BIFT. The multicast source and destination address are not changed along the forwarding path. The characteristics of such schema are helpful to the rapid fault location and traceability, and can make full use of the existing IPv6 quality assurance technologies to provide high-quality multicast service. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] . 3. BIER Routing Header One new type of IPv6 Routing Header is defined according to [RFC8200]. The message format is shown in Figure 1. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Routing Type | Segment Left | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BIFT-id |Ver |TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Nibble | Ver | BSL | Entropy |DSCP |OAM|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |OAM|Rsv| DSCP | Proto | BFIR-id|Rsv| Reserved| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || . . .BitString. . . |(first 32 bits) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ BitString (last 32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: The format of BIER 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 BIFT-id(20 bits): each < SD, Si, BSL > is assigned a BIFT-id. oVer(4TC(3 bits):identifying the version of the BIER header. When an unsupported BIER header versionsee [RFC8296]. This field isreceived, the BFR needsset todiscard the packet and record the error.0. o S(1 bit): see [RFC8296]. This field is set to 0. 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 non MPLS networks. o Nibble(4 bits): see [RFC8296]. This field is set to 0. o Ver(4 bits): identifying the version of the BIER header. When an unsupported BIER header version is received, the BFR needs to discard the packet and record the error. o BSL(4 bits): indicating the length of BitString. o Entropy(20 bits): this field specifies an "entropy" for ECMP. oDSCP(6 bits): this field is used to support different service codes. oOAM(2 bits): by default, this value will be set to 0 by BFIR, and other BFRs will not be modified. Whether to use this field is optional. o Rsv(2 bits): unused, set to 0. o DSCP(6 bits): this field is used to support different service codes. o Proto(6 bits): see [RFC8296]. This field is set to 0. o BFIR-id(16 bits): indicating BFR ID of BFIR. oRsv(2 bits): unused, set to 0. oReserved (14 bits): reserved field, set to 0. o BitString(variable): the length must be reflected in the BSL field. The string saved in this field is used to identify the destination BFER of the packet. 4. Multicast Packet Forwarding Procedures Based on the newly defined BIER Routing Header, thedevicesnodes support BIER Routing Header will perform the following steps to forward the multicast packets: 1) When a BFIRreceives the IPv6receive a multicastpackets from the mulicast source,packet, it willaddencapsulate a IPv6 Header with BIER Routing Header. The payload is user data, the source address is the IPv6 address of BFIR, and destination address is the destination address of original multicast packet. BitString in BIER Routing Headerto indicateindicates the BFERs that want to receives such multicast packet.The encapsulated multicast packet will be forwarded according2) BFIR checks whether there is BIFT corresponding to theBIFT that identified byBIFT-id locally. If not, it will discard theBIFT-id. 2) Each BFR (includes BFIR)packet; otherwise, it will check whether the direct-connecteddevicenode support BIER Routing Header. Ifyes, proceedthe direct-connected node supports BIER Routing Header, proceeding to step3); otherwise, proceed3). If the direct-connected node doesn't support BIER Routing Header, proceeding to step2.1).2.1)Calculating. 2.1) BFIR Calculates the IPv6 address of next hop that support BIER Routing Header. 2.2) Encapsulating an outer IPv6 Header to the multicast packet. The calculated IPv6 address is used as the destination address of the outer IPv6 Header, and its own IPv6 address is used as the source address of the outer IPv6 Header. BitString will not be changed. 2.3) Sending the encapsulated packet to the direct-connecteddevice,node, thedevicenode will perform normal IPv6 forwarding according to the outer IPv6 Header. 3)On the router that supports the BIER Routing Header, performPerforming the normal BIER forwarding process as described in [RFC8279]. For a BFR, it performs the above procedures except 1). The detail procedures for forwarding the multicast packets based on the newly defined Routing Header are described in the following sections. 4.1. Alldevicesnodes in BIER domain support BIER Routing Header +---+ +-----------+ B +----------+ | +---+ | | 0:01000000 | | | | | | | +-+-+ +-+-+ (Packet 2) +---+ (Packet 3)+---+ | A |0:10000000 0:00100000| C +------------+ E +-----------+ F | +-+-+ +-+-+ +---+ +---+ | | 0:00001000 0:00000100 | | | | | | | 0:00010000 | | +---+ | +-----------+ D +----------+ (Packet 1) +---+ Packet 1 +------------------------------------+ IPv6 | IPv6 Address ofMulticast SourceA | Header +------------------------------------+ with | IPv6 Multicast Destination Address | BIER +------------------------------------+ Routing|BitStringBIER RH(BitString =0010110000101100) | Header +------------------------------------+ | Original multicast packet | +------------------------------------+ Packet 2 +------------------------------------+ IPv6 | IPv6 Address ofMulticast SourceA | Header +------------------------------------+ with | IPv6 Multicast Destination Address | BIER +------------------------------------+ Routing|BitStringBIER RH(BitString =0000110000001100) | Header +------------------------------------+ | Original multicast packet | +------------------------------------+ Packet 3 +------------------------------------+ IPv6 | IPv6 Address ofMulticast SourceA | Header +------------------------------------+ with | IPv6 Multicast Destination Address | BIER +------------------------------------+ Routing|BitStringBIER RH(BitString =0000010000000100) | Header +------------------------------------+ | Original multicast packet | +------------------------------------+ Figure 2: Alldevicesnodes in BIER domain support BIER Routing Header The topology is shown in Figure 2,devicenode A-F support BIER Routing Header. The packet need to be transmitted from A to F. The changes of the Routing Header have been given in Figure 2.Each device1). Node A is BFIR, when it receives a multicast packet, it willperformencapsulate a IPv6 Header with BIER Routing Header to thefollowing steps after receivingpacket. The source address is thepacket: 1). CheckingIPv6 address of itself, and the destination address is the destination address of original multicast packet. 2). Node A checks whether there is BIFT corresponding to the BIFT-id locally. Ifyes, proceed to step 2); otherwise, discardnot, discarding thepacket. 2). Checking whether the direct-connected device support BIER Routing Header. If yes,packet; otherwise, forwarding the packet according to the BIFT related to theBIFT-id; otherwise, see sectionSection 4.2 for detail procedures.BIFT-id. During the forwarding procedures, the sourceaddress and& destination addressof thein IPv6multicast packetheader are not changed, only the BitString in BIER Routing Header is updated. 4.2. Somedevicesnodes in BIER domain do not support BIER Routing Header +---+ +-----------+ B +-----------+ | +---+ | | 0:01000000 | | | | | | | +-+-+ +-+-+ +---+ (Packet 3) +---+ | A |0:10000000 | C +------------+ E +------------+ F | +-+-+ +-+-+ +---+ +---+ | | 0:00001000 0:00000100 | | | | | | | 0:00010000 | | +---+ | +-----------+ D +-----------+ (Packet 1)+---+(Packet+---+ (Packet 2) Packet 1 +------------------------------------+ IPv6 | IPv6 Address ofMulticast SourceA | Header +------------------------------------+ with | IPv6 Multicast Destination Address | BIER +------------------------------------+ Routing|BitStringBIER RH(BitString =0010110000001100) | Header +------------------------------------+ | Original multicast packet | +------------------------------------+ Packet 2 +------------------------------------+ Outer | Source IP Address = D | IPv6 +------------------------------------+ Header | Destination IP Address = E | +------------------------------------+ Inner | IPv6 Address ofMulticast SourceA | IPv6 +------------------------------------+ Header | IPv6 Multicast Destination Address | with +------------------------------------+ BIER |BitStringBIER RH(BitString =0000110000001100) | Routing+------------------------------------+ Header | Original multicast packet | +------------------------------------+ Packet 3 +-------------------------------------+ IPv6 | IPv6 Address ofMulticast SourceA | Header +-------------------------------------+ with | IPv6 Multicast Destination Address | BIER +-------------------------------------+ Routing|BitStringBIER RH(BitString =0000010000000100) | Header +-------------------------------------+ | Original multicast packet | +-------------------------------------+ Figure 3: Somedevicesnodes in BIER domain do not support BIER Routing Header The topology is shown in Figure 3, alldevicesnodes expectdevicenode C support BIER Routing Header. The packet need to be transmitted from A to F. The change of the Header has been given in the Figure 3.When it is found that device C does not support1). After receiving a multicast packet, node A encapsulates a IPv6 Header with BIER RoutingHeader, device D will performHeader to it, and forwards thefollowing steps after receivingpacket to node D according to thepacket: 1. CalculatingBIFT. 2). Node D calculates the IPv6 address of next hopdevice(Nodenode(Node E) that supports BIER RoutingHeader. 2. EncapsulatingHeader, and encapsulates an outer IPv6 Header to the packet. Thecalculatedsource IPv6address(E)address isused asthedestinationIPv6 address ofthe outer IPv6 Header,itself, andits ownthe destination IPv6address(D)address isused asthesourceIPv6 address ofthe outer IPv6 Header. BitString will not be changed. 3. Sendingnode E. Then, sending the packet todirected-connected devicenode C.After receiving the packet, device3). Node Cwill performperforms normal IPv6 forwarding according to theinformation inouter IPv6Header,header andsendsends the packet todevicenode E.Device4). Node Ewill send it to device Fdecapsulates the outer IPv6 header and forwards the packet according to theinformation in BIER Routing Header.BIFT to node F. In the forwardingprocess,procedures, the source address and destination address in the Inner IPv6 Header are notchanged.changed, only the BitString in BIER Routing Header is updated. 5. Security Considerations TBD 6. IANA Considerations This document defines a new type of IPv6 Routing Header - BIER Routing Header. The code point is from the "Internet Protocol Version 6 (IPv6) Parameters - Routing Types". It is recommended to set the code point of BIER Routing Header to 7. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <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., Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, November 2017, <https://www.rfc-editor.org/info/rfc8279>. [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non- MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 2018, <https://www.rfc-editor.org/info/rfc8296>. 7.2. Informative References [I-D.ietf-bier-bierin6] Zhang, Z., Zhang, Z., Wijnands, I., Mishra, M., Bidgoli, H., and G. Mishra, "Supporting BIER in IPv6 Networks (BIERin6)",draft-ietf-bier-bierin6-00draft-ietf-bier-bierin6-01 (work in progress),JuneDecember 2021. [I-D.xie-bier-ipv6-encapsulation] Xie, J., Geng, L., McBride, M., Asati, R., Dhanaraj, S., Zhu, Y., Qin, Z., Shin, M., Mishra, G., and X. Geng, "Encapsulation for BIER in Non-MPLS IPv6 Networks", draft- xie-bier-ipv6-encapsulation-10 (work in progress), February 2021. Authors' Addresses Wei Wang China Telecom Beiqijia Town, Changping District Beijing, Beijing 102209 China Email: weiwang94@foxmail.com Aijun Wang China Telecom Beiqijia Town, Changping District Beijing, Beijing 102209 China Email: wangaj3@chinatelecom.cn