BIER Z. Zhang
Internet-Draft ZTE Corporation
Intended status: Standards Track A. Przygienda
Expires: April 24, 2019 Juniper Networks, Inc.
October 21, 2018

BIER in IPv6
draft-zhang-bier-bierin6-02

Abstract

BIER is a new architecture for the forwarding of multicast data packets. This document defines native IPv6 encapsulation for BIER hop-by-hop forwarding or BIERin6 for short.

Requirements Language

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.

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 on April 24, 2019.

Copyright Notice

Copyright (c) 2018 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

BIER [RFC8279] is a new architecture for the forwarding of multicast data packets. It provides optimal forwarding through a "multicast domain' and it does not necessarily precondition construction of a multicast distribution tree, nor does it require intermediate nodes to maintain any per-flow state.

[RFC8296] defines the BIER encapsulation format in MPLS and non-MPLS environment that rely on MPLS labels or special ethernet type support. In pure IPv6 environments a BIER packet could be forwarded by means of simple IPv6 hop-by-hop processing only, without any new hardware support. Ultimate hardware support is obviously possible but the encapsulation is especially interesting for environments like [RFC7368] where high throughput multicast forwarding performance is not decisive and could be initially done in slow-path or end host (assuming last-hop being IPv6 encapsulated).

This document defines native BIER IPv6 encapsulation we call BIERv6. This encapsulation is aligned with the format defined in [RFC8296] for a non-mpls version.

This document uses terminology defined in [RFC8279].

2. IPv6 Header

The BIER packet itself is the payload of an IPv6 frame. The destination address field in IPv6 packet MAY be the neighbor's link-local or one of the loopback interface addresses of that neighbor. The destination address SHOULD be the BFR-prefix advertised by IGP/BGP extensions for BIER. TTL value of 1 MUST be used on the IPv6 packet.

The source address field in IPv6 packet MAY be the loopback interface address of the sending BFIR. The address SHOULD be the BFR-prefix advertised in IGP/BGP extension.

A new next-protocol type in IPv6 Next header field of TBD indicates the following BIER packet.

The Flow-ID in the IPv6 packet SHOULD be copied from the entropy field in the BIER encapsulation.

3. BIER Header

S bit in BIER header has no significance in this environment. It should be set to 1 upon transmission, but it MUST be ignored upon reception.

TC bits in BIER header have no significance in this environment since the IPv6 packet TC takes precedence on processing. It should be set to zero upon transmission, but it MUST be ignored upon reception.

The BIFT-id is used to indicate the combination of <SD, SI, BSL> normally; it should be set to the value advertised by the next-hop BFR through e.g. IGP [I-D.ietf-bier-ospf-bier-extensions], [I-D.zhang-bier-babel-extensions] or BGP [I-D.ietf-bier-idr-extensions] extension for BIER.

The remaining fields defined in BIER header MUST assume the same values and be afforded same treatement as specified in [RFC8296].

4. IANA Considerations

IANA is requested to set up a new type of "Next header" registry value for BIERv6 in the "Assigned Internet Protocol Numbers" registry.

5. Security Considerations

General IPv6 and BIER security considerations apply.

6. References

6.1. Normative References

[I-D.ietf-bier-idr-extensions] Xu, X., Chen, M., Patel, K., Wijnands, I. and T. Przygienda, "BGP Extensions for BIER", Internet-Draft draft-ietf-bier-idr-extensions-05, March 2018.
[I-D.ietf-bier-ospf-bier-extensions] Psenak, P., Kumar, N., Wijnands, I., Dolganow, A., Przygienda, T., Zhang, Z. and S. Aldrin, "OSPFv2 Extensions for BIER", Internet-Draft draft-ietf-bier-ospf-bier-extensions-18, June 2018.
[I-D.zhang-bier-babel-extensions] Zhang, Z. and T. Przygienda, "BIER in BABEL", Internet-Draft draft-zhang-bier-babel-extensions-01, June 2017.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998.

6.2. Informative References

[RFC7368] Chown, T., Arkko, J., Brandt, A., Troan, O. and J. Weil, "IPv6 Home Networking Architecture Principles", RFC 7368, DOI 10.17487/RFC7368, October 2014.
[RFC8279] Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T. and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, November 2017.
[RFC8296] Wijnands, IJ., Rosen, E., 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.

Authors' Addresses

Zheng(Sandy) Zhang ZTE Corporation EMail: zzhang_ietf@hotmail.com
Tony Przygienda Juniper Networks, Inc. EMail: prz@juniper.net