| < draft-mirsky-sfc-pmamm-14.txt | draft-mfm-ippm-sfc-nsh-pmamm-00.txt > | |||
|---|---|---|---|---|
| SFC Working Group G. Mirsky | IPPM Working Group G. Mirsky | |||
| Internet-Draft Ericsson | Internet-Draft Ericsson | |||
| Intended status: Experimental G. Fioccola | Intended status: Standards Track G. Fioccola | |||
| Expires: 28 March 2022 Huawei Technologies | Expires: 3 October 2022 Huawei Technologies | |||
| T. Mizrahi | T. Mizrahi | |||
| Huawei Network.IO Innovation Lab | Huawei Network.IO Innovation Lab | |||
| 24 September 2021 | 1 April 2022 | |||
| Performance Measurement (PM) with Alternate Marking Method in Service | Performance Measurement (PM) with Alternate Marking Method in Service | |||
| Function Chaining (SFC) Domain | Function Chaining (SFC) Network Service Header (NSH) Domain | |||
| draft-mirsky-sfc-pmamm-14 | draft-mfm-ippm-sfc-nsh-pmamm-00 | |||
| Abstract | Abstract | |||
| This document describes how the alternate marking method can be used | This document describes how the alternate marking method can be used | |||
| as the efficient performance measurement method taking advantage of | as the efficient performance measurement method taking advantage of | |||
| the actual data flows in a Service Function Chaining (SFC) domain. | the actual data flows in a Service Function Chaining domain using | |||
| Network Service Header encapsulation. | ||||
| 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 | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| 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 28 March 2022. | This Internet-Draft will expire on 3 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. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 | 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 | |||
| 3. Mark Field in NSH Base Header . . . . . . . . . . . . . . . . 3 | 3. Mark Field in NSH Base Header . . . . . . . . . . . . . . . . 3 | |||
| 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 | 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 4.1. Single Mark Enabled Measurement . . . . . . . . . . . . . 5 | 4.1. Single Mark Enabled Measurement . . . . . . . . . . . . . 5 | |||
| 4.2. Multiplexed Mark Enabled Measurement . . . . . . . . . . 5 | 4.2. Multiplexed Mark Enabled Measurement . . . . . . . . . . 6 | |||
| 4.3. Residence Time Measurement with the Alternate Marking | 4.3. Residence Time Measurement with the Alternate Marking | |||
| Method . . . . . . . . . . . . . . . . . . . . . . . . . 6 | Method . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 5.1. Mark Field in NSH Base Header . . . . . . . . . . . . . . 6 | 5.1. Mark Field in NSH Base Header . . . . . . . . . . . . . . 6 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | |||
| 7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 7 | 7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 | |||
| 8.2. Informative References . . . . . . . . . . . . . . . . . 7 | 8.2. Informative References . . . . . . . . . . . . . . . . . 8 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 1. Introduction | 1. Introduction | |||
| [RFC7665] introduced the architecture of a Service Function Chain | [RFC7665] introduced the architecture of a Service Function Chain | |||
| (SFC) in the network and defined its components. These include | (SFC) in the network and defined its components. These include | |||
| Classifier, Service Function Forwarder (SFF), Service Function (SF), | Classifier, Service Function Forwarder (SFF), Service Function (SF), | |||
| and Service Function proxy. [RFC8924] provides a reference framework | and Service Function proxy. [RFC8924] provides a reference framework | |||
| for Operations, Administration and Maintenance (OAM) for SFC. | for Operations, Administration and Maintenance (OAM) for SFC. | |||
| [RFC8321] describes the hybrid performance measurement method, which | [I-D.fioccola-rfc8321bis] describes the hybrid performance | |||
| can be used to measure packet loss, latency, and jitter on live | measurement method, which can be used to measure packet loss, | |||
| traffic. Because this method is based on marking consecutive batches | latency, and jitter on live traffic. Because this method is based on | |||
| of packets, the procedure is often referred to as Alternate Marking | marking consecutive batches of packets, the procedure is often | |||
| Method (AMM). | referred to as Alternate Marking Method (AMM). | |||
| This document defines how packet loss and delay metrics of a service | This document defines how packet loss and delay metrics of a service | |||
| flow over end-to-end (E2E) Service Function Path (SFP) or any SFP | flow over end-to-end (E2E) Service Function Path (SFP) or any SFP | |||
| segment can be measured using AMM. This document is aligned with the | segment can be measured using AMM. This document is aligned with the | |||
| SFC OAM Performance Measurement requirements defined in [RFC8924]. | SFC OAM Performance Measurement requirements defined in [RFC8924]. | |||
| It states that any SFC-aware network device must have the ability to | It states that any SFC-aware network device must have the ability to | |||
| perform loss and delay measurements over the service function chain | perform loss and delay measurements over the service function chain | |||
| as a unit, i.e., E2E, or to a specific segment of service function | as a unit, i.e., E2E, or to a specific segment of service function | |||
| through the SFC. Besides, AMM can be used in combination with | through the SFC. Besides, AMM can be used in combination with | |||
| [I-D.ietf-sfc-ioam-nsh] complementing it in achieving the SFC | [I-D.ietf-sfc-ioam-nsh] complementing it in achieving the SFC | |||
| performance measurement objective. | performance measurement objective with Network Service Header | |||
| [RFC8300] data plane. | ||||
| 2. Conventions used in this document | 2. Conventions used in this document | |||
| 2.1. Acronyms | 2.1. Acronyms | |||
| AMM: Alternate Marking Method | AMM: Alternate Marking Method | |||
| OAM: Operations, Administration and Maintenance | OAM: Operations, Administration and Maintenance | |||
| SFC: Service Function Chain | SFC: Service Function Chain | |||
| skipping to change at page 3, line 49 ¶ | skipping to change at page 4, line 4 ¶ | |||
| 3. Mark Field in NSH Base Header | 3. Mark Field in NSH Base Header | |||
| [RFC8300] defines the format of the Network Service Header (NSH). | [RFC8300] defines the format of the Network Service Header (NSH). | |||
| 0 1 2 3 | 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 | 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |Ver|O|M| TTL | Length |U|U|U|U|MD Type| Proto | | |Ver|O|M| TTL | Length |U|U|U|U|MD Type| Proto | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 1: NSH Base format | Figure 1: NSH Base format | |||
| This document defines the one-bit long field, referred to as Mark | This document defines the one-bit long field, referred to as Mark | |||
| field (M in Figure 1, as part of NSH Base and designated for the | field (M in Figure 1, as part of NSH Base and designated for the | |||
| alternate marking performance measurement method [RFC8321]. The Mark | alternate marking performance measurement method | |||
| field MUST be set to 0 at initialization of NSH and ignored on the | [I-D.fioccola-rfc8321bis]. The Mark field MUST be set to 0 at | |||
| receipt when the method is not in use. The Mark field MUST NOT be | initialization of NSH and ignored on the receipt when the method is | |||
| used in defining forwarding and/or quality of service treatment of an | not in use. The Mark field MUST NOT be used in defining forwarding | |||
| SFC packet. The Mark field MUST be used only for the performance | and/or quality of service treatment of an SFC packet. The Mark field | |||
| measurement of data traffic in the SFC layer. Though the setting of | MUST be used only for the performance measurement of data traffic in | |||
| the field to any value likely not affect forwarding and/or quality of | the SFC layer. Though the setting of the field to any value likely | |||
| service treatment of a packet, the alternate marking method in the | not affect forwarding and/or quality of service treatment of a | |||
| SFC layer is characterized as an example of a hybrid performance | packet, the alternate marking method in the SFC layer is | |||
| measurement method according to [RFC7799]. | characterized as an example of a hybrid performance measurement | |||
| method according to [RFC7799]. | ||||
| 4. Theory of Operation | 4. Theory of Operation | |||
| The marking method can be successfully used in the SFC. Without | The marking method can be successfully used in the SFC. Without | |||
| limiting any generality consider SFC presented in Figure 2. Any | limiting any generality consider SFC presented in Figure 2. Any | |||
| combination of markings, Loss and/or Delay, can be applied to a | combination of markings, Loss and/or Delay, can be applied to a | |||
| service flow by any SFC component at either ingress or egress point | service flow by any SFC component at either ingress or egress point | |||
| to perform node, link, segment, or E2E measurement to detect | to perform node, link, segment, or E2E measurement to detect | |||
| performance degradation defects and localize them efficiently. | performance degradation defects and localize them efficiently. | |||
| skipping to change at page 5, line 7 ¶ | skipping to change at page 5, line 13 ¶ | |||
| of the Mark field to 0. | of the Mark field to 0. | |||
| Using the marking method, a component of the SFC creates distinct | Using the marking method, a component of the SFC creates distinct | |||
| sub-flows in the particular service traffic over SFC. Each sub-flow | sub-flows in the particular service traffic over SFC. Each sub-flow | |||
| consists of consecutive blocks that are unambiguously recognizable by | consists of consecutive blocks that are unambiguously recognizable by | |||
| a monitoring point at any component of the SFC and can be measured to | a monitoring point at any component of the SFC and can be measured to | |||
| calculate packet loss and/or packet delay metrics. | calculate packet loss and/or packet delay metrics. | |||
| 4.1. Single Mark Enabled Measurement | 4.1. Single Mark Enabled Measurement | |||
| As explained in the [RFC8321], marking can be applied to delineate | As explained in the [I-D.fioccola-rfc8321bis], marking can be applied | |||
| blocks of packets based either on the equal number of packets in a | to delineate blocks of packets based either on the equal number of | |||
| block or based on the same time interval. The latter method offers | packets in a block or based on the same time interval. The latter | |||
| better control as it allows a better account for capabilities of | method offers better control as it allows a better account for | |||
| downstream nodes to report statistics related to batches of packets | capabilities of downstream nodes to report statistics related to | |||
| and, at the same time, time resolution that affects defect detection | batches of packets and, at the same time, time resolution that | |||
| interval. | affects defect detection interval. | |||
| The Mark flag is used to create distinctive flows to measure the | The Mark flag is used to create distinctive flows to measure the | |||
| packet loss by switching the value of the Mark flag every N-th packet | packet loss by switching the value of the Mark flag every N-th packet | |||
| or at specified time intervals. Delay metrics MAY be calculated with | or at specified time intervals. Delay metrics MAY be calculated with | |||
| the alternate flow using any of the following methods: | the alternate flow using any of the following methods: | |||
| * First/Last Packet Delay calculation: whenever the marking, i.e., | * First/Last Packet Delay calculation: whenever the marking, i.e., | |||
| the value of Mark flag changes a component of the SFC can store | the value of Mark flag changes a component of the SFC can store | |||
| the timestamp of the first/last packet of the block. The | the timestamp of the first/last packet of the block. The | |||
| timestamp can be compared with the timestamp of the packet that | timestamp can be compared with the timestamp of the packet that | |||
| skipping to change at page 7, line 11 ¶ | skipping to change at page 7, line 19 ¶ | |||
| +--------------+-------------+---------------+ | +--------------+-------------+---------------+ | |||
| Table 1: Mark field of SFC NSH | Table 1: Mark field of SFC NSH | |||
| 6. Security Considerations | 6. Security Considerations | |||
| This document defines the use of AMM in an SFC domain and thus all | This document defines the use of AMM in an SFC domain and thus all | |||
| security considerations specific to SFC discussed in [RFC7665] and | security considerations specific to SFC discussed in [RFC7665] and | |||
| [RFC8300] are applicable. By introducing AMM into the SFC | [RFC8300] are applicable. By introducing AMM into the SFC | |||
| environment, it inherits all security considerations discussed in | environment, it inherits all security considerations discussed in | |||
| [RFC8321]. A new Mark flag is defined in this specification to be | [I-D.fioccola-rfc8321bis]. A new Mark flag is defined in this | |||
| used by AMM. Processing of AMM does require additional computational | specification to be used by AMM. Processing of AMM does require | |||
| resources and creates a certain amount of state information per AMM | additional computational resources and creates a certain amount of | |||
| flow performance metrics. An implementation MUST provide control | state information per AMM flow performance metrics. An | |||
| over the number of concurrent AMM flows that a node process. | implementation MUST provide control over the number of concurrent AMM | |||
| flows that a node process. | ||||
| 7. Acknowledgment | 7. Acknowledgment | |||
| TBD | TBD | |||
| 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>. | ||||
| [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>. | |||
| [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., | [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., | |||
| "Network Service Header (NSH)", RFC 8300, | "Network Service Header (NSH)", RFC 8300, | |||
| DOI 10.17487/RFC8300, January 2018, | DOI 10.17487/RFC8300, January 2018, | |||
| <https://www.rfc-editor.org/info/rfc8300>. | <https://www.rfc-editor.org/info/rfc8300>. | |||
| 8.2. Informative References | 8.2. Informative References | |||
| [I-D.ietf-sfc-ioam-nsh] | [I-D.ietf-sfc-ioam-nsh] | |||
| Brockners, F. and S. Bhandari, "Network Service Header | Brockners, F. and S. Bhandari, "Network Service Header | |||
| (NSH) Encapsulation for In-situ OAM (IOAM) Data", Work in | (NSH) Encapsulation for In-situ OAM (IOAM) Data", Work in | |||
| Progress, Internet-Draft, draft-ietf-sfc-ioam-nsh-06, 31 | Progress, Internet-Draft, draft-ietf-sfc-ioam-nsh-07, 31 | |||
| July 2021, <https://datatracker.ietf.org/doc/html/draft- | January 2022, <https://datatracker.ietf.org/doc/html/ | |||
| ietf-sfc-ioam-nsh-06>. | draft-ietf-sfc-ioam-nsh-07>. | |||
| [I-D.mizrahi-ippm-compact-alternate-marking] | [I-D.mizrahi-ippm-compact-alternate-marking] | |||
| Mizrahi, T., Arad, C., Fioccola, G., Cociglio, M., Chen, | Mizrahi, T., Arad, C., Fioccola, G., Cociglio, M., Chen, | |||
| M., Zheng, L., and G. Mirsky, "Compact Alternate Marking | M., Zheng, L., and G. Mirsky, "Compact Alternate Marking | |||
| Methods for Passive and Hybrid Performance Monitoring", | Methods for Passive and Hybrid Performance Monitoring", | |||
| Work in Progress, Internet-Draft, draft-mizrahi-ippm- | Work in Progress, Internet-Draft, draft-mizrahi-ippm- | |||
| compact-alternate-marking-05, 6 July 2019, | compact-alternate-marking-05, 6 July 2019, | |||
| <https://datatracker.ietf.org/doc/html/draft-mizrahi-ippm- | <https://datatracker.ietf.org/doc/html/draft-mizrahi-ippm- | |||
| compact-alternate-marking-05>. | compact-alternate-marking-05>. | |||
| [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function | [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function | |||
| Chaining (SFC) Architecture", RFC 7665, | Chaining (SFC) Architecture", RFC 7665, | |||
| DOI 10.17487/RFC7665, October 2015, | DOI 10.17487/RFC7665, October 2015, | |||
| <https://www.rfc-editor.org/info/rfc7665>. | <https://www.rfc-editor.org/info/rfc7665>. | |||
| [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with | [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with | |||
| Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, | Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, | |||
| May 2016, <https://www.rfc-editor.org/info/rfc7799>. | May 2016, <https://www.rfc-editor.org/info/rfc7799>. | |||
| [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>. | ||||
| [RFC8924] Aldrin, S., Pignataro, C., Ed., Kumar, N., Ed., Krishnan, | [RFC8924] Aldrin, S., Pignataro, C., Ed., Kumar, N., Ed., Krishnan, | |||
| R., and A. Ghanwani, "Service Function Chaining (SFC) | R., and A. Ghanwani, "Service Function Chaining (SFC) | |||
| Operations, Administration, and Maintenance (OAM) | Operations, Administration, and Maintenance (OAM) | |||
| Framework", RFC 8924, DOI 10.17487/RFC8924, October 2020, | Framework", RFC 8924, DOI 10.17487/RFC8924, October 2020, | |||
| <https://www.rfc-editor.org/info/rfc8924>. | <https://www.rfc-editor.org/info/rfc8924>. | |||
| Authors' Addresses | Authors' Addresses | |||
| Greg Mirsky | Greg Mirsky | |||
| Ericsson | Ericsson | |||
| End of changes. 19 change blocks. | ||||
| 52 lines changed or deleted | 56 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/ | ||||