< 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/