rfc9571xml2.original.xml   rfc9571.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.13 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]> ]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-mpls-rfc6374-sfl-10" number="9571" obsoletes="" updates=""
submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="
true"
sortRefs="true" symRefs="true" version="3">
<?rfc toc="yes"?> <!-- xml2rfc v2v3 conversion 3.6.0 -->
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes"?>
<rfc docName="draft-ietf-mpls-rfc6374-sfl-10" category="std">
<front> <front>
<title abbrev="RFC6374-SFL">RFC6374 Synonymous Flow Labels</title> <title abbrev="SFL">Extension of RFC 6374-Based Performance Measurement Usin
g Synonymous Flow Labels</title>
<author initials="S." surname="Bryant (Ed)" fullname="Stewart Bryant"> <seriesInfo name="RFC" value="9571"/>
<organization>Futurewei Technologies Inc.</organization> <author initials="S." surname="Bryant" fullname="Stewart Bryant" role="edito
r">
<organization>University of Surrey</organization>
<address> <address>
<email>sb@stewartbryant.com</email> <email>sb@stewartbryant.com</email>
</address> </address>
</author> </author>
<author initials="G." surname="Swallow" fullname="George Swallow"> <author initials="G." surname="Swallow" fullname="George Swallow">
<organization>Southend Technical Center</organization> <organization>Independent</organization>
<address> <address>
<email>swallow.ietf@gmail.com</email> <email>swallow.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author initials="M." surname="Chen" fullname="Mach Chen"> <author initials="M." surname="Chen" fullname="Mach(Guoyi) Chen">
<organization>Huawei</organization> <organization>Huawei</organization>
<address> <address>
<email>mach.chen@huawei.com</email> <email>mach.chen@huawei.com</email>
</address> </address>
</author> </author>
<author initials="G." surname="Fioccola" fullname="Giuseppe Fioccola"> <author initials="G." surname="Fioccola" fullname="Giuseppe Fioccola">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<email>giuseppe.fioccola@huawei.com</email> <email>giuseppe.fioccola@huawei.com</email>
</address> </address>
</author> </author>
<author initials="G." surname="Mirsky" fullname="Gregory Mirsky"> <author initials="G." surname="Mirsky" fullname="Gregory Mirsky">
<organization>ZTE Corp.</organization> <organization>ZTE Corp.</organization>
<address> <address>
<email>gregimirsky@gmail.com</email> <email>gregimirsky@gmail.com</email>
</address> </address>
</author> </author>
<date year="2024" month="May"/>
<workgroup>MPLS</workgroup>
<date year="2021" month="March" day="05"/> <keyword>Performance Measurement</keyword>
<keyword>OAM</keyword>
<workgroup>MPLS Working Group</workgroup>
<abstract> <abstract>
<t>RFC 6374 describes methods of making loss and delay measurements on
<t>RFC 6374 describes methods of making loss and delay measurements on Label Switched Paths (LSPs) primarily as they are used in MPLS Transport
Label Switched Paths (LSPs) primarily as used in MPLS Transport Profile (MPLS-TP Profile (MPLS-TP) networks. This document describes a method of
) extending the performance measurements (specified in RFC 6374) from
networks. This document describes a method of extending RFC 6374 performance flows carried over MPLS-TP to flows carried over generic MPLS LSPs. In
measurements from flows carried over MPLS-TP to flows carried over generic MPLS particular, it extends the technique to allow loss and delay
LSPs. measurements to be made on multipoint-to-point LSPs and introduces some
In particular, it extends additional techniques to allow more sophisticated measurements to be
the technique to allow loss and delay measurements to be made on multi-point to made in both MPLS-TP and generic MPLS networks.</t>
point
LSPs and introduces some additional techniques to allow more sophisticated
measurements to be made in both MPLS-TP and generic MPLS networks.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default">
<section anchor="introduction" title="Introduction"> <name>Introduction</name>
<t><xref target="RFC6374" format="default"/> was originally designed for u
<t><xref target="RFC6374"/> was originally designed for use as an Operations, Ad se as an Operations, Administration, and
ministration, and
Maintenance (OAM) protocol Maintenance (OAM) protocol
for use with MPLS Transport Profile (MPLS-TP) <xref target="RFC5921"/> LSPs. MPL for use with MPLS Transport Profile (MPLS-TP) <xref target="RFC5921" format="def
S-TP only ault"/> LSPs. MPLS-TP only
supports point-to-point and point-to-multi-point LSPs. This document describes supports point-to-point and point-to-multipoint LSPs. This document describes
how to use RFC6374 in the generic MPLS case, and also introduces a number how to use <xref target="RFC6374" format="default"/> in the generic MPLS case an
d also introduces a number
of more sophisticated measurements of applicability to both cases.</t> of more sophisticated measurements of applicability to both cases.</t>
<t><xref target="RFC8372" format="default"/> describes the requirement for
introducing
flow identities when using packet loss measurements described in <xref target="R
FC6374" format="default"/>.
<t><xref target="RFC8372"/> describes the requirement for introducing In summary, <xref target="RFC6374" format="default"/> describes use of the loss
flow identities when using RFC6374 <xref target="RFC6374"/> packet Loss Measurem measurement (LM) message as the
ents
(LM). In summary RFC6374 uses the loss-measurement (LM) packet as the
packet accounting packet accounting
demarcation point. Unfortunately this gives rise to a number of demarcation point. Unfortunately, this gives rise to a number of
problems that may lead to significant packet accounting errors in problems that may lead to significant packet accounting errors in
certain situations. For example:</t> certain situations. For example:</t>
<ol spacing="normal" type="1"><li>Where a flow is subjected to Equal-Cost
<t><list style="numbers"> Multipath (ECMP)
<t>Where a flow is subjected to Equal Cost Multi-Path (ECMP) treatment, packets can arrive out of order with respect to the LM
treatment packets can arrive out of order with respect to the LM packet.</li>
packet.</t> <li>Where a flow is subjected to ECMP treatment, packets can arrive
<t>Where a flow is subjected to ECMP treatment, packets can arrive
at different hardware interfaces, thus requiring reception of an at different hardware interfaces, thus requiring reception of an
LM packet on one interface to trigger a packet accounting action LM packet on one interface to trigger a packet accounting action
on a different interface which may not be co-located with it. on a different interface that may not be co-located with it.
This is a difficult technical problem to address with the This is a difficult technical problem to address with the
required degree of accuracy.</t> required degree of accuracy.</li>
<t>Even where there is no ECMP (for example on RSVP-TE, MPLS-TP LSPs <li>Even where there is no ECMP (for example, on RSVP-TE, MPLS-TP LSPs,
and pseudowires(PWs)) local processing may be distributed over a number of and pseudowires (PWs)), local processing may be distributed over a number of
processor cores, leading to synchronization problems.</t> processor cores, leading to synchronization problems.</li>
<t>Link aggregation techniques <xref target="RFC7190"/> may also lead to synch <li>Link aggregation techniques <xref target="RFC7190" format="default"/
ronization > may also lead to synchronization
issues.</t> issues.</li>
<t>Some forwarder implementations have a long pipeline between <li>Some forwarder implementations have a long pipeline between
processing a packet and incrementing the associated counter, again processing a packet and incrementing the associated counter, again
leading to synchronization difficulties.</t> leading to synchronization difficulties.</li>
</list></t> </ol>
<t>An approach to mitigating these synchronization issue is described in <t>An approach to mitigating these synchronization issues is described in
<xref target="RFC8321"/> in which packets are <xref target="RFC9341" format="default"/> -- the packets are
batched by the sender and each batch is marked in some way such that batched by the sender, and each batch is marked in some way such that
adjacent batches can be easily recognized by the receiver.</t> adjacent batches can be easily recognized by the receiver.</t>
<t>An additional problem arises where the LSP is a multipoint-to-point
<t>An additional problem arises where the LSP is a multi-point to point LSP since MPLS does not include a source address in the packet.
LSP, since MPLS does not include a source address in the packet.
Network management operations require the measurement of packet loss Network management operations require the measurement of packet loss
between a source and destination. It is thus necessary to introduce between a source and destination. It is thus necessary to introduce
some source specific information into the packet to identify packet some source-specific information into the packet to identify packet
batches from a specific source.</t> batches from a specific source.</t>
<t><xref target="RFC8957" format="default"/> describes a method of encodin
<t><xref target="RFC8957"/> describes a method of encoding per flow g per-flow
instructions in an MPLS label stack using a technique called instructions in an MPLS label stack using a technique called
Synonymous Flow Labels (SFL) in which labels which mimic the Synonymous Flow Labels (SFLs), in which labels that mimic the
behavior of other labels provide the packet batch identifiers and behavior of other labels provide the packet batch identifiers and
enable the per batch packet accounting. This memo specifies how SFLs enable the per-batch packet accounting. This memo specifies how SFLs
are used to perform RFC6374 packet loss and RFC6374 delay measurements.</t> are used to perform packet loss and delay measurements as described in <xref tar
get="RFC6374" format="default"/>.</t>
</section> <t>
<section anchor="requirements-language" title="Requirements Language"> When the terms "performance measurement method," "Query," "packet," or "messag
e" are used in this document,
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, they refer to a performance measurement method, Query, packet, or message as s
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and pecified in <xref
“OPTIONAL” in this document are to be interpreted as described in BCP 14 target="RFC6374"/>. </t> </section> <section anchor="requirements-language"
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appe numbered="true" toc="default"> <name>Requirements Language</name>
ar in all <t>
capitals, as shown here.</t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
</section> NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
<section anchor="rfc6374-packet-loss-measurement-with-sfl" title="RFC6374 Packet RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
Loss Measurement with SFL"> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
<t>The data service packets of the flow being instrumented are grouped described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
<section anchor="rfc6374-packet-loss-measurement-with-sfl" numbered="true" t
oc="default">
<name>Packet Loss Measurement Using SFL</name>
<t>The data service packets of the flow being instrumented are grouped
into batches, and all the packets within a batch are marked with into batches, and all the packets within a batch are marked with
the SFL <xref target="RFC8372"/> corresponding to that batch. the SFL <xref target="RFC8372" format="default"/> corresponding to that batch.
The sender counts the number of packets in the batch. When the The sender counts the number of packets in the batch. When the
batch has completed and the sender is confident that all of the batch has completed and the sender is confident that all of the
packets in that batch will have been received, the sender issues packets in that batch will have been received, the sender issues
an RFC6374 Query message to determine the number actually a Query message to determine the number actually
received and hence the number of packets lost. The RFC6374 received and hence the number of packets lost. The
Query message is sent using the same SFL as the corresponding batch of Query message is sent using the same SFL as the corresponding batch of
data service packets. The format of the Query and Response packets is data service packets. The format of the Query and Response packets is
described in <xref target="RFC6374SFL"/>.</t> described in <xref target="sec-RFC6374SFL" format="default"/>.</t>
</section>
</section> <section anchor="SPD" numbered="true" toc="default">
<section anchor="SPD" title="RFC6374 Single Packet Delay Measurement"> <name>Single Packet Delay Measurement Using SFL</name>
<t><xref target="RFC6374" format="default"/> describes how to measure the
<t>RFC6374 describes how to measure the packet delay by measuring the packet delay by measuring the
transit time of an RFC6374 packet over an LSP. Such a packet may not transit time of a packet over an LSP. Such a packet may not
need to be carried over an SFL since the delay over a particular LSP need to be carried over an SFL since the delay over a particular LSP
should be a function of the Traffic Class (TC) bits.</t> should be a function of the Traffic Class (TC) bits.</t>
<t>However, where SFLs are being used to monitor packet loss or where
<t>However, where SFLs are being used to monitor packet loss or where label-inferred scheduling is used <xref target="RFC3270" format="default"/>, the
label inferred scheduling is used <xref target="RFC3270"/> then n
the SFL would be REQUIRED to ensure that the RFC6374 packet the SFL would be <bcp14>REQUIRED</bcp14> to ensure that the packet
which was being used as a proxy for a data service packet experienced that was being used as a proxy for a data service packet experienced
a representative delay. The format of an a representative delay. The format of a packet carried over the LSP using an SFL
RFC6374 packet carried over the LSP using an SFL is shown in <xref target="RFC63 is shown in <xref target="sec-RFC6374SFL" format="default"/>.</t>
74SFL"/>.</t> </section>
<section anchor="data-service-packet-delay-measurement" numbered="true" toc=
</section> "default">
<section anchor="data-service-packet-delay-measurement" title="Data Service Pack <name>Data Service Packet Delay Measurement</name>
et Delay Measurement"> <t>Where it is desired to more thoroughly instrument a packet flow and to
determine the delay of a number of packets, it is undesirable to
<t>Where it is desired to more thoroughly instrument a packet flow and to send a large number of packets acting as proxy data service
determine the delay of a number of packets it is undesirable to packets (see <xref target="SPD" format="default"/>). A method of directly measur
send a large number of RFC6374 packets acting as a proxy data service ing the delay characteristics
packets (see <xref target="SPD"/>). A method of directly measuring the delay cha
racteristics
of a batch of packets is therefore needed.</t> of a batch of packets is therefore needed.</t>
<t>Given the long intervals over which it is necessary to measure packet
<t>Given the long intervals over which it is necessary to measure packet
loss, it is not necessarily the case that the batch times for the two loss, it is not necessarily the case that the batch times for the two
measurement types would be identical. Thus, we use a technique that measurement types would be identical. Thus, we use a technique that
permits the two measurements are made concurrently and yet relatively permits the two measurements to be made concurrently and yet relatively
independent from each other. The notion that they are relatively independently from each other. The notion that they are relatively
independent arises from the potential for the two batches to overlap in time, independent arises from the potential for the two batches to overlap in time,
in which case either the delay batch time will need to be cut short or the loss in which case either the delay batch time will need to be cut short or the loss
time will need to be extended to allow correct reconciliation of the time will need to be extended to allow correct reconciliation of the
various counters.</t> various counters.</t>
<t>The problem is illustrated in <xref target="fig1"/>.</t>
<t>The problem is illustrated in <xref target="FIGDM"/> below:</t> <figure anchor="fig1">
<name>Query Packet with SFL</name>
<figure title="RFC6734 Query Packet with SFL" anchor="FIGDM"><artwork><![CDATA[ <artwork>
(1) AAAAAAAAAABBBBBBBBBBAAAAAAAAAABBBBBBBBBB (Case 1) AAAAAAAAAABBBBBBBBBBAAAAAAAAAABBBBBBBBBB
SFL Marking of a packet batch for loss measurement SFL marking of a packet batch for loss measurement
(2) AADDDDAAAABBBBBBBBBBAAAAAAAAAABBBBBBBBBB (Case 2) AADDDDAAAABBBBBBBBBBAAAAAAAAAABBBBBBBBBB
SFL Marking of a subset of the packets for delay SFL marking of a subset of the packets for delay
(3) AAAAAAAADDDDBBBBBBBBAAAAAAAAAABBBBBBBBBB (Case 3) AAAAAAAADDDDBBBBBBBBAAAAAAAAAABBBBBBBBBB
SFL Marking of a subset of the packets across a SFL marking of a subset of the packets across a packet loss
packet loss measurement boundary measurement boundary
(4) AACDCDCDAABBBBBBBBBBAAAAAAAAAABBBBBBBBBB (Case 4) AACDCDCDAABBBBBBBBBBAAAAAAAAAABBBBBBBBBB
The case of multiple delay measurements within A case of multiple delay measurements within a packet loss
a packet loss measurement measurement
A & B are packets where loss is being measured where
C & D are pacekts where loss and delay is being measured A and B are packets where loss is being measured.
]]></artwork></figure> C and D are packets where loss and delay are being measured.
</artwork></figure>
<t>In case 1 of <xref target="FIGDM"/> we show the case where loss measurement a lone <t>In Case 1, we show where loss measurement alone
is being carried out on the flow under analysis. For illustrative is being carried out on the flow under analysis. For illustrative
purposes consider that 10 packets are used in each flow in the purposes, consider that 10 packets are used in each flow in the
time interval being analyzed.</t> time interval being analyzed.</t>
<t>Now consider Case 2, where a small batch of
<t>Now consider case 2 of <xref target="FIGDM"/> where a small batch of
packets need to be analyzed for delay. These are marked with a different packets need to be analyzed for delay. These are marked with a different
SFL type indicating that they are to be monitored for both loss SFL type, indicating that they are to be monitored for both loss
and delay. The SFL=A indicates loss batch A, SFL=D indicates a batch and delay. The SFL=A indicates loss batch A, and SFL=D indicates a batch
of packets that are to be instrumented for delay, but SFL D is of packets that are to be instrumented for delay, but SFL D is
synonymous with SFL A, which in turn is synonymous with the underlying synonymous with SFL A, which in turn is synonymous with the underlying
Forwarding Equivalence Class (FEC). Thus, a packet marked D will be accumulated Forwarding Equivalence Class (FEC). Thus, a packet marked "D" will be accumulate
into the A loss d into the A loss
batch, into the delay statistics and will be forwarded as normal. batch, into the delay statistics, and will be forwarded as normal.
Whether the packet is actually counted twice (for loss and delay) Whether the packet is actually counted twice (for loss and delay)
or whether the two counters are reconciled during reporting is or whether the two counters are reconciled during reporting is
a local matter.</t> a local matter.</t>
<t>Now consider Case 3, where a small batch of packets
<t>Now consider case 3 of <xref target="FIGDM"/> where a small batch of packets is marked for delay across a loss batch boundary. These packets
are marked for delay across a loss batch boundary. These packets need to be considered as a part of batch A or a part of batch B, and
need to be considered as part of batch A or a part of batch B, and any Query needs to take place after all packets
any RFC6374 Query needs to take place after all the packets A or D (whichever option is chosen) have arrived at the receiving Label Switchin
A or D (whichever option is chosen) have arrived at the receiving LSR.</t> g Router (LSR).</t>
<t>Now consider Case 4. Here, we have a case where
<t>Now consider case 4 of <xref target="FIGDM"/>. Here we have a case where
it is required to take a number of delay measurements within it is required to take a number of delay measurements within
a batch of packets that we are measuring for loss. To do this a batch of packets that we are measuring for loss. To do this,
we need two SFLs for delay (C and D) and alternate between we need two SFLs for delay (C and D) and alternate between
them (on a delay batch by delay batch basis) for the purposes of them (on a delay-batch-by-delay-batch basis) for the purposes of
measuring the delay characteristics of the different batches of packets.</t> measuring the delay characteristics of the different batches of packets.</t>
</section>
</section> <section anchor="some-simplifying-rules" numbered="true" toc="default">
<section anchor="some-simplifying-rules" title="Some Simplifying Rules"> <name>Some Simplifying Rules</name>
<t>It is possible to construct a large set of overlapping measurement
<t>It is possible to construct a large set of overlapping measurement types in terms of loss, delay, loss and delay, and batch overlap. If
types, in terms of loss, delay, loss and delay and batch overlap. If
we allow all combinations of cases, this leads to configuration, we allow all combinations of cases, this leads to configuration,
testing and implementation complexity and hence increased costs. testing, and implementation complexity and, hence, increased costs.
The following simplifying rules represent the The following simplifying rules represent the
default case:</t> default case:</t>
<ol spacing="normal" type="1"><li>Any system that needs to measure delay <
<t><list style="numbers"> bcp14>MUST</bcp14> be able to
<t>Any system that needs to measure delay MUST be able to measure loss.</li>
measure loss.</t> <li>Any system that is to measure delay <bcp14>MUST</bcp14> be configure
<t>Any system that is to measure delay MUST be configured to d to
measure loss. Whether the loss statistics are collected measure loss. Whether the loss statistics are collected
or not is a local matter.</t> or not is a local matter.</li>
<t>A delay measurement MAY start at any point during a loss measurement <li>A delay measurement <bcp14>MAY</bcp14> start at any point during a l
batch, subject to rule 4.</t> oss measurement
<t>A delay measurement interval MUST be short enough that it batch, subject to rule 4.</li>
will complete before the enclosing loss batch completes.</t> <li>A delay measurement interval <bcp14>MUST</bcp14> be short enough tha
<t>The duration of a second delay (D in <xref target="FIGDM"/> batch must be s t it
uch will complete before the enclosing loss batch completes.</li>
<li>The duration of a second delay batch (D in <xref target="fig1"/>) mu
st be such
that all packets from the packets belonging to a first that all packets from the packets belonging to a first
delay batch (C in <xref target="FIGDM"/>)will have been received before delay batch (C in <xref target="fig1"/>) will have been received before
the second delay batch completes. This condition is satisfied the second delay batch completes. This condition is satisfied
when the time to send a batch is long compared to the network when the time to send a batch is long compared to the network
propagation time, and is a parameter that can be established propagation time and is a parameter that can be established
by the network operator.</t> by the network operator.</li>
</list></t> </ol>
<t>Given that the sender controls both the start and duration of
<t>Given that the sender controls both the start and duration of
a loss and a delay packet batch, these rules are readily implemented a loss and a delay packet batch, these rules are readily implemented
in the control plane.</t> in the control plane.</t>
</section>
</section> <section anchor="multiple-packet-delay-characteristics" numbered="true" toc=
<section anchor="multiple-packet-delay-characteristics" title="Multiple Packet D "default">
elay Characteristics"> <name>Multiple Packet Delay Characteristics</name>
<t>A number of methods are described that add to the set of measurements
<t>A number of methods are described which add to the set of measurements originally specified in <xref target="RFC6374" format="default"/>. Each of these
originally specified in <xref target="RFC6374"/>. Each of these methods has diff methods has different
erent
characteristics and different processing demands on the packet forwarder. characteristics and different processing demands on the packet forwarder.
The choice of method will depend on the type of diagnostic that the operator see ks.</t> The choice of method will depend on the type of diagnostic that the operator see ks.</t>
<t>Three methods are discussed:</t>
<ol spacing="normal" type="1"><li>Time Buckets</li>
<li>Classic Standard Deviation</li>
<li>Average Delay</li>
</ol>
<section anchor="method-1-time-buckets" numbered="true" toc="default">
<name>Method 1: Time Buckets</name>
<t>Three Methods are discussed:</t> <t>In this method, the receiving LSR measures the inter-packet gap, classifies
the
<t><list style="numbers"> delay into a number of delay buckets, and records the number of packets
<t>Time Buckets</t> in each bucket.
<t>Classic Standard Deviation</t> As an example, if the operator were concerned about packets with a delay of
<t>Average Delay</t> up to 1 μs, 2 μs, 4 μs, 8 μs, and over 8 μs, then there would be five
</list></t> buckets, and packets that arrived up to 1 μs would cause the "up to 1 μs"
bucket counter to increase. Likewise, for those that arrived between 1 μs and
<section anchor="method-1-time-buckets" title="Method 1: Time Buckets"> 2 μs, the "2 μs" bucket counter would increase, etc. In practice, it
might be better in terms of processing and potential parallelism if both the "
<t>In this method the receiving LSR measures the inter-packet gap, classifies th up to 1 μs" and "2 μs" counters were incremented when a packet had
e a delay relative to its predecessor of 2 μs, and any more detailed information w
delay into a number of delay buckets and records the number of packets as calculated in the analytics
in each bucket. As an example, if the operator were concerned about packets with
a delay of up to 1us, 2us, 4us, 8us, and over 8us then there would be five bucke
ts
and packets that arrived up to 1us would cause the 1us bucket counter to increas
e,
between 1us and 2us the 2us bucket counter would increase etc. In practice it
might be better in terms of processing and potential parallelism if, when a pack
et had
a delay relative to its predecessor of 2us, then both the up to 1us and the 2us
counter
were incremented, and any more detailed information was calculated in the analyt
ics
system.</t> system.</t>
<t>This method allows the operator to see more structure in the jitter c
<t>This method allows the operator to see more structure in the jitter character haracteristics
istics than simply measuring the average jitter and avoids the complication of needing
than simply measuring the average jitter, and avoids the complication of needing to perform a per-packet multiply but will probably need the time intervals betwe
to perform a per packet multiply, but will probably need the time intervals betw en
een
buckets to be programmable by the operator.</t> buckets to be programmable by the operator.</t>
<t>The packet format of a Time Bucket Jitter Measurement message
<t>The packet format of a Time Bucket Jitter Measurement Message
is shown below:</t> is shown below:</t>
<figure title="Time Bucket Jitter Measurement Message Format" anchor="FIGBucket" <figure anchor="FIGBucket">
><artwork><![CDATA[ <name>Time Bucket Jitter Measurement Message Format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flags | Control Code | Message Length | |Version| Flags | Control Code | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QTF | RTF | RPTF | Reserved | | QTF | RTF | RPTF | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier | DS | | Session Identifier | DS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of | Reserved 1 | | Number of | Reserved 1 |
| Buckets | | | Buckets | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interval in 10ns units | | Interval (in 10 ns units) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number pkts in Bucket | | Number of Pkts in Bucket 1 |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~ ~ ~
~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Pkts in Bucket N |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~ ~ ~
~ TLV Block ~ ~ TLV Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure> ]]></artwork>
</figure>
<t>The Version, Flags, Control Code, Message Length, QTF, RTF, RPTF, <t>The Version, Flags, Control Code, Message Length, Querier Timestamp F
Session Identifier, Reserved and DS Fields are as defined in section 3.2 ormat (QTF), Responder Timestamp Format (RTF), Responder's Preferred Timestamp F
of RFC6374. The remaining fields, which are unsigned integers, are as follows:</ ormat (RPTF),
t> Session Identifier, Reserved, and Differentiated Services (DS) fields are as def
ined in <xref target="RFC6374" sectionFormat="of" section="3.2"/>. The remaining
<figure><artwork><![CDATA[ fields, which are unsigned integers, are as follows:</t>
o Number of Buckets in the measurement <ul empty="false">
<li>Number of Buckets in the measurement.</li>
o Reserved 1 must be sent as zero and ignored on receipt
o Interval in 10ns units is the inter-packet interval for <li>Reserved 1 must be sent as zero and ignored on receipt.</li>
this bucket
o Number Pkts in Bucket is the number of packets found in <li>Interval (in 10 ns units) is the inter-packet interval for
this bucket. this bucket.</li>
]]></artwork></figure>
<t>There will be a number of Interval/Number pairs depending on the <li>Number of Pkts in Bucket 1 is the number of packets found in
number of buckets being specified by the Querier. If an RFC6374 the first bucket.</li>
message is being used to configure the buckets, (i.e. the responder <li>Number of Pkts in Bucket N is the number of packets found in
is creating or modifying the buckets according to the intervals in the Nth bucket, where N is the value in the Number of Buckets field.</li>
the Query message), then the Responder </ul>
MUST respond with 0 packets in each bucket until it has been <t>There will be a number of Interval/Number pairs depending on the
number of buckets being specified by the Querier. If a message is being used to
configure the buckets (i.e., the responder
is creating or modifying the buckets according to the intervals in
the Query message), then the responder
<bcp14>MUST</bcp14> respond with 0 packets in each bucket until it has been
configured for a full measurement period. This indicates that it was configured configured for a full measurement period. This indicates that it was configured
at the time of the last response message, and thus the response at the time of the last response message, and thus, the response
is valid for the whole interval. As per the <xref target="RFC6374"/> convention is valid for the whole interval.
the Number of pkts in Bucket fields are included in the Query message and set
to zero.</t>
<t>Out of band configuration is permitted by this mode of operation.</t>
<t>Note this is a departure from the normal fixed format used in
RFC6374.</t>
<t>The time bucket jitter measurement message is carried over an LSP in the way
described in
<xref target="RFC6374"/> and over an LSP with an SFL as described in <xref targe
t="RFC6374SFL"/>.</t>
</section>
<section anchor="method-2-classic-standard-deviation" title="Method 2 Classic St
andard Deviation">
<t>In this method, provision is made for reporting the following delay As per the convention in <xref target="RFC6374" format="default"/>,
the Number of Pkts in Bucket fields are included in the Query message and set
to zero.</t>
<t>Out-of-band configuration is permitted by this mode of operation.</t>
<t>Note this is a departure from the normal fixed format used in
<xref target="RFC6374" format="default"/>.</t>
<t>The Time Bucket Jitter Measurement message is carried over an LSP in
the way described in
<xref target="RFC6374" format="default"/> and over an LSP with an SFL as describ
ed in <xref target="sec-RFC6374SFL" format="default"/>.</t>
</section>
<section anchor="method-2-classic-standard-deviation" numbered="true" toc=
"default">
<name>Method 2: Classic Standard Deviation</name>
<t>In this method, provision is made for reporting the following delay
characteristics:</t> characteristics:</t>
<ol spacing="normal" type="1"><li>Number of packets in the batch (n)</li
<t><list style="numbers"> >
<t>Number of packets in the batch (n).</t> <li>Sum of delays in a batch (S)</li>
<t>Sum of delays in a batch (S)</t> <li>Maximum delay</li>
<t>Maximum Delay.</t> <li>Minimum delay</li>
<t>Minimum Delay.</t> <li>Sum of squares of inter-packet delay (SumS)</li>
<t>Sum of squares of Inter-packet delay (SS).</t> </ol>
</list></t> <t>Characteristics 1 and 2 give the mean delay. Measuring the delay of e
ach
<t>Characteristics 1 and 2 give the mean delay. Measuring the delay of each pair in the batch is discussed in <xref target="PPDM" format="default"/>.</t>
pair in the batch is discussed in <xref target="PPDM"/>.</t> <t>Characteristics 3 and 4 give the outliers.</t>
<t>Characteristics 1, 2, and 5 can be used to calculate the variance of
<t>Characteristics 3 and 4 give the outliers.</t> the
inter-packet gap, hence the standard deviation giving a view of
<t>Characteristics 1, 2 and 5 can be used to calculate the variance of the
inter-packet gap and hence the standard deviation giving a view of
the distribution of packet delays and hence the jitter. The equation the distribution of packet delays and hence the jitter. The equation
for the variance (var) is given by:</t> for the variance (var) is given by:</t>
<artwork><![CDATA[
var = (SumS - S*S/n)/(n-1)
]]></artwork>
<figure><artwork><![CDATA[ <t>There is some concern over the use of this algorithm for measuring
var = (SS - S*S/n)/(n-1) variance because SumS and S*S/n can be similar numbers, particularly
]]></artwork></figure> where variance is low. However, the method is acceptable because it does
not require a division in the hardware.</t>
<t>There is some concern over the use of this algorithm for measuring <section anchor="multi-packet-delay-measurement-message-format" numbered
variance, because SS and S*S/n can be similar numbers, particularly ="true" toc="default">
where variance is low. However the method commends it self by not <name>Multi-packet Delay Measurement Message Format</name>
requiring a division in the hardware.</t> <t>The packet format of a Multi-packet Delay Measurement message
<section anchor="multi-packet-delay-measurement-message-format" title="Multi-Pac
ket Delay Measurement Message Format">
<t>The packet format of a Multi-Packet Delay Measurement Message
is shown below:</t> is shown below:</t>
<figure anchor="FIGMPM">
<figure title="Multi-packet Delay Measurement Message Format" anchor="FIGMPM"><a <name>Multi-packet Delay Measurement Message Format</name>
rtwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flags | Control Code | Message Length | |Version| Flags | Control Code | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QTF | RTF | RPTF | Reserved | | QTF | RTF | RPTF | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier | DS | | Session Identifier | DS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Packets | | Number of Packets |
skipping to change at line 438 skipping to change at line 410
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Delay | | Maximum Delay |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sum of squares of Inter-packet delay | | Sum of squares of Inter-packet delay |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~ ~ ~
~ TLV Block ~ ~ TLV Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure> ]]></artwork>
</figure>
<t>The Version, Flags, Control Code, Message Length, QTF, RTF, RPTF, <t>The Version, Flags, Control Code, Message Length, QTF, RTF, RPTF,
Session Identifier, Reserved and DS Fields are as defined in section 3.2 Session Identifier, Reserved, and DS fields are as defined in <xref target="RFC6
of RFC6374. The remaining fields are as follows:</t> 374" sectionFormat="of" section="3.2"/>. The remaining fields are as follows:</t
>
<figure><artwork><![CDATA[ <ul empty="false">
o Number of Packets is the number of packets in this batch <li>Number of Packets is the number of packets in this batch.</li>
o Sum of Delays for Batch is the duration of the batch in the
time measurement format specified in the RTF field.
o Minimum Delay is the minimum inter-packet gap observed during
the batch in the time format specified in the RTF field.
o Maximum Delay is the maximum inter-packet gap observed during
the batch in the time format specified in the RTF field.
]]></artwork></figure>
<t>The multi-packet delay measurement message is carried over an LSP in the way
described in
<xref target="RFC6374"/> and over an LSP with an SFL as described in <xref targe
t="RFC6374SFL"/>.</t>
</section>
</section>
<section anchor="PPDM" title="Per Packet Delay Measurement">
<t>If detailed packet delay measurement is required then it might be <li>Sum of Delays for Batch is the duration of the batch in the
possible to record the inter-packet gap for each packet pair. In other time measurement format specified in the RTF field.</li>
than exception cases of slow flows or small batch sizes, this would
create a large (per packet) demand on storage in the instrumentation system,
a large bandwidth to such a storage system and large bandwidth to the analytics
system. Such a measurement technique is outside the scope of this
document.</t>
</section> <li>Minimum Delay is the minimum inter-packet gap observed during
<section anchor="average-delay" title="Average Delay"> the batch in the time format specified in the RTF field.</li>
<t>Introduced in <xref target="RFC8321"/> is the concept of a one <li>Maximum Delay is the maximum inter-packet gap observed during
way delay measurement in which the average time of arrival of a the batch in the time format specified in the RTF field.</li>
set of packets is measured. In this approach the packet is time-stamped </ul>
at arrival and the Responder returns the sum of the time-stamps <t>The Multi-packet Delay Measurement message is carried over an LSP i
and the number of times-tamps. From this the analytics engine can n the way described in
determine the mean delay. An alternative model is that the Responder <xref target="RFC6374" format="default"/> and over an LSP with an SFL as describ
returns the time stamp of the first and last packet and the ed in <xref target="sec-RFC6374SFL" format="default"/>.</t>
number of packets. This later method has the advantage of allowing the </section>
</section>
<section anchor="PPDM" numbered="true" toc="default">
<name>Per-Packet Delay Measurement</name>
<t>If detailed packet delay measurement is required, then it might be
possible to record the inter-packet gap for each packet pair.
In cases other than the exceptions of slow flows or small batch sizes,
this would create a large (per-packet) demand on storage in the
instrumentation system, a large bandwidth for such a storage system and
large bandwidth for the analytics system.
Such a measurement technique is outside the scope of this document.</t>
</section>
<section anchor="average-delay" numbered="true" toc="default">
<name>Average Delay</name>
<t>Introduced in <xref target="RFC9341" format="default"/> is the concep
t of a one-way delay measurement in which the average time of arrival of a
set of packets is measured. In this approach, the packet is timestamped
at arrival, and the responder returns the sum of the timestamps
and the number of timestamps. From this, the analytics engine can
determine the mean delay. An alternative model is that the responder
returns the timestamp of the first and last packet and the
number of packets. This latter method has the advantage of allowing the
average delay to be determined at a number of points along the average delay to be determined at a number of points along the
packet path and allowing the components of the delay to be packet path and allowing the components of the delay to be
characterized. Unless specifically configured otherwise, the characterized. Unless specifically configured otherwise, the
responder may return either or both types of response and responder may return either or both types of response, and
the analytics engine should process the response appropriately.</t> the analytics engine should process the response appropriately.</t>
<t>The packet format of an Average Delay Measurement message
<t>The packet format of an Average Delay Measurement Message
is shown below:</t> is shown below:</t>
<figure anchor="FIGAD">
<figure title="Average Delay Measurement Message Format" anchor="FIGAD"><artwork <name>Average Delay Measurement Message Format</name>
><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flags | Control Code | Message Length | |Version| Flags | Control Code | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QTF | RTF | RPTF | Reserved | | QTF | RTF | RPTF | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier | DS | | Session Identifier | DS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Packets | | Number of Packets |
skipping to change at line 518 skipping to change at line 484
| Time of Last Packet | | Time of Last Packet |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sum of Timestamps of Batch | | Sum of Timestamps of Batch |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~ ~ ~
~ TLV Block ~ ~ TLV Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure> ]]></artwork>
</figure>
<t>The Version, Flags, Control Code, Message Length, QTF, RTF, RPTF, <t>The Version, Flags, Control Code, Message Length, QTF, RTF, RPTF,
Session Identifier, and DS Fields are as defined in section 3.2 Session Identifier, and DS fields are as defined in <xref target="RFC6374" secti
of RFC6374. The remaining fields are as follows:</t> onFormat="of" section="3.2"/>. The remaining fields are as follows:</t>
<ul empty="false">
<figure><artwork><![CDATA[ <li>Number of Packets is the number of packets in this batch.</li>
o Number of Packets is the number of packets in this batch.
o Time of First Packet is the time of arrival of the first
packet in the batch.
o Time of Last Packet is the time of arrival of the last <li>Time of First Packet is the time of arrival of the first
packet in the batch. packet in the batch.</li>
o Sum of Timestamps of Batch. <li>Time of Last Packet is the time of arrival of the last
]]></artwork></figure> packet in the batch.</li>
<t>The average delay measurement message <li>Sum of Timestamps of Batch.</li>
</ul>
<t>The Average Delay Measurement message
is carried over an LSP in the way described in is carried over an LSP in the way described in
<xref target="RFC6374"/> and over an LSP with an SFL as described in <xref targe <xref target="RFC6374" format="default"/> and over an LSP with an SFL as describ
t="RFC6374SFL"/>. ed in <xref target="sec-RFC6374SFL" format="default"/>.
As is the convention with RFC6374, the Query message contains placeholders As is the convention with <xref target="RFC6374" format="default"/>, the Query m
essage contains placeholders
for the Response message. The placeholders are sent as zero.</t> for the Response message. The placeholders are sent as zero.</t>
</section>
</section> </section>
</section> <section anchor="sampled-measurement" numbered="true" toc="default">
<section anchor="sampled-measurement" title="Sampled Measurement"> <name>Sampled Measurement</name>
<t>In the discussion so far, it has been assumed that we would measure
<t>In the discussion so far it has been assumed that we would measure
the delay characteristics of every packet in a delay measurement the delay characteristics of every packet in a delay measurement
interval defined by an SFL of constant color. interval defined by an SFL of constant color.
In <xref target="RFC8321"/> the concept of a sampled In <xref target="RFC9341" format="default"/>, the concept of a sampled
measurement is considered. That is the Responder only measures a packet measurement is considered. That is, the responder only measures a packet
at the start of a group of packets being marked for delay measurement at the start of a group of packets being marked for delay measurement
by a particular color, rather than every packet in the marked batch. by a particular color, rather than every packet in the marked batch.
A measurement A measurement
interval is not defined by the duration of a marked batch of packets interval is not defined by the duration of a marked batch of packets
but the interval between a pair of RFC6374 packets taking a readout but the interval between a pair of packets taking a readout
of the delay characteristic. This approach has the advantage that of the delay characteristic. This approach has the advantage that
the measurement is not impacted by ECMP effects.</t> the measurement is not impacted by ECMP effects.</t>
<t>This sampled approach may be used if supported by the responder and
<t>This sampled approach may be used if supported by the Responder and configured by the operator.</t>
configured by the opertor.</t> </section>
<section anchor="sec-RFC6374SFL" numbered="true" toc="default">
</section> <name>Carrying Packets over an LSP Using an SFL</name>
<section anchor="RFC6374SFL" title="Carrying RFC6374 Packets over an LSP using a <t>We illustrate the packet format of a Query message using SFLs
n SFL"> for the case of an MPLS Direct Loss Measurement in
<xref target="Figure1" format="default"/>.</t>
<t>We illustrate the packet format of an RFC6374 Query message using SFLs <figure anchor="Figure1">
for the case of an MPLS direct loss measurement in <name>Query Packet with SFL</name>
<xref target="Figure1"/>.</t> <artwork name="" type="" align="left" alt=""><![CDATA[
<figure title="RFC6734 Query Packet with SFL" anchor="Figure1"><artwork><![CDATA
[
+-------------------------------+ +-------------------------------+
| | | |
| LSP | | LSP |
| Label | | Label |
+-------------------------------+ +-------------------------------+
| | | |
| Synonymous Flow | | Synonymous Flow |
| Label | | Label |
+-------------------------------+ +-------------------------------+
| | | |
| GAL | | GAL |
| | | |
+-------------------------------+ +-------------------------------+
| | | |
| ACH Type = 0xA | | ACH Type = 0xA |
| | | |
+-------------------------------+ +-------------------------------+
| | | |
| RFC6374 Measurement Message | | Measurement Message |
| | | |
| +-------------------------+ | | +-------------------------+ |
| | | | | | | |
| | Fixed-format | | | | Fixed-format | |
| | portion of msg | | | | portion of msg | |
| | | | | | | |
| +-------------------------+ | | +-------------------------+ |
| | | | | | | |
| | Optional SFL TLV | | | | Optional SFL TLV | |
| | | | | | | |
| +-------------------------+ | | +-------------------------+ |
| | | | | | | |
| | Optional Return | | | | Optional Return | |
| | Information | | | | Information | |
| | | | | | | |
| +-------------------------+ | | +-------------------------+ |
| | | |
+-------------------------------+ +-------------------------------+
]]></artwork></figure> ]]></artwork>
</figure>
<t>The MPLS label stack is exactly the same as that used for the user <t>The MPLS label stack is exactly the same as that used for the user
data service packets being instrumented except for the inclusion data service packets being instrumented except for the inclusion
of the Generic Associated Channel Label (GAL) <xref target="RFC5586"/> to allow the receiver to distinguish between of the Generic Associated Channel Label (GAL) <xref target="RFC5586" format="def ault"/> to allow the receiver to distinguish between
normal data packets and OAM packets. Since the packet loss normal data packets and OAM packets. Since the packet loss
measurements are being made on the data service packets, measurements are being made on the data service packets,
an RFC6374 direct loss measurement is being made, an MPLS Direct Loss Measurement is being made,
and which is indicated by the type field in the ACH (Type = 0x000A).</t> which is indicated by the type field in the Associated Channel Header (ACH) (Typ
e = 0x000A).</t>
<t>The RFC6374 measurement message consists of the three components,
the RFC6374 fixed-format portion of the message as specified in <xref target="RF
C6374"/> carried over
the ACH channel type specified the type of measurement being
made (currently: loss, delay or loss and delay) as specified in RFC6374.</t>
<t>Two optional TLVs MAY also be carried if needed. The first is the
SFL TLV specified in <xref target="sfltlv"/>. This is used to provide the
implementation with a reminder of the SFL that was used to carry the
RFC6374 message. This is needed because a number of MPLS
implementations do not provide the MPLS label stack to the MPLS OAM
handler. This TLV is required if RFC6374 messages are sent over UDP
<xref target="RFC7876"/>. This TLV MUST be included unless, by some method outs
ide
the scope of this document, it is known that this information is not
needed by the RFC6374 Responder.</t>
<t>The second set of information that may be needed is the return
information that allows the responder send the RFC6374 response to
the Querier. This is not needed if the response is requested in-band
and the MPLS construct being measured is a point to point LSP, but
otherwise MUST be carried. The return address TLV is defined in
<xref target="RFC6374"/> and the optional UDP Return Object is defined in <xref
target="RFC7876"/>.</t>
<t>Where a measurement other than an MPLS direct loss measurement is to be <t>The measurement message consists of up to three components as follows.<
made, the appropriate RFC6374 measurement message is used (for example, one of t /t>
he <ul>
new types defined in this document) and this is indicated to the receiver <li>
<t>The fixed-format portion of the message is carried over the ACH
channel. The ACH channel type specifies the type of measurement
being made (currently: loss, delay, or loss and delay).</t>
</li>
<li>
<t>(Optional) The SFL TLV specified in <xref target="sfltlv"
format="default"/> <bcp14>MAY</bcp14> be carried if needed. It is
used to provide the implementation with a reminder of the SFL that
was used to carry the message. This is needed because a number of
MPLS implementations do not provide the MPLS label stack to the MPLS
OAM handler. This TLV is required if messages are sent over UDP
<xref target="RFC7876" format="default"/>. This TLV
<bcp14>MUST</bcp14> be included unless, by some method outside the
scope of this document, it is known that this information is not
needed by the responder.</t>
</li>
<li>
<t>(Optional) The Return Information <bcp14>MAY</bcp14> be carried if
needed. It allows the responder send the response to the Querier. This i
s not needed if the
response is requested in band and the MPLS construct being measured is
a point-to-point LSP, but it otherwise <bcp14>MUST</bcp14> be carried.
The Return Address TLV is defined in <xref target="RFC6374"
format="default"/>, and the optional UDP Return Object is defined in
<xref target="RFC7876" format="default"/>.</t>
</li>
</ul>
<t>Where a measurement other than an MPLS Direct Loss Measurement is to be
made, the appropriate measurement message is used (for example, one of the
new types defined in this document), and this is indicated to the receiver
by the use of the corresponding ACH type.</t> by the use of the corresponding ACH type.</t>
<section anchor="sfltlv" numbered="true" toc="default">
<name>Extending RFC 6374 with SFL TLV</name>
<t>The <xref target="RFC6374" format="default"/> SFL TLV is shown in <xr
ef target="Figure2" format="default"/>.
This contains the SFL that was carried in the label stack, the FEC that was
used to allocate the SFL, and the index (into the batch of SFLs that were
allocated for the FEC) that corresponds to this SFL.</t>
<section anchor="sfltlv" title="RFC6374 SFL TLV"> <figure anchor="Figure2">
<name>SFL TLV</name>
<t>The RFC6374 SFL TLV is shown in <xref target="Figure2"/>. This contains the <artwork name="" type="" align="left" alt=""><![CDATA[
SFL that was carried in the label stack, the FEC that was used to
allocate the SFL and the index into the batch of SLs that were
allocated for the FEC that corresponds to this SFL.</t>
<figure title="SFL TLV" anchor="Figure2"><artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |MBZ| SFL Batch | SFL Index | | Type | Length |MBZ| SFL Batch | SFL Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFL | Reserved | | SFL | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC | | FEC |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure> ]]></artwork>
</figure>
<t>Where:</t> <t>Where:</t>
<dl indent="15">
<figure><artwork><![CDATA[ <dt>Type</dt><dd> Set to Synonymous Flow Label (SFL-TLV).</dd>
Type Type is set to Synonymous Flow Label (SFL-TLV).
Length The length of the TLV as specified in RFC6374.
MBZ MUST be sent as zero and ignored on receive. <dt>Length</dt><dd> The length of the TLV is as specified in <xref target="RF C6374"/>.</dd>
SFL Batch The SFL batch that this SFL was allocated as part <dt>MBZ</dt><dd> <bcp14>MUST</bcp14> be sent as zero and ignored on receiv
of see [I-D.bryant-mpls-sfl-control] e.</dd>
SPL Index The index into the list of SFLs that were assigned <dt>SFL Batch</dt><dd> An identifier for a collection of SFLs grouped together f
against the FEC that corresponds to the SFL. or management and control purposes. </dd>
Multiple SFLs can be assigned to a FEC each <dt>SFL Index</dt><dd><t>The index of this SFL within the list of SFLs that were
assigned
for the FEC.</t>
<t> Multiple SFLs can be assigned to a FEC, each
with different actions. This index is an optional with different actions. This index is an optional
convenience for use in mapping between the TLV convenience for use in mapping between the TLV
and the associated data structures in the LSRs. and the associated data structures in the LSRs.
The use of this feature is agreed between the The use of this feature is agreed upon between the
two parties during configuration. It is not required, two parties during configuration. It is not required
but is a convenience for the receiver if both parties but is a convenience for the receiver if both parties
support the facility, support the facility.</t></dd>
SFL The SFL used to deliver this packet. This is an MPLS <dt>SFL</dt><dd>The SFL used to deliver this packet. This is an MPLS
label which is a component of a label stack entry as label that is a component of a label stack entry as
defined in Section 2.1 of [RFC3032]. defined in <xref target="RFC3032" sectionFormat="of" section="2.1"/>.<
/dd>
Reserved MUST be sent as zero and ignored on receive. <dt>Reserved</dt><dd> <bcp14>MUST</bcp14> be sent as zero and ignored on receiv e.</dd>
FEC The Forwarding Equivalence Class that was used to <dt>FEC</dt><dd> The Forwarding Equivalence Class that was used to
request this SFL. This is encoded as per request this SFL. This is encoded as per
Section 3.4.1 of [RFC5036] <xref target="RFC5036" sectionFormat="of" section="3.4.1"/>.</dd>
]]></artwork></figure> </dl>
<t>This information is needed to allow for operation with hardware that
<t>This information is needed to allow for operation with hardware that
discards the MPLS label stack before passing the remainder of the discards the MPLS label stack before passing the remainder of the
stack to the OAM handler. By providing both the SFL and the FEC plus stack to the OAM handler. By providing both the SFL and the FEC plus
index into the array of allocated SFLs a number of implementation index into the array of allocated SFLs, a number of implementation
types are supported.</t> types are supported.</t>
</section>
</section> </section>
</section> <section anchor="rfc6374-combined-loss-delay-measurement" numbered="true" to
<section anchor="rfc6374-combined-loss-delay-measurement" title="RFC6374 Combine c="default">
d Loss-Delay Measurement"> <name>Combined Loss/Delay Measurement Using SFL</name>
<t>This mode of operation is not currently supported by this specification
<t>This mode of operation is not currently supported by this specification.</t> .</t>
</section>
</section> <section anchor="PCSEC" numbered="true" toc="default">
<section anchor="PCSEC" title="Privacy Considerations"> <name>Privacy Considerations</name>
<t>The inclusion of originating and/or flow information in a packet
<t>The inclusion of originating and/or flow information in a packet
provides more identity information and hence potentially degrades the provides more identity information and hence potentially degrades the
privacy of the communication. Whilst the inclusion of the additional privacy of the communication. While the inclusion of the additional
granularity does allow greater insight into the flow characteristics granularity does allow greater insight into the flow characteristics,
it does not specifically identify which node originated the packet it does not specifically identify which node originated the packet
other than by inspection of the network at the point of ingress, or other than by inspection of the network at the point of ingress or
inspection of the control protocol packets. This privacy threat may inspection of the control protocol packets. This privacy threat may
be mitigated by encrypting the control protocol packets, regularly be mitigated by encrypting the control protocol packets, regularly
changing the synonymous labels and by concurrently using a number of changing the synonymous labels, and by concurrently using a number of
such labels.</t> such labels.</t>
</section>
</section> <section anchor="security-considerations" numbered="true" toc="default">
<section anchor="security-considerations" title="Security Considerations"> <name>Security Considerations</name>
<t>The security considerations documented in <xref target="RFC6374" format
<t>The security considerations documented in <xref target="RFC6374"/> and <xref ="default"/> and <xref target="RFC8372" format="default"/>
target="RFC8372"/> (which in turn calls up <xref target="RFC5920" format="default"/> and <xref targ
(which in turn calls up <xref target="RFC7258"/> and <xref target="RFC5920"/>) a et="RFC7258" format="default"/>) are applicable to this
re applicable to this
protocol.</t> protocol.</t>
<t>The issue noted in <xref target="PCSEC" format="default"/> is a securit
<t>The issue noted in <xref target="PCSEC"/> is a security consideration. There y consideration. There are
are no other new security issues associated with the MPLS data plane. Any
no other new security issues associated with the MPLS dataplane. Any
control protocol used to request SFLs will need to ensure the control protocol used to request SFLs will need to ensure the
legitimacy of the request.</t> legitimacy of the request.</t>
<t>An attacker that manages to corrupt the <xref target="RFC6374" format="
default"/> SFL TLV in <xref target="sfltlv" format="default"/> could
disrupt the measurements in a way that the <xref target="RFC6374" format="defaul
t"/> responder is unable to
detect. However, the network operator is likely to notice the
anomalous network performance measurements, and in any case,
normal MPLS network security procedures make this type of attack extremely unlik
ely.</t>
</section>
<section anchor="iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name>
<section anchor="allocation-of-mpls-generalized-associated-channel-g-ach-t
ypes" numbered="true" toc="default">
<name>Allocation of MPLS Generalized Associated Channel (G-ACh) Types</n
ame>
<t>As per the IANA considerations in <xref target="RFC5586" format="defa
ult"/> updated by <xref target="RFC7026" format="default"/> and <xref target="RF
C7214" format="default"/>, IANA has
allocated the following values in the "MPLS Generalized Associated Channel
(G-ACh) Types" registry, in the "Generic Associated Channel (G-ACh) Parameters"
registry group:</t>
<t>An attacker that manages to corrupt the RFC6374 SFL TLV <xref target="sfltlv" <table anchor="tab-1">
/> could <name/>
disrupt the measurements in a way that the RFC6374 responder is unable to <thead>
detect. However, the network opertator is likely to notice the <tr>
anomalous network performance measurements, and in any case <th>Value</th>
normal MPLS network security proceedures make this type of attack extremely unli <th>Description</th>
kley.</t> <th>Reference</th>
</tr>
</section> </thead>
<section anchor="iana-considerations" title="IANA Considerations"> <tbody>
<tr>
<section anchor="allocation-of-mpls-generalized-associated-channel-g-ach-types" <td>0x0010</td>
title="Allocation of MPLS Generalized Associated Channel (G-ACh) Types"> <td>Time Bucket Jitter Measurement</td>
<td>RFC 9571</td>
<t>As per the IANA considerations in <xref target="RFC5586"/> updated by <xref t </tr>
arget="RFC7026"/> and <xref target="RFC7214"/>, IANA is requested to <tr>
allocate the following codeponts in the “MPLS Generalized Associated Channel <td>0x0011</td>
(G-ACh) Type” registry, in the “Generic Associated Channel (G-ACh) Parameters” <td>Multi-packet Delay Measurement</td>
name space:</t> <td>RFC 9571</td>
</tr>
<figure><artwork><![CDATA[ <tr>
Value Description Reference <td>0x0012</td>
TBD RFC6374 Time Bucket Jitter Measurement This <td>Average Delay Measurement</td>
<td>RFC 9571</td>
TBD RFC6374 Multi-Packet Delay This </tr>
Measurement </tbody>
</table>
TBD RFC6374 Average Delay Measurement This </section>
]]></artwork></figure> <section anchor="allocation-of-mpls-lossdelay-tlv-object" numbered="true"
toc="default">
</section> <name>Allocation of MPLS Loss/Delay TLV Object</name>
<section anchor="allocation-of-mpls-lossdelay-tlv-object" title="Allocation of M <t>IANA has allocated the following TLV from the 0-127 range of the
PLS Loss/Delay TLV Object"> "MPLS Loss/Delay Measurement TLV Object" registry in the
"Generic Associated Channel (G-ACh) Parameters" registry group:</t>
<t>IANA is requested to allocate a new TLV from the 0-127 range of the
MPLS Loss/Delay Measurement TLV Object Registry in the
“Generic Associated Channel (G-ACh) Parameters” namespace:</t>
<figure><artwork><![CDATA[
Type Description Reference
---- --------------------------------- ---------
TBD Synonymous Flow Label This
]]></artwork></figure>
<t>A value of 4 is recommended.</t>
<t>RFC Editor please delete this para <xref target="RFC3032"/><xref target="I-D.
bryant-mpls-sfl-control"/><xref target="RFC5036"/></t>
</section>
</section>
<section anchor="acknowledgments" title="Acknowledgments">
<t>The authors thank Benjamin Kaduk and Elwyn Davies for their thorough and thou
ghtful
review of this document.</t>
</section>
<section anchor="contributing-authors" title="Contributing Authors">
<figure><artwork><![CDATA[
Zhenbin Li
Huawei
Email: lizhenbin@huawei.com
Siva Sivabalan
Ciena Corporation
Email: ssivabal@ciena.com
]]></artwork></figure>
</section>
<table anchor="tab-2">
<name/>
<thead>
<tr>
<th>Type</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>4</td>
<td>Synonymous Flow Label</td>
<td>RFC 9571</td>
</tr>
</tbody>
</table>
</section>
</section>
</middle> </middle>
<back> <back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<references title='Normative References'> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<reference anchor="I-D.bryant-mpls-sfl-control"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<front> 174.xml"/>
<title>A Simple Control Protocol for MPLS SFLs</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
032.xml"/>
<author initials='S' surname='Bryant' fullname='Stewart Bryant'> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<organization /> 876.xml"/>
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
586.xml"/>
<author initials='G' surname='Swallow' fullname='George Swallow'> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<organization /> 374.xml"/>
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
957.xml"/>
<author initials='S' surname='Sivabalan' fullname='Siva Sivabalan'> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<organization /> 036.xml"/>
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
026.xml"/>
<date month='December' day='7' year='2020' /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
214.xml"/>
<abstract><t>In draft-ietf-mpls-sfl-framework the concept of MPLS synonymous flo </references>
w labels (SFL) was introduced. This document describes a simple control protoco <references>
l that runs over an associated control header to request, withdraw, and extend t <name>Informative References</name>
he lifetime of such labels. It is not the only control protocol that moght be u <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
sed to support SFL, but it has the benefit of being able to be used without modi 372.xml"/>
fying of the existing MPLS control prodocols. The existance of this design is n <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
ot intended to restrict the ability to enhance an existing MPLS control protocol 270.xml"/>
to add a similar capability. A Querier MUST wait a configured time (suggested <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
wait of 60 seconds) before re-attempting a Withdraw request. No more than three 921.xml"/>
Withdraw requests SHOULD be made. These restricctions are to prevent overloadi <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
ng the control plane of the actioning router.</t></abstract> 190.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
</front> 258.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<seriesInfo name='Internet-Draft' value='draft-bryant-mpls-sfl-control-09' /> 920.xml"/>
<format type='TXT' <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
target='http://www.ietf.org/internet-drafts/draft-bryant-mpls-sfl-contro 341.xml"/>
l-09.txt' /> </references>
</reference>
<reference anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></
author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify
the requirements in the specification. These words are often capitalized. This
document defines these words as they should be interpreted in IETF documents.
This document specifies an Internet Best Current Practices for the Internet Comm
unity, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></auth
or>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
pecifications. This document aims to reduce the ambiguity by clarifying that on
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
tract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>
<reference anchor="RFC3032" target='https://www.rfc-editor.org/info/rfc3032'>
<front>
<title>MPLS Label Stack Encoding</title>
<author initials='E.' surname='Rosen' fullname='E. Rosen'><organization /></auth
or>
<author initials='D.' surname='Tappan' fullname='D. Tappan'><organization /></au
thor>
<author initials='G.' surname='Fedorkow' fullname='G. Fedorkow'><organization />
</author>
<author initials='Y.' surname='Rekhter' fullname='Y. Rekhter'><organization /></
author>
<author initials='D.' surname='Farinacci' fullname='D. Farinacci'><organization
/></author>
<author initials='T.' surname='Li' fullname='T. Li'><organization /></author>
<author initials='A.' surname='Conta' fullname='A. Conta'><organization /></auth
or>
<date year='2001' month='January' />
<abstract><t>This document specifies the encoding to be used by an LSR in order
to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN
data links, and possibly on other data links as well. This document also specif
ies rules and procedures for processing the various fields of the label stack en
coding. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3032'/>
<seriesInfo name='DOI' value='10.17487/RFC3032'/>
</reference>
<reference anchor="RFC7876" target='https://www.rfc-editor.org/info/rfc7876'>
<front>
<title>UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks</
title>
<author initials='S.' surname='Bryant' fullname='S. Bryant'><organization /></au
thor>
<author initials='S.' surname='Sivabalan' fullname='S. Sivabalan'><organization
/></author>
<author initials='S.' surname='Soni' fullname='S. Soni'><organization /></author
>
<date year='2016' month='July' />
<abstract><t>RFC 6374 defines a protocol for Packet Loss and Delay Measurement f
or MPLS networks (MPLS-PLDM). This document specifies the procedures to be used
when sending and processing out-of-band MPLS performance management Responses o
ver an UDP/IP return path.</t></abstract>
</front>
<seriesInfo name='RFC' value='7876'/>
<seriesInfo name='DOI' value='10.17487/RFC7876'/>
</reference>
<reference anchor="RFC5586" target='https://www.rfc-editor.org/info/rfc5586'>
<front>
<title>MPLS Generic Associated Channel</title>
<author initials='M.' surname='Bocci' fullname='M. Bocci' role='editor'><organiz
ation /></author>
<author initials='M.' surname='Vigoureux' fullname='M. Vigoureux' role='editor'>
<organization /></author>
<author initials='S.' surname='Bryant' fullname='S. Bryant' role='editor'><organ
ization /></author>
<date year='2009' month='June' />
<abstract><t>This document generalizes the applicability of the pseudowire (PW)
Associated Channel Header (ACH), enabling the realization of a control channel a
ssociated to MPLS Label Switched Paths (LSPs) and MPLS Sections in addition to M
PLS pseudowires. In order to identify the presence of this Associated Channel H
eader in the label stack, this document also assigns one of the reserved MPLS la
bel values to the Generic Associated Channel Label (GAL), to be used as a label
based exception mechanism.</t></abstract>
</front>
<seriesInfo name='RFC' value='5586'/>
<seriesInfo name='DOI' value='10.17487/RFC5586'/>
</reference>
<reference anchor="RFC6374" target='https://www.rfc-editor.org/info/rfc6374'>
<front>
<title>Packet Loss and Delay Measurement for MPLS Networks</title>
<author initials='D.' surname='Frost' fullname='D. Frost'><organization /></auth
or>
<author initials='S.' surname='Bryant' fullname='S. Bryant'><organization /></au
thor>
<date year='2011' month='September' />
<abstract><t>Many service provider service level agreements (SLAs) depend on the
ability to measure and monitor performance metrics for packet loss and one-way
and two-way delay, as well as related metrics such as delay variation and channe
l throughput. This measurement capability also provides operators with greater
visibility into the performance characteristics of their networks, thereby facil
itating planning, troubleshooting, and network performance evaluation. This doc
ument specifies protocol mechanisms to enable the efficient and accurate measure
ment of these performance metrics in MPLS networks. [STANDARDS-TRACK]</t></abst
ract>
</front>
<seriesInfo name='RFC' value='6374'/>
<seriesInfo name='DOI' value='10.17487/RFC6374'/>
</reference>
<reference anchor="RFC8957" target='https://www.rfc-editor.org/info/rfc8957'>
<front>
<title>Synonymous Flow Label Framework</title>
<author initials='S.' surname='Bryant' fullname='S. Bryant'><organization /></au
thor>
<author initials='M.' surname='Chen' fullname='M. Chen'><organization /></author
>
<author initials='G.' surname='Swallow' fullname='G. Swallow'><organization /></
author>
<author initials='S.' surname='Sivabalan' fullname='S. Sivabalan'><organization
/></author>
<author initials='G.' surname='Mirsky' fullname='G. Mirsky'><organization /></au
thor>
<date year='2021' month='January' />
<abstract><t>RFC 8372 (&quot;MPLS Flow Identification Considerations&quot;) desc
ribes the requirement for introducing flow identities within the MPLS architectu
re. This document describes a method of accomplishing this by using a technique
called &quot;Synonymous Flow Labels&quot; in which labels that mimic the behavi
or of other labels provide the identification service. These identifiers can be
used to trigger per-flow operations on the packet at the receiving label switchi
ng router.</t></abstract>
</front>
<seriesInfo name='RFC' value='8957'/>
<seriesInfo name='DOI' value='10.17487/RFC8957'/>
</reference>
<reference anchor="RFC5036" target='https://www.rfc-editor.org/info/rfc5036'>
<front>
<title>LDP Specification</title>
<author initials='L.' surname='Andersson' fullname='L. Andersson' role='editor'>
<organization /></author>
<author initials='I.' surname='Minei' fullname='I. Minei' role='editor'><organiz
ation /></author>
<author initials='B.' surname='Thomas' fullname='B. Thomas' role='editor'><organ
ization /></author>
<date year='2007' month='October' />
<abstract><t>The architecture for Multiprotocol Label Switching (MPLS) is descri
bed in RFC 3031. A fundamental concept in MPLS is that two Label Switching Rout
ers (LSRs) must agree on the meaning of the labels used to forward traffic betwe
en and through them. This common understanding is achieved by using a set of pr
ocedures, called a label distribution protocol, by which one LSR informs another
of label bindings it has made. This document defines a set of such procedures
called LDP (for Label Distribution Protocol) by which LSRs distribute labels to
support MPLS forwarding along normally routed paths. [STANDARDS-TRACK]</t></abs
tract>
</front>
<seriesInfo name='RFC' value='5036'/>
<seriesInfo name='DOI' value='10.17487/RFC5036'/>
</reference>
<reference anchor="RFC7026" target='https://www.rfc-editor.org/info/rfc7026'>
<front>
<title>Retiring TLVs from the Associated Channel Header of the MPLS Generic Asso
ciated Channel</title>
<author initials='A.' surname='Farrel' fullname='A. Farrel'><organization /></au
thor>
<author initials='S.' surname='Bryant' fullname='S. Bryant'><organization /></au
thor>
<date year='2013' month='September' />
<abstract><t>The MPLS Generic Associated Channel (G-ACh) is a generalization of
the applicability of the pseudowire (PW) Associated Channel Header (ACH). RFC 5
586 defines the concept of TLV constructs that can be carried in messages on the
G-ACh by placing them in the ACH between the fixed header fields and the G-ACh
message. These TLVs are called ACH TLVs</t><t>No Associated Channel Type yet de
fined uses an ACH TLV. Furthermore, it is believed that handling TLVs in hardwa
re introduces significant problems to the fast path, and since G-ACh messages ar
e intended to be processed substantially in hardware, the use of ACH TLVs is und
esirable.</t><t>This document updates RFC 5586 by retiring ACH TLVs and removing
the associated registry.</t></abstract>
</front>
<seriesInfo name='RFC' value='7026'/>
<seriesInfo name='DOI' value='10.17487/RFC7026'/>
</reference>
<reference anchor="RFC7214" target='https://www.rfc-editor.org/info/rfc7214'>
<front>
<title>Moving Generic Associated Channel (G-ACh) IANA Registries to a New Regist
ry</title>
<author initials='L.' surname='Andersson' fullname='L. Andersson'><organization
/></author>
<author initials='C.' surname='Pignataro' fullname='C. Pignataro'><organization
/></author>
<date year='2014' month='May' />
<abstract><t>RFC 5586 generalized the applicability of the pseudowire Associated
Channel Header (PW-ACH) into the Generic Associated Channel G-ACh. However, reg
istries and allocations of G-ACh parameters had been distributed throughout diff
erent, sometimes unrelated, registries. This document coalesces these into a new
&quot;Generic Associated Channel (G-ACh) Parameters&quot; registry under the &
quot;Multiprotocol Label Switching Architecture (MPLS)&quot; heading. This doc
ument updates RFC 5586.</t><t>This document also updates RFCs 6374, 6378, 6427,
and 6428.</t></abstract>
</front>
<seriesInfo name='RFC' value='7214'/>
<seriesInfo name='DOI' value='10.17487/RFC7214'/>
</reference>
</references> </references>
<section anchor="acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The authors thank <contact fullname="Benjamin Kaduk"/> and <contact ful
lname="Elwyn Davies"/> for their thorough and thoughtful
review of this document.</t>
</section>
<references title='Informative References'> <section anchor="contributors" numbered="false" toc="default">
<name>Contributors</name>
<reference anchor="RFC8372" target='https://www.rfc-editor.org/info/rfc8372'> <contact fullname="Zhenbin Li" >
<front> <organization>Huawei</organization>
<title>MPLS Flow Identification Considerations</title> <address>
<author initials='S.' surname='Bryant' fullname='S. Bryant'><organization /></au <email>lizhenbin@huawei.com</email>
thor> </address>
<author initials='C.' surname='Pignataro' fullname='C. Pignataro'><organization </contact>
/></author>
<author initials='M.' surname='Chen' fullname='M. Chen'><organization /></author
>
<author initials='Z.' surname='Li' fullname='Z. Li'><organization /></author>
<author initials='G.' surname='Mirsky' fullname='G. Mirsky'><organization /></au
thor>
<date year='2018' month='May' />
<abstract><t>This document discusses aspects to consider when developing a solut
ion for MPLS flow identification. The key application that needs this solution
is in-band performance monitoring of MPLS flows when MPLS is used to encapsulate
user data packets.</t></abstract>
</front>
<seriesInfo name='RFC' value='8372'/>
<seriesInfo name='DOI' value='10.17487/RFC8372'/>
</reference>
<reference anchor="RFC8321" target='https://www.rfc-editor.org/info/rfc8321'>
<front>
<title>Alternate-Marking Method for Passive and Hybrid Performance Monitoring</t
itle>
<author initials='G.' surname='Fioccola' fullname='G. Fioccola' role='editor'><o
rganization /></author>
<author initials='A.' surname='Capello' fullname='A. Capello'><organization /></
author>
<author initials='M.' surname='Cociglio' fullname='M. Cociglio'><organization />
</author>
<author initials='L.' surname='Castaldelli' fullname='L. Castaldelli'><organizat
ion /></author>
<author initials='M.' surname='Chen' fullname='M. Chen'><organization /></author
>
<author initials='L.' surname='Zheng' fullname='L. Zheng'><organization /></auth
or>
<author initials='G.' surname='Mirsky' fullname='G. Mirsky'><organization /></au
thor>
<author initials='T.' surname='Mizrahi' fullname='T. Mizrahi'><organization /></
author>
<date year='2018' month='January' />
<abstract><t>This document describes a method to perform packet loss, delay, and
jitter measurements on live traffic. This method is based on an Alternate-Mark
ing (coloring) technique. A report is provided in order to explain an example a
nd show the method applicability. This technology can be applied in various sit
uations, as detailed in this document, and could be considered Passive or Hybrid
depending on the application.</t></abstract>
</front>
<seriesInfo name='RFC' value='8321'/>
<seriesInfo name='DOI' value='10.17487/RFC8321'/>
</reference>
<reference anchor="RFC3270" target='https://www.rfc-editor.org/info/rfc3270'>
<front>
<title>Multi-Protocol Label Switching (MPLS) Support of Differentiated Services<
/title>
<author initials='F.' surname='Le Faucheur' fullname='F. Le Faucheur'><organizat
ion /></author>
<author initials='L.' surname='Wu' fullname='L. Wu'><organization /></author>
<author initials='B.' surname='Davie' fullname='B. Davie'><organization /></auth
or>
<author initials='S.' surname='Davari' fullname='S. Davari'><organization /></au
thor>
<author initials='P.' surname='Vaananen' fullname='P. Vaananen'><organization />
</author>
<author initials='R.' surname='Krishnan' fullname='R. Krishnan'><organization />
</author>
<author initials='P.' surname='Cheval' fullname='P. Cheval'><organization /></au
thor>
<author initials='J.' surname='Heinanen' fullname='J. Heinanen'><organization />
</author>
<date year='2002' month='May' />
<abstract><t>This document defines a flexible solution for support of Differenti
ated Services (Diff-Serv) over Multi-Protocol Label Switching (MPLS) networks.
[STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3270'/>
<seriesInfo name='DOI' value='10.17487/RFC3270'/>
</reference>
<reference anchor="RFC5921" target='https://www.rfc-editor.org/info/rfc5921'>
<front>
<title>A Framework for MPLS in Transport Networks</title>
<author initials='M.' surname='Bocci' fullname='M. Bocci' role='editor'><organiz
ation /></author>
<author initials='S.' surname='Bryant' fullname='S. Bryant' role='editor'><organ
ization /></author>
<author initials='D.' surname='Frost' fullname='D. Frost' role='editor'><organiz
ation /></author>
<author initials='L.' surname='Levrau' fullname='L. Levrau'><organization /></au
thor>
<author initials='L.' surname='Berger' fullname='L. Berger'><organization /></au
thor>
<date year='2010' month='July' />
<abstract><t>This document specifies an architectural framework for the applicat
ion of Multiprotocol Label Switching (MPLS) to the construction of packet-switch
ed transport networks. It describes a common set of protocol functions -- the M
PLS Transport Profile (MPLS-TP) -- that supports the operational models and capa
bilities typical of such networks, including signaled or explicitly provisioned
bidirectional connection-oriented paths, protection and restoration mechanisms,
comprehensive Operations, Administration, and Maintenance (OAM) functions, and n
etwork operation in the absence of a dynamic control plane or IP forwarding supp
ort. Some of these functions are defined in existing MPLS specifications, while
others require extensions to existing specifications to meet the requirements o
f the MPLS-TP.</t><t>This document defines the subset of the MPLS-TP applicable
in general and to point-to-point transport paths. The remaining subset, applica
ble specifically to point-to-multipoint transport paths, is outside the scope of
this document.</t><t>This document is a product of a joint Internet Engineering
Task Force (IETF) / International Telecommunication Union Telecommunication Sta
ndardization Sector (ITU-T) effort to include an MPLS Transport Profile within t
he IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to suppo
rt the capabilities and functionalities of a packet transport network as defined
by the ITU-T. This document is not an Internet Standards Track specification;
it is published for informational purposes.</t></abstract>
</front>
<seriesInfo name='RFC' value='5921'/>
<seriesInfo name='DOI' value='10.17487/RFC5921'/>
</reference>
<reference anchor="RFC7190" target='https://www.rfc-editor.org/info/rfc7190'>
<front>
<title>Use of Multipath with MPLS and MPLS Transport Profile (MPLS-TP)</title>
<author initials='C.' surname='Villamizar' fullname='C. Villamizar'><organizatio
n /></author>
<date year='2014' month='March' />
<abstract><t>Many MPLS implementations have supported multipath techniques, and
many MPLS deployments have used multipath techniques, particularly in very high-
bandwidth applications, such as provider IP/MPLS core networks. MPLS Transport
Profile (MPLS-TP) has strongly discouraged the use of multipath techniques. Som
e degradation of MPLS-TP Operations, Administration, and Maintenance (OAM) perfo
rmance cannot be avoided when operating over many types of multipath implementat
ions.</t><t>Using MPLS Entropy Labels (RFC 6790), MPLS Label Switched Paths (LSP
s) can be carried over multipath links while also providing a fully MPLS-TP-comp
liant server layer for MPLS-TP LSPs. This document describes the means of suppo
rting MPLS as a server layer for MPLS-TP. The use of MPLS-TP LSPs as a server la
yer for MPLS LSPs is also discussed.</t></abstract>
</front>
<seriesInfo name='RFC' value='7190'/>
<seriesInfo name='DOI' value='10.17487/RFC7190'/>
</reference>
<reference anchor="RFC7258" target='https://www.rfc-editor.org/info/rfc7258'>
<front>
<title>Pervasive Monitoring Is an Attack</title>
<author initials='S.' surname='Farrell' fullname='S. Farrell'><organization /></
author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organizatio
n /></author>
<date year='2014' month='May' />
<abstract><t>Pervasive monitoring is a technical attack that should be mitigated
in the design of IETF protocols, where possible.</t></abstract>
</front>
<seriesInfo name='BCP' value='188'/>
<seriesInfo name='RFC' value='7258'/>
<seriesInfo name='DOI' value='10.17487/RFC7258'/>
</reference>
<reference anchor="RFC5920" target='https://www.rfc-editor.org/info/rfc5920'>
<front>
<title>Security Framework for MPLS and GMPLS Networks</title>
<author initials='L.' surname='Fang' fullname='L. Fang' role='editor'><organizat
ion /></author>
<date year='2010' month='July' />
<abstract><t>This document provides a security framework for Multiprotocol Label
Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks
. This document addresses the security aspects that are relevant in the context
of MPLS and GMPLS. It describes the security threats, the related defensive te
chniques, and the mechanisms for detection and reporting. This document emphasi
zes RSVP-TE and LDP security considerations, as well as inter-AS and inter-provi
der security considerations for building and maintaining MPLS and GMPLS networks
across different domains or different Service Providers. This document is not
an Internet Standards Track specification; it is published for informational pu
rposes.</t></abstract>
</front>
<seriesInfo name='RFC' value='5920'/>
<seriesInfo name='DOI' value='10.17487/RFC5920'/>
</reference>
</references> <contact fullname="Siva Sivabalan">
<organization>Ciena Corporation</organization>
<address>
<email>ssivabal@ciena.com</email>
</address>
</contact>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAJCNQmAAA+09a28bR5Lf+1c0bOAg3VKMJduxYyBAZMlydCfFWlNJcLsI
Ds2ZJjXRcIaZnpHM2N7ffvXqxwxJ2UHi2ySIFutI5HR3dXW9q7pmb29PZXVe
VPNnumtne0+Vaou2tM/065Ojzx8+eaQnq6quVou6c/qkrG/1mZna0ikznTb2
Jjy2Nzk5U3mdVWYBY/PGzNq9wsKEi2Xp9ppZRg+5Wbm3/0DdwmLnF2cT/X3d
XMPS+mVTd0uVmdbO62b1TLs2V8q1psr/15R1BTOurFPL4pn+Z1tnI+3qpm3s
zMFvqwX/ktWLha1a94NSpmuv6uaZ0noP/k8/ReWe6clYP29Wpmr1zot813/F
EE9ae2uaVh7w39UNQHrStV1jb22hL212VdVlPS+s06dVNvbP2YUpSgB7+pXj
eaY0zRiAWoPi5VhPbk0JqOxD8NLCanb4HUEwqWFHtsoZgCIzpT6CvdpmuD6P
HSPiv5rjZxshOB/rI5iuv/y5ya56H9PKX3cGNj5YZgGPjjN49Ksr+nrbNk+K
Osvq0gz2WXTOLpd27etkwR6mB6vPZfx4JuM/AMV50bjr1QCGhght8B0B8I/L
F/qobpbDs9VzGFMsaECCW6WqulmYtrixSHCne8djPnsmfCT4rK7api7xa2CW
g/39L+TXp/tPHsmvDx88PJBfnzx98rn8+vjx08/XH0BO8jN88fiJf/bBQ//s
kwcH4deDfXhWFdUshRJHPnxyEH492PerHDx54Of7Inz6ZP+LB2G+x0/jA/Sp
2tvb02bq2sZkrVLwjSa5kVuXNcUUOGVhgR9zp+sZkA7xe1k7p4G74aHSrOAB
44DFiH91XSkSMcAJRQtUlusL0145vXM2uXC7etkUC9MU5Uobp4EScjhoFiaX
jancEiSDvmjqWVFavYOf711e7KrKtrcga9xY68urwmmQVB0ul0BpBE4E075p
gd0Q0rCdpW0Ih1VmVQ/eWVMv9AzYzunMNE0BENU3ttGytm7rTd/ObWWbImPI
cWdjdVrpJYiOIutK04x00QoYTgHz65ZY/6fO4oSa+PxONMJTUwv4zi1gVC+6
si32lnUBW4Zv6BeFy9LwAgk07zLAgqsXVps8L9qirkDOhGVpRl52UTcWHlwC
IgFaENq52rY0nM20bq8CMnC13tbDwQAnISEtijwvrVL3Qb4yUAiIUm/fCuW/
f69v4eTrppgXACDQARxhMa8AsXA+SBFIGKbSr+DEDA4G5XCYL4qqQBLFD0YI
hjo3sG1b4YHqnVeH50haNWiXulR+IiDAqw/SlibQkF0ANDrJsNu6KlfKdUsc
6Bjpe20tx4CoCB+l58NzbCNTdQUnABhG+LyKBiwjifQQmxlnaaNwaK5Oj9jo
qltMQXkgP64d5YAZZ9oslyV8NS3Kol3R2eKB4vR4aLR5FCaw+QgkQtPYn7qC
56GT8RAAVylkCF3k8BXQGTx/C8oEdiQMR3tKD3xpsmsLiEFyP0/AUztn57vA
0sA5rluAWFiF4YAeBgN5ZC/Zk8YxfkZDzyj/F6iTDkACAHOQ+k1G1MKHBKt8
i0K07SrAElBdi+czB4HqdFM44kqPWMCaAlqalnaB85sWeGGlS2tyfAqJtZgB
RgGWtYW1bZq6cYAsldmmBRKF59uO6RhgOAFE2jcGdAsIcrUPn3x/ZeEIjWaU
AgN30x9thgcJa734qUNboXatPicKQ1EK1s/R+QXbP2BFmZbQwqCglKo0Cqob
kBtdiwRQNznsiXihsW4Jk+PUiNuzc5qEhwIxHHwQHlg4rjnasChNCBjLi9kM
JgLArkyTg0mFsgQsnpkBEh7B6mCOMoUh1hqb2SUdFhIsmzBn5x69+HGVjCfw
QX7MYVtmwxkYljlkEgBcCSxxiturAuwlPNeqblHcZfVeWTMHEaqKli0I4uPC
yTQo3FsRqmjGCZkQ9eQ5oNfxaKRKHC1MhBIe7A9L28uyDlTtCvD9EPD94gZY
55aQ3tK/sFYlmN6ZRXLBrbyefHexd/liFAQUihrGOAojZ7u8voXl3M7F9253
V+OGCEbAOTEn7hf2mqMoLaZd67VZSvlEETwEVs9AwMB5IfHjBEj/qyq7auqq
+FnYSzgF9vMI9nNWVNfazNHa4u8TDUQyAa0RkAkICkm2wFf9eQmOwjkYN9ZK
PYapJ6jbACVATUjRBaIF6ZC5CwjtBgkX/I25XhZLWxZANFPQT1aM4gQRkWxI
fWYsW2iHV6iAXJ0VRAtEVBbUuZkDM9M0d+AikEhBwvWwQunb1Giaw9MLEJaI
FF4FZM5wOG0XCcBLYoTNi2jST0UllOs5DxhLTQ3bWdMVQe/A5sAzhZ1ZXJm+
xllBJF6zvUVWwi2cgOsQNBBxyuQ/Al8Aj/BszNNAKyB50VgDDq1B7v0cl0Ge
BYZvZJ/R5PA8YVCuukjbSK3MSdusGXAHC1TnpADz2jpiTvio7HI8Wld3TWYD
p4na9OLrGzZFYJuVmbOuqIMN4TmRRqTqBDhSSAE1jRJ6SRYj8wy0a0UTobZq
cRckwSqLBIV6q01UtCL0yngUuKgudLDh8aArkcCyNI4mbTpbyUfKHwOZpyZO
w9MGzQ0ORE9z96zgiiMDaPuSPAc/AhifTTJCnxHTuySDHRz27FrUuEkMVhAi
JdiImwMJemdycrYbCbPkT0W+gsOVkTCcWmDPom5IIaGg8w8CtdzA3lNsCMEy
QgrbkJGrwNQDsuLnYDg/tCb8vYOwsIvaIw3QgkYXwOkUKiLyOpDu2CUINkdC
B3Ts/vN163yMBu7raCA5QEY174DslLoEAK/tSgMtgs907/zbyeW9Ef9Xf/OK
fn/94u/fnr5+cYy/T74+PDsLv/ATCv549e2ZfI+/xZFHr87PX3xzzIPhUz34
6Pzwf+6xgXzv1cXl6atvDs/uMaek9iiigc18UonLxqKwM33Jo58fXej9R0xp
6PcCpTHV7bMdD1Yfm6hoKMufcD4rlHrWNERhZakysyxakPUjXMDBUVQaZQIj
UXB8sdlEZG2KsSnCa25aYAXb3BSZDSIQKAqJggyWqUXiZTLH8bgp2Ooc41NA
wsR3wlneuC4T0mPtjWALfeFgEZv4DXlyCI5O7WbQkWhY1ZVXC2Qz0gRjAlsk
MtEoW7VB3YaFRZjxKLTCKuYbAuMKEJfVqO9oRwB3IugL/K6aEb/w0rgpxorq
Te+hgr3AE6QvpyjsRJTno/60qHsViAh/Rn/vbIN8ABJvTuSTAzjNAtVssiew
vjr065SfleCF/WR2y9aB4Vp0mIJDpPoroRWKe2PJRCAaELB4DOwADE6A9wim
zCZy4YVYFHvS4eWI5WkWF+mhcKrHEsGtgdXfv++R8ATWBgEllHxMQiMl5bf3
JxfH7ynCMgiwiEsoEiYVhSx6pl76yP5Vi+5sAaddLNimrIZCjM26CnXuWE9Q
yweTxxu9qrIsB9H6TWMbMAxxy7oYgWEoxFKMMQ5S6AoYuitznASchq7KvBmP
A8HtRoNIH5VgUumdy6NdPS1aMui+rm/tDRpWbB+gcCZuYw72InoBxlELWiMV
zfAnjVGstUCvgtMFjzs0grqSBICElui0MCgGXIoRWOJf3Nuth9mLYlzMVoJ+
0xL0fZQqVmkYvEhgxFgF6rA3K3KSzSYRBSY8qJoCOSBXBrgNxK1ju/VGkDuk
SvCBBgfaOyFvTYmu5vMqvHDdTKbHCNhEANtGpEqx/1e0YoaS80IHQZipQZDO
r0DYRxEbCYskMAmnWvVFgxDQLHU0IovRWl1Fq7GOrxUKITTmDcbU45g+Uhy5
eoiBeAop/oP023Hge719i/z3fnesDxMjKYcdZm054DCBOAPnFZaAw8PwilO0
Ay9eEhnBrtsMcYRMZXPA+MvihmU4eySkZ29AC/IJMjHx1ntWpBcCQnRI8SP/
HDCtf7Yo2QrHOE6kWAYNpYIjcqTA422dhvd0u1qiVe4ZgM0sMPGQBDtY69Zy
EC6NWKKDsMTzFPUFc/bjTKwnc5TEFbi36GyXLFFXQBgNIBNpHZRCAce8RAWD
USU0bclFIYuQeQA2SV6jbGlFU2+ZQDwMmoeEZt3iZsAHSTYfHBpALqK+NEvS
hoCkkQpmK+HRFmSZxvOP+GSVmUrMrkV2a1otS5H7sPFRDgPznxyBJX2VteRV
VVlRFiaRmuoG9oVWtvieaG0iZrxfhfGIsuwoGuqV0snpy+NzEHIgEOvbZ0r5
5MfO/q4+DD/Pw8+mz8IgFCbnhjN7RPE9uxxRS3J4kYoNv94BrncMP79mPddN
nQ3a2bMZLkzHEld7GHeHa/6Wq5msIT/AD0s1UMpOUzikHHg3AvUIgTo6xv99
NAouPStjTBe9Y4z4bMgKsHnqR5ltUPED/rFD/R/6OfFRsHJJyNOowqszGZ77
UUcw6tiPstf9UTFpsT7+7TN9n+hRUyb6y3sotJ889PajqB5v2N8Di+i04s3v
4/YjMYMkcmQaeeQkAKRHQClmFQAJmrKj0GHwDToJi5hy5QqwQTAWGxgJQ5fL
rlnWKFCAKV2RkyQAKbT/II22hJwVCS6OkrKpTrzvxbzAQqv9TPrgG+J7mZi2
czDYrkRe3QLt92DE+rUTgeJnjSxBshOldt9fSYOfCgkfhT/AmGOugFVdKmYl
8cM2l0xP2QKSbeHMWVDDdF8e+rms42NhqA9H9O1x8q2oTZWoTXZVEkc0cdrC
xkZ6CseIoB+jLe5iDMITEK4m2hTOoWsqMoQGzyER0PmXK0wPnHAQETHwApx4
OC9yT8RMPXlxtOu1YWI1E1aPWbrjIWTgS4MZzDJY4jmHEkXCvY7ix8wqDi0+
MiSIf/xEPqJJxiRlo8sxmmFBFwkEhQu+lagGoIdbtOZ2gkwOZ7Sr2EwOk6Am
9ApFdCrrHgxOdxKFx0QX28/KSPQYDNKWgnzr9PvwY+jXH7dKSDOcbpCyKfV4
iepp2k+QKl+Bg3GGHgmuJMSna++mxA+fc0jEVKuBN4uTkmnQmmtYqsTcgJm1
KCj6kQFF8x7rHaI1dF10vZSoLdiJIDeqXQlBUyIk12KTsRuMWD2bvN6Ix0c9
PI7114hHEH4S0I6iT7EdGJIKHuzUqt6uNDZYrsSCtyI2gv3rqQkOAHz8mkJH
6taKBAI6ImctHuLOEdHd8a5EVAB7mGQLsXfAwkLvcComMaumq/6fBqTybrDc
gjAGEfgRprlX3zHX482+uF1ygyiJMMHcQTFbUcKyK60DHUSohSVdwS4IHRJF
S4MfImaCWJHLROuR0iXLekRiCGxlWpnNd5FkA82Jv8mJ8IRjfTpDPLONiPSX
1YupBJ5pOsrajjiWh2kIJ3DOinknuXHVUrB6zpmNXopEQkhvMA8cYzKU/TCO
ch0OkcSeKMKA07gEVQ2iKvqvpPVyOzOYE0PQOKV5CEzmVq7FtBjSV2Ax79rw
9ikginJUPD4wOfwDRHyUjhzOVdwxkccDMcbadDqVqHQSqThucHhZUqJTUSkR
px5YNPXk4EP0H9e4TJ8f/g/OCEIHtRqAzekNEa1mo4kmakJSrLgzxLB+xKm0
TasE88Jvml0QW6FbLiiiqUm5+JAhPDirJbAEZw6ghCIeJkD/IGL9Mav3XAhK
bGRUFp5wd44HTgfNsQBDiiDqQM1jatpHIoP9Htw0+QCdlWouMVOjZ0XjCPZU
KoBsSdfa3RK5lB3yurYP7nCLnCDABwovvx1Swqzgs7+V2Cv7fZjl41hEyKOR
P4/zGS+E0W/l7JPiPOPS+OwnupnMi461kllgaITR43NsQDjTsnBXDIAk2GRG
SWLVTRJTENUS4spUoObYVqMvmBCrPD1GZaIE8pI49exGkpVkLmcTweQYaAhi
hELoEnGlNVFjVhzJP/duSy+2dDSIoIAajbrKF5YZ4mUfZWVjzuQBtSJ2U52m
kvohn+Xpx2dRkb4wrO54X341DKZHq3ioRwhpQYkkKWMsKamwCi7NOsZ0NMtN
MATQIAt7Yz7kiIUfSTY4RZ7MvKpx1Xii/qxhz/aa4qSXV1g3cJ5iqnBZ50Bg
s7i9RCp93rGRAiKTjFiYc4LltwAaHMQNxxdIdIGqwZj6MTvS9+/L1Hr/WX8m
dMpazqTR92umjD8PjgiRYNoTpMzNcqQzgoOyb6wnyFus+nU2nkU78a8AS2iX
YuZsY65AeceLR8B+qFZMaiRA9876aLy1DcekwCRBk2yKTmGa61EmBie7JVLc
Ppr9B/jPI/znaSeZIgrbwV8USJZajRBFm2EkV3ZBjtLAyWGLMCwgAzPTOZbK
+BkP90Y6Z5RZNY9CWhqfw+kPGA7672AcT+2HattmYyywWiKVI22CflgU8yuS
1TAtDkktlrRIgircfEgNRRdoSBBTC0DziMVkcI+uTB5Q6aN1tAUsnAMxaaWe
BFYg3BISo8CKmPHJrYMYAFN0iqFKA/NUJMNAyVJYOretIT8mTbFjnB70dhY8
NK7sQM+ZBBFbFRRai0ROlpfrkxApACuVdmQPdgQNPfVjQQgcxonh1Cu2nIZx
ZSP8xwNlIzd1kftE1oKq9bzmRdsJHdYkW20o/e29Uha64iaTsMEwIWiTlZjr
Xo/F+LM3yz3TsUsFw+agmxZkjokGSjQPRyCDzPNpilRm6P9iZKQ5r3NO4amQ
m/ABSgoxPdDrP/sbPjvY8NlDP8U+fP0QfKjH+nP9RD/VX/ySz2iSv+39yv/R
LO++A88aju2dPinN3Ol3Wh+Jkjyqc4t/84/gRJ/Zag7k73/e/ZawaP33yxP6
72v+7+sL+Tv9eW0xUQJUMvz5jWHZ+DNBKQNUfhrqPJL18Z/jySeA5ZugURLY
Ah42Ed86Xt55JZlC+wt+PjV2T72TAEJq/0GFubUiALtlR7/u51PvSE5tec2V
DCJv/ig7+tevhOVfv+Esf5QdXZ59p5+D5339/7AjSVgIVUnS4uMUGyYRQBdi
EgMVpKiAEauAUU8BjAaCf4QieoTyeUTSeaTWJeIoiiaKsE30SWFL8QOoWmtW
VFLSabny4uH4QMVEOfvyDd6Bqii0R8N9wJzSGZXcvkADYQ7wj/zkHANyoqzr
RHR68SdG0FoisE4laogLUKrG6Z9tU7NDDN4POtC1uPHLMHqLACs2uBohIAJG
iWSuyGth42YA+kVffhTbarFmGIHWIc+WTMip2MbGLEAy3IP9mRdXpmicOH+U
beQ8URzgLTDOFUU/VswvjFAXmBc/TSt8VFIW1S+WCQEwrgXgyUd6pxjbsfhv
VCMFi6NBhg4CRQrByF3UucT4kqFUVtnEorbUiETsxNIpAWl3FJwjqaSCtRSF
qmRpzsbEhFrfndNYw1litcMVVdmAkZoE9bi+ZtYB4tOQGJbW1LlEdWLCSWJh
7AeESZT42b5wioKBxrUCH0UJaCsjcUQ6l2DOkSEL+y/yEKe+varLiBhySJcS
ZUyvwAAIN8jVNaMt8tJAp80if0vdc/Bd+kVxCJ4DCoeTQY4CwnzVScKjyvsx
YQpsU/VG64kLXR40SjGa7WukKTfRWv6WbzxYzKIgQYXYHeenAMw3fCLoCEhG
1FcsSbkCoVjOVdyk9NgSKh4Wn1GdOO8Za9TXi+EFp8ErlzGc8ax8YeDddXtJ
6OPgrpjJIA4y4oJlJ2ilmhckhZg7a3vhcy5YGPiHHLj55s4aUL1T7Y4xnjPp
FiFQwkXb/oHJLkZ0zs2bYgHPUERnjIHjc5D1ySePwxzup840nBI5TYWohHUn
E1hRDSJ2IMEp4EB3pby4r3wi+HxDZgYrz4GnFYq//pawpMwHr/hQLi4o5bW+
6kNa9VFcte7asuBimDUIRwAePv7YB1SDRPQBAJoC62rouqDU2QxjVoNCVeeJ
IffEgNBwNP+msLcYUuWUk9ymEZ89RaobzMmMwFrZ/sT3wpQXJQG+HfhtV8v9
NNjQSnQwfKy/xHPSe3ryn5PPqt3Pdqq9/V3ttVIhF0Al4hWLBTsnu0a+Lud1
A6yyIMIN4Qnllx8BBjkyBQsh+LSUR60rFgXWfrIWc6OkHrRcKc4Bh41QsPx2
rKXYU8iHmI7v++dU/udsOUO5VNWtipfCsHbBcxpTkb9KhnFR4N/74VLclorb
vpG2NYbxkdP8FcT4K4gx/Pn3BDE2/kR1cmHS6MQWvPyeHORNsIjKOmYpipLq
OemQP+6O8Kenmj8Iyx9iR6n58cfe0UdZSb/nHf0pwzLnF6GQlPX08uPU/R8s
JvPhqIsX61vDFv6WH1dayvhtclRmScs8EkOdIxV8nuTIpa6b2E69vDu5/KCd
aTNjv3hf3MmSC/lwzfyup4JXLpoJ0Zc+VAzPL4ChJ6A8DPLhJ4cBj3qRku16
Tc+/2xMGO/oCg2Pb762Rlwae8CymWrfuplefiMEgsO99vlml5XWc599YPEBk
SnEh+QxdScpi00URTq/aN75nBFXFkeTGujlu1oMlFEkdqit+DoVzlCBXFP2y
obRvJyZVd6XUA+N1rq0pXSuHEGuUmWk4iTxSfhaMvdwWeUvX/R3fuvNTSBkb
Trzh4Y3JaX9xr3d9J9zKga2AU+z85WmX1cvg5Cl/05fPd1D14VvzJATh+wv4
NHSFyGX3CIvrmfrWq9EkkJxmtsOdRCx6MHQR1Sgp4UluTPnrAnSs7JeGVgm9
mmecbw988cWSw3d+Xl8oEAKNQFFY/s07cCz2PK/yBFya0ReedFlqj74d6xMO
cwkWwnloi2VqeAmhGlxsS2Mh2AVBal8xaIHxtZIR6u8ThpBoCinhi8ALN5mx
EE4IxcUmMwy6WpP7EvrEMEfjvesruRhr8hsDxDrnE/FBKZzGHxefKtcAhL1R
8XLvrh4WMzq6acHDA2OSoMl7c1MVA1BNFS9nJ6skwTC8GKG/rUps5uAbHEh5
e4j6EsffFtgMCdeNIewFVZpQwb/c2/K3FfiGG6wcgrpY+73xROXyqhS99EK9
TI/LpqB+QdtLIKo+d/0VOfgrcjCAZePPX5GDT7ijS9FBJyRJxbL5U+zozNy9
oT/IjsQrwV2xZqa08uYAz+9vR39eZ/vw2PvaH1Rqn9zN/j1718G73ChpisSy
61vCwbwTxzJUMUQXc23qlOXvnhnNxbsm5q/6gYENLMhl59Gi3+qyqn+Ty3ro
EkdF0uo8gTw32pAwxxsLQBOOL/ld1SUYkS7k3l4P8v9MRumjREJpEQslkfWE
Ks/zfhONU0aAJDvJU6z1DDsixdIG7DIHLlqu/SU8LtwWNKtoNW+46YbJtFVy
xmb9jFSojPEsM115/OJNMrzchi0ss7rEAt/Tvh+45gQ63qYauPrxIiYizAQC
jU4ZtYYKVwV8vbivw+CLKrQC9WhKGU6ulQ+vjKZ7xC2lDWloMyPdmJZvemGY
YIAqjv7QnMIVh5vRJg03EuwN42WmN1F6SwGLsdN6GR3bylFWfEMnk5Y7Kxu6
dAN+vep5Tn0aEI8vOMzr3h517BjUZvkdFYulyaQShNpM2tkMRKnztfBy1HF6
6RrJZR4zLQ1xI07iYaOflfhuSRk5V5Hf10cgLlZpn1gvd1NZ0Gtr8/Z+wvxK
fW+T7hdpqKDnkm1uWcXzUh84z/e+6YLvhMftYNZ7DJD0OqF97XP9COvdu3/u
dgH8zyYDB9Hwwae4z/aGpz4JXMP+f78XuPDn5eHZRzy1da5PANfh0df6Em96
fakfvDn8fcDluWKTNfeL4Hp3F2h/S57aPt279adOsKhsT/h461NUZ8UCeOHm
2576wIqfAPpXS+l/ikILTfffG1yvOVi2+anT5OrU9rl+E+jv/PlYuid/hcXx
R7eZQYturd0pKDz7xlAHMDJIsLOgkaAtaTyvKeCPZmNHwU1NJzk5EcZSKSfa
gV6rv5RW74ex0/ARWCsVgMXCcwckmm9N//jp52iS+eZR7VVsvktdGAu68N8V
7irc7ZIyTQI3NK8Bi/vV4XkMG09Cg7+0A+5aXy9vh/GbCMgm2YCFUdopcqsW
dclsI4rGS+uWWLobzAa6J0vum7fbUKbuBKH64MGDw11JsfmFN+XVyEZ1MRbd
0o3aGKMekaHkZ5ilQiiRNWxMSe2t23rpuOcPKQ90JmdLW4pDwy77t5sZR4ow
vhO6qT1Lm0no9YYva1Al5bi3tTQrAZoA0eSoWwF13056PxYz37yO+1FxGoIN
euWF2mDfbla25Q3etQ6N0kN33djYVw36UEhrIthtwT4Co5caFJEzZFxSwtk0
RA8qnrF4aGFJBjuULaaJC+R3NewUntdkCKeth9fkguTk6HPgGgUnmJdYusmr
Ii7SVGcx0wP4EoeRbNtvjy/YAcYXxESM4US+mUOo+O4oJzJCTqB6Tt+ukNN9
ai3dFxr7+laB1xVmGyTzRMyVNJ8mN0B5pIkNL8AHW14YSzopSP4unSa8GGHq
mx5654+zMmrt4eR2bUzjUHOFFIKQf2nrcMOgiIgPfRB5xVk/ZyNHYh3f+d2b
ctefPJ5l7OrSb1sm/Rl6Pck19SSfojPms1Cx2whzjfCKJKJ8Z3KhjhisWgt9
sF8kLAmk4bXzK24F0husU7LxHTr7WeE6Orwf9GTkxi/JFw6UJJmuOyWp5+70
vQQjejeDVFRX9laybwn0PQLdld3zSUaZL+zm9ZoSsgx1y8MevyhVcSXOb4cW
vCKl3t4XwdTXDv7rfqdUNiMOIkuGSJEXfEEoBVEpjT2jvGBEnrw4WpNgCsk+
884qhbcqX/aQ2zexSViIIkzOQmemxobh0RIJq0SUcAsrBB4WGP8p84v4D+n+
YHfqNIf47vz5P94RejmNQN/jn6eE5U+c0cCFNhiz/pdBpvHTwoLk8fE/DMv4
F4zY9DP+LdMQzI/erBemRQOeJJ/E7iMp0G/UI5wk98bXFNBbCvZgml1hjkg5
KCBK/st3rQYRsd2YwjFAa7Lx0IfpQ7cbb6yMjSR6KfJAuswGZU0NqrGlceB8
aXKn+kjHiiewZP95x0vrfpA1LzwfXK7LnRKMYxI7J6ncwfA0XQwdLErvQXHt
BwSRTeVQ+AktgmgpuVDi1+EmUDgl3R7qjySLMbbl4Tf8uHjpD/dDnWC8Th2M
5zwBteAOrxmDU11IFzcfnpXTH25Z5HXyWhj2gHw3kHBz62zy2o0Hoy8H129m
1nAHEYAX3wmUp6sPxmKzPQpvo0ble1a9m31jeRkJWkTeFB0N5sBYNNk2Qxz0
/EgwpKh2RlYbzCEhX05fmYxeJTaK5Bw3in95yx3cEnZRcdfykpbkfUpspgwW
Yo0afEIT3TQOuKcWOnyIXfuHsCaWx0QyhAdj6iz7T3kP4w9CmFEq/3IujkIW
t31nP9E1g6APr9irUXtHHNELXIT948tC5WcS0p+P4vbwLZI/SBx/aPOzxRzC
CEgC4e4nM1h4VRelDzB7ZXwnpjX/SFrKLY0Lb2XgpGt06FTPk8LQQ3Sinq/E
/SL2822AUusIMbwsO6cG4gpMMOklH8Qjvzwg8fr6Dh83ZmR3zOcuem9uOKI2
izARvn5kb0NT/MuNF2Y958WG54PUSJGUtckN2/v6AlO22QoT5JQ6E5/07f2L
o8mLI7FYQ8CIFuReZ76r42d14/sOp28Uirk18Wsd9yyS1/Steo/HW4mhwRO9
iXHemFwadi0FzmB+LxZd5TeC74krSuezXAmwnIfyL4NSMGGFqTkEgN7oxMQ3
p+pbvB7qqDY4nC5tbNhOCXza8DaoXp1geGkSS4yKTkiwJfEVwUniIE3p7QVL
23tThW+2J3lJdv/I45035IrXjVofFbrgyZsnY2yNedjjEENO7C0rbLDM7wFj
KoFDaFbLNpZObp5xBNw1l0uWGE2ah1ehRHNH3qhEfUVX/U78/qVO8TVvVJ3M
I7gvqoWn8ZT6dBmiAPxl1ida79WhDB3EwRCK5CU5aqffoxnPz2HbL/ZtDx4/
Tcfgu2nfv9/lqg15fyVXjVNxs0eOxCj4tWlAHOFWMXHSe9Ygm2Fnv72h1req
qsWBRv81PM8vwEm1fmglzQ422ADc/lBjn1K1dnReEXoJT2Kq93KA8MYRq0o7
B7JYJBwnw+T9ai3KUt83kl9xJt1fm6Zb9l9YEtzgEJ/DVmpljiI9PNyL85L4
wHqNtZefxEgNvaTDd2vFUuGsDTd7Rz0mooQvNU/DuuTimt63STG3ggPOylT1
wpQ1vUKNxyTv5+2BJs0zK2r3htlaH9tOXz8bD40qeW1ORtkCeyNzNbcEWRmL
+EIGnB35ogLwSrviWo7Tw28O1+gfy+dZ0wjj08IUwDclvRBvQxB/5+Xe4dHV
Lvkm2PQyNoWgNQZs5FlHIv3dMvfSgbnjwcHnKXfgS6Hfvx/xVL2I1zDaEPsQ
oCEB5xibDNz7mG2odB/3UAThXffVKExyRx7DD73wLU/dPYVv7wYJbjLr31Hx
nSmBd/Uxlfss0/TTpp/XlhyAjO1kSgXJf+764bHpB+xBPj+mOYXQP9DwB+W5
wDwYuOH2ePpDiiC13VLLYiMk20vvwoRqG12iBfMZD0QJwOFEpTaRSjCgUC+A
4MPnQ5+PB3v7B080KO95CO4N5+9hJ6wFZ8RE4i+R/UIaoTe890hEPPwPk0if
OvjEP4I6wm9+NTyNzVGE4bliO9sbomDA0SNGsDQ2IBMT3z7+Iuc3WJXUjhOc
Iut7rGBHTXlFFXgl79+/fXuHJ49fi4EP2hSE1WGGQf7S5nPuiMslex2+o4l8
jupaP7fVj2YB5/DfJu+uSYC8KG9XlT42N0V8RVCB//KbncT6xl/bWVeqxkqn
i34Ul8UllXhS4wsMyPLKcmT/AOMSTGp9VvDfX3fm1srvL8BLKJ+BXviZH/rq
ir4cA+Jk9ASsJvpnakp5G7A+AsfVwJINGNjxBbF+MnBC6OmvMnyMp1L/Bwz6
2q8cgwAA
</rfc> </rfc>
 End of changes. 127 change blocks. 
1228 lines changed or deleted 622 lines changed or added

This html diff was produced by rfcdiff 1.48.