| < draft-ietf-bier-pmmm-oam-11.txt | draft-ietf-bier-pmmm-oam-12.txt > | |||
|---|---|---|---|---|
| BIER Working Group G. Mirsky | BIER Working Group G. Mirsky | |||
| Internet-Draft Ericsson | Internet-Draft Ericsson | |||
| Intended status: Standards Track L. Zheng | Intended status: Standards Track L. Zheng | |||
| Expires: 7 April 2022 Individual Contributor | Expires: 2 October 2022 Individual Contributor | |||
| M. Chen | M. Chen | |||
| G. Fioccola | G. Fioccola | |||
| Huawei Technologies | Huawei Technologies | |||
| 4 October 2021 | 31 March 2022 | |||
| Performance Measurement (PM) with Marking Method in Bit Index Explicit | Performance Measurement (PM) with Marking Method in Bit Index Explicit | |||
| Replication (BIER) Layer | Replication (BIER) Layer | |||
| draft-ietf-bier-pmmm-oam-11 | draft-ietf-bier-pmmm-oam-12 | |||
| Abstract | Abstract | |||
| This document describes the applicability of a hybrid performance | This document describes the applicability of a hybrid performance | |||
| measurement method for packet loss and packet delay measurements of a | measurement method for packet loss and packet delay measurements of a | |||
| multicast service through a Bit Index Explicit Replication domain. | multicast service through a Bit Index Explicit Replication domain. | |||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| skipping to change at page 1, line 37 ¶ | skipping to change at page 1, line 37 ¶ | |||
| 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 https://datatracker.ietf.org/drafts/current/. | Drafts is at https://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 7 April 2022. | This Internet-Draft will expire on 2 October 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2021 IETF Trust and the persons identified as the | Copyright (c) 2022 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 (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
| extracted from this document must include Simplified BSD License text | extracted from this document must include Revised BSD License text as | |||
| as described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
| provided without warranty as described in the Simplified BSD License. | provided without warranty as described in the Revised 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 | |||
| 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 | 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 | |||
| 3. OAM Field in BIER Header . . . . . . . . . . . . . . . . . . 3 | 3. OAM Field in BIER Header . . . . . . . . . . . . . . . . . . 3 | |||
| 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 | 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 4.1. Single-Marking Enabled Measurement . . . . . . . . . . . 5 | 4.1. Single-Marking Enabled Measurement . . . . . . . . . . . 5 | |||
| 4.2. Double-Marking Enabled Measurement . . . . . . . . . . . 6 | 4.2. Double-Marking Enabled Measurement . . . . . . . . . . . 6 | |||
| 4.3. Operational Considerations . . . . . . . . . . . . . . . 6 | 4.3. Operational Considerations . . . . . . . . . . . . . . . 7 | |||
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | |||
| 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 | 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 | |||
| 8.2. Informative References . . . . . . . . . . . . . . . . . 8 | 8.2. Informative References . . . . . . . . . . . . . . . . . 9 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 1. Introduction | 1. Introduction | |||
| [RFC8279] introduces and explains the Bit Index Explicit Replication | [RFC8279] introduces and explains the Bit Index Explicit Replication | |||
| (BIER) architecture and how it supports the forwarding of multicast | (BIER) architecture and how it supports the forwarding of multicast | |||
| data packets. [RFC8296] specified that in the case of BIER | data packets. [RFC8296] specified that in the case of BIER | |||
| encapsulation in an MPLS network, a BIER-MPLS label, the label that | encapsulation in an MPLS network, a BIER-MPLS label, the label that | |||
| is at the bottom of the label stack, uniquely identifies the | is at the bottom of the label stack, uniquely identifies the | |||
| multicast flow. [RFC8321] and [RFC8889] describe a hybrid | multicast flow. [I-D.fioccola-rfc8321bis] and | |||
| performance measurement method, according to the classification of | [I-D.fioccola-rfc8889bis] describe a hybrid performance measurement | |||
| measurement methods in [RFC7799]. The method, called Packet Network | method, according to the classification of measurement methods in | |||
| Performance Monitoring (PNPM), can be used to measure packet loss, | [RFC7799]. The method, called Packet Network Performance Monitoring | |||
| latency, and jitter on live traffic complies with requirements R-5 | (PNPM), can be used to measure packet loss, latency, and jitter on | |||
| and R-12 listed in [I-D.ietf-bier-oam-requirements]. Because this | live traffic complies with requirements R-5 and R-12 listed in | |||
| method is based on marking consecutive batches of packets, the method | [I-D.ietf-bier-oam-requirements]. Because this method is based on | |||
| is often referred to as a marking method. Terms PNPM and "marking | marking consecutive batches of packets, the method is often referred | |||
| method" in this document are used interchangeably. | to as a marking method. Terms PNPM and "marking method" in this | |||
| document are used interchangeably. | ||||
| This document defines how the marking method can be used on the BIER | This document defines how the marking method can be used on the BIER | |||
| layer to measure packet loss and delay metrics of a multicast flow in | layer to measure packet loss and delay metrics of a multicast flow in | |||
| an MPLS network. | an MPLS network. | |||
| 2. Conventions used in this document | 2. Conventions used in this document | |||
| 2.1. Terminology | 2.1. Terminology | |||
| This document uses the terms related to the Alternate Marking Method | This document uses the terms related to the Alternate Marking Method | |||
| as defined in [RFC8321], [RFC8889]. This document uses the terms | as defined in [I-D.fioccola-rfc8321bis], [I-D.fioccola-rfc8889bis]. | |||
| related to the Bit Indexed Explicit Replication as defined in | This document uses the terms related to the Bit Indexed Explicit | |||
| [RFC8296]. | Replication as defined in [RFC8296]. | |||
| 2.2. Requirements Language | 2.2. Requirements Language | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
| 14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| 3. OAM Field in BIER Header | 3. OAM Field in BIER Header | |||
| skipping to change at page 5, line 7 ¶ | skipping to change at page 5, line 26 ¶ | |||
| can be achieved by using an explicit Flow Identifiier. The | can be achieved by using an explicit Flow Identifiier. The | |||
| definition of the Flow Identifier is outside the scope of this | definition of the Flow Identifier is outside the scope of this | |||
| specification. It is expected that the marking values be set and | specification. It is expected that the marking values be set and | |||
| cleared at the edge of BIER domain. Thus for the scenario presented | cleared at the edge of BIER domain. Thus for the scenario presented | |||
| in Figure 2 if the operator initially monitors the A-C-G and A-B-D | in Figure 2 if the operator initially monitors the A-C-G and A-B-D | |||
| segments he may enable measurements on segments C-F and B-E at any | segments he may enable measurements on segments C-F and B-E at any | |||
| time. | time. | |||
| 4.1. Single-Marking Enabled Measurement | 4.1. Single-Marking Enabled Measurement | |||
| As explained in [RFC8321], marking can be applied to delineate blocks | As explained in [I-D.fioccola-rfc8321bis], marking can be applied to | |||
| of packets based either on the equal number of packets in a block or | delineate blocks of packets based either on the equal number of | |||
| based on the equal time interval. The latter method offers better | packets in a block or based on the equal time interval. The latter | |||
| control as it allows a better account for capabilities of downstream | method offers better control as it allows a better account for | |||
| nodes to report statistics related to batches of packets and, at the | capabilities of downstream nodes to report statistics related to | |||
| same time, time resolution that affects defect detection interval. | batches of packets and, at the same time, time resolution that | |||
| affects defect detection interval. | ||||
| If the Single-Marking measurement is used to measure packet loss, | If the Single-Marking measurement is used to measure packet loss, | |||
| then the D flag MUST be set to zero on transmit and ignored by the | then the D flag MUST be set to zero on transmit and ignored by the | |||
| monitoring point. | monitoring point. | |||
| The S flag is used to create sub-flows to measure the packet loss by | The S flag is used to create sub-flows to measure the packet loss by | |||
| switching the value of the S flag every N-th packet or at certain | switching the value of the S flag every N-th packet or at certain | |||
| time intervals. Delay metrics MAY be calculated with the sub-flow | time intervals. Delay metrics MAY be calculated with the sub-flow | |||
| using any of the following methods: | using any of the following methods: | |||
| skipping to change at page 6, line 41 ¶ | skipping to change at page 7, line 17 ¶ | |||
| For the ease of operational procedures, the initial marking of a | For the ease of operational procedures, the initial marking of a | |||
| multicast flow is performed at BFIR. and cleared, by way of removing | multicast flow is performed at BFIR. and cleared, by way of removing | |||
| BIER encapsulation form a payload packet, at the edge of the BIER | BIER encapsulation form a payload packet, at the edge of the BIER | |||
| domain by BFERs. | domain by BFERs. | |||
| Since at the time of writing this specification, there are no | Since at the time of writing this specification, there are no | |||
| proposals to using auto-discovery or signaling mechanism to inform | proposals to using auto-discovery or signaling mechanism to inform | |||
| downstream nodes what methodology is used each monitoring point MUST | downstream nodes what methodology is used each monitoring point MUST | |||
| be configured beforehand. | be configured beforehand. | |||
| Section 4.3 [RFC8321] provides a detailed analysis of how packet re- | Section 5 [I-D.fioccola-rfc8321bis] provides a detailed analysis of | |||
| ordering and the duration of the block in the Single-Marking mode of | how packet re-ordering and the duration of the block in the Single- | |||
| the marking method impact the accuracy of the packet loss | Marking mode of the marking method impact the accuracy of the packet | |||
| measurement. Re-ordering of packets in the Single-Marking mode will | loss measurement. Re-ordering of packets in the Single-Marking mode | |||
| be noticeable only at the edge of a block of packets (re-ordering | will be noticeable only at the edge of a block of packets (re- | |||
| within the block cannot be detected in the Single-Marking mode). If | ordering within the block cannot be detected in the Single-Marking | |||
| the extra delay for some packets is much smaller than half of the | mode). If the extra delay for some packets is much smaller than half | |||
| duration of a block, then it should be easier to attribute re-ordered | of the duration of a block, then it should be easier to attribute re- | |||
| packets to the proper block and thus maintain the accuracy of the | ordered packets to the proper block and thus maintain the accuracy of | |||
| packet loss measurement. | the packet loss measurement. | |||
| Selection of a time interval to switch the marking of a batch of | Selection of a time interval to switch the marking of a batch of | |||
| packets should be based on the service requirements. In the course | packets should be based on the service requirements. In the course | |||
| of the regular operation, reports, including performance metrics like | of the regular operation, reports, including performance metrics like | |||
| packet loss ratio, packet delay, and inter-packet delay variation, | packet loss ratio, packet delay, and inter-packet delay variation, | |||
| are logged every 15 minutes. Thus, it is reasonable to maintain the | are logged every 15 minutes. Thus, it is reasonable to maintain the | |||
| duration of the measurement interval at 5 minutes with 100 | duration of the measurement interval at 5 minutes with 100 | |||
| measurements per each interval. To support these measurements, | measurements per each interval. To support these measurements, | |||
| marking of the packet batch is switched every 3 seconds. In case | marking of the packet batch is switched every 3 seconds. In case | |||
| when performance metrics are required in near-real-time, the duration | when performance metrics are required in near-real-time, the duration | |||
| interval of a single batch of identically marked packets will be in | interval of a single batch of identically marked packets will be in | |||
| the range of tens of milliseconds. | the range of tens of milliseconds. | |||
| 5. IANA Considerations | 5. IANA Considerations | |||
| This document sets no requirements to IANA. This section can be | This document sets no requirements to IANA. This section can be | |||
| removed before the publication. | removed before the publication. | |||
| 6. Security Considerations | 6. Security Considerations | |||
| Regarding using the marking method, [RFC8321] stressed two types of | Regarding using the marking method, [I-D.fioccola-rfc8321bis] | |||
| security concerns. First, the potential harm caused by the | stressed two types of security concerns. First, the potential harm | |||
| measurements, is a lesser threat as [RFC8296] defines OAM field used | caused by the measurements, is a lesser threat as [RFC8296] defines | |||
| by the marking method so that the value of "two bits have no effect | OAM field used by the marking method so that the value of "two bits | |||
| on the path taken by a BIER packet and have no effect on the quality | have no effect on the path taken by a BIER packet and have no effect | |||
| of service applied to a BIER packet." Second security concern, | on the quality of service applied to a BIER packet." Second security | |||
| potential harm to the measurements can be mitigated by using policy, | concern, potential harm to the measurements can be mitigated by using | |||
| suggested in [RFC8296], to accept BIER packets only from trusted | policy, suggested in [RFC8296], to accept BIER packets only from | |||
| routers, not from customer-facing interfaces. | trusted routers, not from customer-facing interfaces. | |||
| All the security considerations for BIER discussed in [RFC8296] are | All the security considerations for BIER discussed in [RFC8296] are | |||
| inherited by this document. | inherited by this document. | |||
| 7. Acknowledgement | 7. Acknowledgement | |||
| Comments from Alvaro Retana helped improve the document and are much | Comments from Alvaro Retana helped improve the document and are much | |||
| appreciated. | appreciated. | |||
| Reviews and comments from Quan Xiong and Xiao Min are thankfully | Reviews and comments from Quan Xiong and Xiao Min are thankfully | |||
| acknowledged. | acknowledged. | |||
| 8. References | 8. References | |||
| 8.1. Normative References | 8.1. Normative References | |||
| [I-D.fioccola-rfc8321bis] | ||||
| Fioccola, G., Cociglio, M., Mirsky, G., Mizrahi, T., Zhou, | ||||
| T., and X. Min, "Alternate-Marking Method", Work in | ||||
| Progress, Internet-Draft, draft-fioccola-rfc8321bis-03, 23 | ||||
| February 2022, <https://datatracker.ietf.org/doc/html/ | ||||
| draft-fioccola-rfc8321bis-03>. | ||||
| [I-D.fioccola-rfc8889bis] | ||||
| Fioccola, G., Cociglio, M., Sapio, A., Sisto, R., and T. | ||||
| Zhou, "Multipoint Alternate-Marking Method", Work in | ||||
| Progress, Internet-Draft, draft-fioccola-rfc8889bis-03, 23 | ||||
| February 2022, <https://datatracker.ietf.org/doc/html/ | ||||
| draft-fioccola-rfc8889bis-03>. | ||||
| [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>. | |||
| [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
| May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
| [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., | [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., | |||
| Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation | Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation | |||
| for Bit Index Explicit Replication (BIER) in MPLS and Non- | for Bit Index Explicit Replication (BIER) in MPLS and Non- | |||
| MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January | MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January | |||
| 2018, <https://www.rfc-editor.org/info/rfc8296>. | 2018, <https://www.rfc-editor.org/info/rfc8296>. | |||
| [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, | ||||
| L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, | ||||
| "Alternate-Marking Method for Passive and Hybrid | ||||
| Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, | ||||
| January 2018, <https://www.rfc-editor.org/info/rfc8321>. | ||||
| [RFC8889] Fioccola, G., Ed., Cociglio, M., Sapio, A., and R. Sisto, | ||||
| "Multipoint Alternate-Marking Method for Passive and | ||||
| Hybrid Performance Monitoring", RFC 8889, | ||||
| DOI 10.17487/RFC8889, August 2020, | ||||
| <https://www.rfc-editor.org/info/rfc8889>. | ||||
| 8.2. Informative References | 8.2. Informative References | |||
| [I-D.ietf-bier-bier-yang] | [I-D.ietf-bier-bier-yang] | |||
| Chen, R., Hu, F., Zhang, Z., Dai, X., and M. Sivakumar, | Chen, R., Hu, F., Zhang, Z., Dai, X., and M. Sivakumar, | |||
| "YANG Data Model for BIER Protocol", Work in Progress, | "YANG Data Model for BIER Protocol", Work in Progress, | |||
| Internet-Draft, draft-ietf-bier-bier-yang-07, 8 September | Internet-Draft, draft-ietf-bier-bier-yang-07, 8 September | |||
| 2020, <https://datatracker.ietf.org/doc/html/draft-ietf- | 2020, <https://datatracker.ietf.org/doc/html/draft-ietf- | |||
| bier-bier-yang-07>. | bier-bier-yang-07>. | |||
| [I-D.ietf-bier-oam-requirements] | [I-D.ietf-bier-oam-requirements] | |||
| End of changes. 15 change blocks. | ||||
| 62 lines changed or deleted | 66 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/ | ||||