Internet-Draft | Performance Measurement (PM) with Flow-I | July 2022 |
Zhang & Wang | Expires 12 January 2023 | [Page] |
This document proposes one new performance measurement method of Bit Index Explicit Replication (BIER) IOAM information. The controller can realize the closed-loop control of end-to-end quality assurance for BIER through collecting and analyzing of BIER IOAM and related path algorithms in the new method.¶
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 12 January 2023.¶
Copyright (c) 2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[RFC8279] introduces the architecture of the Bit Index Explicit Replication (BIER) the forwarding of multicast data packets. [I-D.wang-bier-rh-bier]introduces a new encapsulation schema of Bit Index Explicit Replication (BIER) information, and the original source address and destination address in the IPv6 Header are not changed during process of the packet forwarding. [I-D.ietf-bier-pmmm-oam]introduces how to measure packet loss and delay metrics of a multicast flow in an MPLS network by using the marking method on the BIER layer. [I-D.ietf-ippm-ioam-data]provides four possible IOAM option to record telemetry data from the transit nodes. Based on the [I-D.ietf-ippm-ioam-data], [I-D.ietf-ippm-ioam-direct-export]provides a new IOAM option type to collect and report telemetry data.¶
Multicast performance measurement is the basis of service quality guarantee. However, nowadays it is difficult for the controller to collect and association analysis dynamically of IOAM information and user multicast flow path. [I-D.ietf-ippm-ioam-direct-export] provides a flow id field to represent the flow identifier, but the draft did not specify the generation of the flow id field. Therefore, this draft has evolved from combining some of the concepts of the Direct Export (DEX) option from [I-D.ietf-ippm-ioam-direct-export] with the path and algorithm information are saved during packet forwarding from [I-D.wang-bier-rh-bier].¶
This document proposes a BIER performance measurement information collection and transmission method with the IOAM option type of Direct Export (DEX) option. In the new method, The BFIR will maintain a mapping table of flow id and (multicast source address, multicast destination address, BFIR address, End.MVPN, BIER-TE Algo) tuple (called " flow id mapping table") and BFIR will send the mapping table to the controller. When the controller receives the IOAM data, it will get the multicast path information according to the flow id mapping table. Based on the information, the controller can analyzes the performance of the multicast flows and optimize the path, which lays the basis for the normal operation and quality assurance of multicast services in the carrier network.¶
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].¶
During the transimission of multicast packet, the transit nodes send the IOAM data to the controller. When the IOAM data contains the multicast flow information, the controller can quickly locate faults and optimize paths.¶
+----+-----+ | | |Controller| | | +----------+ ^ |Exported IOAM data | | | +--------------+------+-------+--------------+ | | | | | | | | User +---+----+ +---+----+ +---+----+ +---+----+ packets |Encapsu-| | Transit| | Transit| |Decapsu-| --------->|lating |====>| Node |====>| Node |====>|lating |----> |Node | | A | | B | |Node | +--------+ +--------+ +--------+ +--------+ Insert DEX Export Export Remove DEX option and IOAM data IOAM data option and export data export data BFIR BFR BFR BFER Figure 2: IOAM data transfer process¶
Based on the new method, the nodes support BIER Routing Header will perform the following steps to forward the multicast packets:¶
1) When a BFIR receives a multicast packet, it will encapsulate the data as the method in [I-D.wang-bier-rh-bier].¶
2) The BFIR hashes the quintuple information (multicast source address, Multicast destination address, BFIR address, End.MVPN, BIER-TE Algo) into a 32-bit flow id field. Where, multicast source address is the IPv6 address of the multicast packet, multicast destination address is IPv6 multicast destination address, and the fields of End.MVPN, BIER-TE Algo are consistent with those mentioned in [I-D.wang-bier-rh-bier]. The BFIR saves the flow id field and its corresponding quintuple information in the flow id mapping table, and sends the flow id mapping table to the controller.¶
3) The BFIR encapsulates the hashed flow id field into the direct-export header. And then, the multicast packet is forwarded according to BIFT table.¶
4) The BFR and BFER collect and export IOAM data to the controller.¶
5) The controller analyzes IOAM data and proposes performance optimization suggestions for each forwarding path for the multicast flows based on the flow id field in the performance sampling data and the flow id mapping table reported by the BFIR.¶
Due to the IOAM header is encapsulated by ingress router, it needs a method to determine which multicast flow information should be assigned to the flow id field.¶
On ingress router, a "Flow ID mapping table" should be maintain to save the mapping between Flow ID field and (multicast source address, Multicast destination address, BFIR address, End.MVPN, BIER-TE Algo). Its structure is as follow:¶
+----------+-------------------------------------------------------+ | flow id1 | (multicast source address1, multicast destination | | | address1, BFIR address1,End.MVPN1, BIER-TE Algo1) | +----------+-------------------------------------------------------+ | flow id2 | (multicast source address2, multicast destination | | | address2, BFIR address2,End.MVPN2, BIER-TE Algo2) | +----------+-------------------------------------------------------+ | ... | ... | +----------+-------------------------------------------------------+ Figure 1: Flow ID mapping table¶
To be added.¶
To be added.¶