rfc9533xml2.original.xml   rfc9533.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
<?rfc toc="yes"?> nsus="true" docName="draft-ietf-ippm-otwamp-on-lag-08" number="9533" ipr="trust2
<?rfc tocompact="yes"?> 00902" sortRefs="true" submissionType="IETF" tocInclude="true" obsoletes="" upda
<?rfc tocdepth="3"?> tes="" xml:lang="en" tocDepth="3" symRefs="true" prepTime="2024-01-31T15:57:19"
<?rfc tocindent="yes"?> indexInclude="true" scripts="Common,Latin">
<?rfc symrefs="yes"?> <link href="https://datatracker.ietf.org/doc/draft-ietf-ippm-otwamp-on-lag-08"
<?rfc sortrefs="yes"?> rel="prev"/>
<?rfc comments="yes"?> <link href="https://dx.doi.org/10.17487/rfc9533" rel="alternate"/>
<?rfc inline="yes"?> <link href="urn:issn:2070-1721" rel="alternate"/>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" consensus="true"
docName="draft-ietf-ippm-otwamp-on-lag-08" ipr="trust200902"
sortRefs="true" submissionType="IETF" tocInclude="true">
<front> <front>
<title abbrev="O/TWAMP PM on LAG">One-way/Two-way Active Measurement <title abbrev="OWAMP/TWAMP PM on LAG">One-Way and Two-Way Active Measurement
Protocol Extensions for Performance Measurement on LAG</title> Protocol Extensions for Performance Measurement on a Link Aggregation Group</ti
tle>
<seriesInfo name="RFC" value="9533" stream="IETF"/>
<author fullname="Zhenqiang Li" initials="Z." surname="Li"> <author fullname="Zhenqiang Li" initials="Z." surname="Li">
<organization>China Mobile</organization> <organization showOnFrontPage="true">China Mobile</organization>
<address> <address>
<postal> <postal>
<street>No. 29 Finance Avenue, Xicheng District</street> <street>No. 29 Finance Avenue</street>
<cityarea>Xicheng District</cityarea>
<city>Beijing</city> <city>Beijing</city>
<code/> <code/>
<country>China</country> <country>China</country>
</postal> </postal>
<email>li_zhenqiang@hotmail.com</email> <email>li_zhenqiang@hotmail.com</email>
</address> </address>
</author> </author>
<author fullname="Tianran Zhou" initials="T." surname="Zhou"> <author fullname="Tianran Zhou" initials="T." surname="Zhou">
<organization>Huawei</organization> <organization showOnFrontPage="true">Huawei</organization>
<address> <address>
<postal> <postal>
<street/>
<country>China</country> <country>China</country>
</postal> </postal>
<email>zhoutianran@huawei.com</email> <email>zhoutianran@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Jun Guo" initials="J." surname="Guo"> <author fullname="Jun Guo" initials="J." surname="Guo">
<organization>ZTE Corp.</organization> <organization showOnFrontPage="true">ZTE Corp.</organization>
<address> <address>
<postal> <postal>
<street/>
<city/>
<region/>
<code/>
<country>China</country> <country>China</country>
</postal> </postal>
<phone/> <phone/>
<facsimile/>
<email>guo.jun2@zte.com.cn</email> <email>guo.jun2@zte.com.cn</email>
<uri/> <uri/>
</address> </address>
</author> </author>
<author fullname="Greg Mirsky" initials="G." surname="Mirsky"> <author fullname="Greg Mirsky" initials="G." surname="Mirsky">
<organization>Ericsson</organization> <organization showOnFrontPage="true">Ericsson</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>gregimirsky@gmail.com</email> <email>gregimirsky@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Rakesh Gandhi" initials="R." surname="Gandhi"> <author fullname="Rakesh Gandhi" initials="R." surname="Gandhi">
<organization>Cisco</organization> <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street/>
<city/>
<region/>
<code/>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<phone/> <phone/>
<facsimile/>
<email>rgandhi@cisco.com</email> <email>rgandhi@cisco.com</email>
<uri/> <uri/>
</address> </address>
</author> </author>
<date month="01" year="2024"/>
<date day="11" month="December" year="2023"/> <area>Transport Area</area>
<area>Operation and Management Area</area>
<workgroup>IPPM</workgroup> <workgroup>IPPM</workgroup>
<abstract pn="section-abstract">
<abstract> <t indent="0" pn="section-abstract-1">This document defines extensions to
<t>This document defines extensions to One-way Active Measurement the One-Way Active Measurement
Protocol (OWAMP), and Two-way Active Measurement Protocol (TWAMP) to Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) to
implement performance measurement on every member link of a Link implement performance measurement on every member link of a Link
Aggregation Group (LAG). Knowing the measured metrics of each member Aggregation Group (LAG). Knowing the measured metrics of each member
link of a LAG enables operators to enforce the performance based traffic link of a LAG enables operators to enforce the performance-based traffic
steering policy across the member links.</t> steering policy across the member links.</t>
</abstract> </abstract>
<boilerplate>
<note title="Requirements Language"> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "exclude" pn="section-boilerplate.1">
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <name slugifiedName="name-status-of-this-memo">Status of This Memo</name
"OPTIONAL" in this document are to be interpreted as described in BCP 14 >
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, <t indent="0" pn="section-boilerplate.1-1">
they appear in all capitals, as shown here.</t> This is an Internet Standards Track document.
</note> </t>
<t indent="0" pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
</t>
<t indent="0" pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc9533" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t indent="0" pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-introduction">
Introduction</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.1.2">
<li pn="section-toc.1-1.1.2.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><
xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.
1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-re
quirements-language">Requirements Language</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref der
ivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-micro-sessions
-on-a-lag">Micro Sessions on a LAG</xref></t>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-micro-owamp-session">Micro OWAMP S
ession</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.3.2">
<li pn="section-toc.1-1.3.2.1">
<t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent=
"3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-micro-owamp-control">M
icro OWAMP-Control</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2">
<t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent=
"3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-micro-owamp-test">Micr
o OWAMP-Test</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-micro-twamp-session">Micro TWAMP S
ession</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.4.2">
<li pn="section-toc.1-1.4.2.1">
<t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent=
"4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-micro-twamp-control">M
icro TWAMP-Control</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2">
<t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent=
"4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-micro-twamp-test">Micr
o TWAMP-Test</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.4.2.2.2">
<li pn="section-toc.1-1.4.2.2.2.1">
<t indent="0" pn="section-toc.1-1.4.2.2.2.1.1"><xref derived
Content="4.2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-sender-pac
ket-format-and-co">Sender Packet Format and Content</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2.2.2">
<t indent="0" pn="section-toc.1-1.4.2.2.2.2.1"><xref derived
Content="4.2.2" format="counter" sectionFormat="of" target="section-4.2.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-sender-beh
avior">Sender Behavior</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2.2.3">
<t indent="0" pn="section-toc.1-1.4.2.2.2.3.1"><xref derived
Content="4.2.3" format="counter" sectionFormat="of" target="section-4.2.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-reflector-
packet-format-and">Reflector Packet Format and Content</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2.2.4">
<t indent="0" pn="section-toc.1-1.4.2.2.2.4.1"><xref derived
Content="4.2.4" format="counter" sectionFormat="of" target="section-4.2.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-reflector-
behavior">Reflector Behavior</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-applicability">Applicability</xref
></t>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent=
"6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-micro-owamp-control-co
mmand">Micro OWAMP-Control Command</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2">
<t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent=
"6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-micro-twamp-control-co
mmand">Micro TWAMP-Control Command</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-security-considerations">Security
Considerations</xref></t>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-references">References</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.8.2">
<li pn="section-toc.1-1.8.2.1">
<t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent=
"8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-normative-references">
Normative References</xref></t>
</li>
<li pn="section-toc.1-1.8.2.2">
<t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent=
"8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-informative-references
">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" forma
t="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent=""
format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgemen
ts</xref></t>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
<t>Link Aggregation Group (LAG), as defined in <xref <name slugifiedName="name-introduction">Introduction</name>
target="IEEE802.1AX"/>, provides mechanisms to combine multiple physical <t indent="0" pn="section-1-1">A Link Aggregation Group (LAG), as defined
in <xref target="IEEE802.1AX" format="default" sectionFormat="of" derivedContent
="IEEE802.1AX"/>, provides mechanisms to combine multiple physical
links into a single logical link. This logical link offers higher links into a single logical link. This logical link offers higher
bandwidth and better resiliency, because if one of the physical member bandwidth and better resiliency because, if one of the physical member
links fails, the aggregate logical link can continue to forward traffic links fails, the aggregate logical link can continue to forward traffic
over the remaining operational physical member links.</t> over the remaining operational physical member links.</t>
<t indent="0" pn="section-1-2">Usually, when forwarding traffic over a LAG
<t>Usually, when forwarding traffic over LAG, a hash-based mechanism is , a hash-based mechanism is
used to load balance the traffic across the LAG member links. The link used to load balance the traffic across the LAG member links. The link
delay might vary between member links because of different transport delay might vary between member links because of different transport
paths, especially when LAG is used in wide area network. To provide low paths, especially when a LAG is used in a wide area network. To provide lo
latency service for time sensitive traffic, we need to explicitly steer w-latency service for time-sensitive traffic, we need to explicitly steer
the traffic across the LAG member links based on the link delay, loss the traffic across the LAG member links based on the link delay, loss,
and so on. That requires a solution to measure the performance metrics and so on. That requires a solution to measure the performance metrics
of every member link of a LAG. Hence, the measured performance metrics of every member link of a LAG. Hence, the measured performance metrics
can work together with <xref target="RFC8668">layer 2 bundle member link can work together with Layer 2 bundle member link
attributes advertisement</xref> for traffic steering.</t> attributes advertisement <xref target="RFC8668" format="default" sectionFo
rmat="of" derivedContent="RFC8668"/> for traffic steering.</t>
<t>According to the classifications in <xref target="RFC7799"/>, <xref <t indent="0" pn="section-1-3">According to the classifications in <xref t
target="RFC4656">OWAMP</xref> and <xref target="RFC5357">TWAMP</xref> arget="RFC7799" format="default" sectionFormat="of" derivedContent="RFC7799"/>,
OWAMP <xref target="RFC4656" format="default" sectionFormat="of" derivedContent=
"RFC4656"/> and TWAMP <xref target="RFC5357" format="default" sectionFormat="of"
derivedContent="RFC5357"/>
are active measurement methods, and they can complement passive and are active measurement methods, and they can complement passive and
hybrid methods. With either method, one test session over the LAG can hybrid methods. With either method, one test session over the LAG can be
measure the performance of a member link with fixed five tuples. Or it used to measure the performance of a member link using a specially constructed 5
can measure an average of some/all member links of the LAG by varying -tuple. The session can be used to measure an average of some or all member link
the five tuples. However, without the knowledge of each member link, a s of the LAG by varying one or more elements of that 5-tuple. However, without
the knowledge of each member link, a
test session cannot measure the performance of every physical member test session cannot measure the performance of every physical member
link.</t> link.</t>
<t indent="0" pn="section-1-4">This document extends OWAMP and TWAMP to im
<t>This document extends OWAMP and TWAMP to implement performance plement performance
measurement on every member link of a LAG. It can provide the same measurement on every member link of a LAG. It can provide the same
metrics as OWAMP and TWAMP can measure, such as delay, jitter and packet metrics as OWAMP and TWAMP can measure, such as delay, jitter, and packet
loss.</t> loss.</t>
<section numbered="true" toc="include" removeInRFC="false" pn="section-1.1
">
<name slugifiedName="name-requirements-language">Requirements Language</
name>
<t indent="0" pn="section-1.1-1">
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP 14 <xref target="RFC2119" format="default" s
ectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="defa
ult" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they app
ear in all capitals, as
shown here.
</t>
</section>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-2">
<section title="Micro Session on LAG"> <name slugifiedName="name-micro-sessions-on-a-lag">Micro Sessions on a LAG
<t>This document addresses the scenario where a LAG directly connects </name>
two nodes. An example of this is in Figure 1, where the LAG consisting <t indent="0" pn="section-2-1">This document addresses the scenario where
a LAG directly connects
two nodes. An example of this is in <xref target="PMonLAG" format="default
" sectionFormat="of" derivedContent="Figure 1"/>, where the LAG consisting
of four links connects nodes A and B. The goal is to measure the of four links connects nodes A and B. The goal is to measure the
performance of each link of the LAG.</t> performance of each link of the LAG.</t>
<figure anchor="PMonLAG" align="left" suppress-title="false" pn="figure-1"
<figure align="center" anchor="PMonLAG" >
title="Performance Measurement on LAG"> <name slugifiedName="name-performance-measurement-on-">Performance Measu
<artwork><![CDATA[ +---+ +---+ rement on a LAG</name>
<artwork name="" type="" align="left" alt="" pn="section-2-2.1">
+---+ +---+
| |-----------------------| | | |-----------------------| |
| A |-----------------------| B | | A |-----------------------| B |
| |-----------------------| | | |-----------------------| |
| |-----------------------| | | |-----------------------| |
+---+ +---+ +---+ +---+
]]></artwork> </artwork>
</figure> </figure>
<t indent="0" pn="section-2-3">To measure the performance metrics of every
<t>To measure the performance metrics of every member link of a LAG, member link of a LAG,
multiple sessions (one session for each member link) need to be multiple sessions (one session for each member link) need to be
established between the two end points that are connected by the LAG. established between the two endpoints that are connected by the LAG.
These sessions are called micro sessions in the remainder of this These sessions are called "micro sessions" in the remainder of this
document. Although micro sessions are in fact OWAMP or TWAMP sessions document. Although micro sessions are in fact OWAMP or TWAMP sessions
established on member links of a LAG, test packets of micro TWAMP established on member links of a LAG, test packets of micro TWAMP
sessions MUST carry member link information for validation.</t> sessions <bcp14>MUST</bcp14> carry member link information for validation.
</t>
<t>All micro sessions of a LAG share the same Sender IP Address and <t indent="0" pn="section-2-4">All micro sessions of a LAG share the same
Receiver IP Address of the LAG. As for the UDP layer, the micro sessions Sender IP Address and
may share the same Sender Port and Receiver Port pair, or each micro Receiver IP Address. As for the UDP port, the micro sessions
session is configured with a different Sender Port and Receiver Port may share the same Sender Port and Receiver Port pair or each micro
pair. But from the operational point of view, the former is simpler and session may be configured with a different Sender Port and Receiver Port
is RECOMMENDED.</t> pair. From the operational point of view, the former is simpler and
is <bcp14>RECOMMENDED</bcp14>.</t>
<t>Test packets of a micro session MUST carry the member link <t indent="0" pn="section-2-5">Test packets of a micro session <bcp14>MUST
information for validation check. For example, when a micro TWAMP </bcp14> carry the member link
information for validation checks. For example, when a micro TWAMP
Session-Sender receives a reflected test packet, it checks whether the Session-Sender receives a reflected test packet, it checks whether the
test packet is from the expected member link.</t> test packet is from the expected member link.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-3">
<section title="Micro OWAMP Session"> <name slugifiedName="name-micro-owamp-session">Micro OWAMP Session</name>
<section title="Micro OWAMP-Control"> <section numbered="true" toc="include" anchor="micro" removeInRFC="false"
<t>To support the micro OWAMP session, a new command, pn="section-3.1">
Request-OW-Micro-Sessions (TBD1), is defined in this document. The <name slugifiedName="name-micro-owamp-control">Micro OWAMP-Control</name
>
<t indent="0" pn="section-3.1-1">To support the micro OWAMP session, a n
ew command,
Request-OW-Micro-Sessions (5), is defined in this document. The
Request-OW-Micro-Sessions command is based on the OWAMP Request-OW-Micro-Sessions command is based on the OWAMP
Request-Session command, and uses the message format as described in Request-Session command and uses the message format as described in
Section 3.5 of <xref target="RFC4656">OWAMP</xref>. Test session <xref target="RFC4656" sectionFormat="of" section="3.5" format="default"
creation of micro OWAMP session follows the same procedure as defined derivedLink="https://rfc-editor.org/rfc/rfc4656#section-3.5" derivedContent="RF
in Section 3.5 of <xref target="RFC4656">OWAMP</xref> with the C4656"/>. Test session
creation of micro OWAMP sessions follows the same procedure as defined
in <xref target="RFC4656" sectionFormat="of" section="3.5" format="defau
lt" derivedLink="https://rfc-editor.org/rfc/rfc4656#section-3.5" derivedContent=
"RFC4656"/> with the
following additions:</t> following additions:</t>
<t indent="0" pn="section-3.1-2">When an OWAMP Server receives a Request
<t>When an OWAMP Server receives a Request-OW-Micro-Sessions command, -OW-Micro-Sessions command,
if the request is accepted, the OWAMP Server MUST build a set of micro if the request is accepted, the OWAMP Server <bcp14>MUST</bcp14> build a
set of micro
sessions for all the member links of the LAG from which the sessions for all the member links of the LAG from which the
Request-OW-Micro-Sessions message is received.</t> Request-OW-Micro-Sessions message is received.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-3.2
<section title="Micro OWAMP-Test"> ">
<t>Micro OWAMP-Test reuses the OWAMP-Test packet format and procedures <name slugifiedName="name-micro-owamp-test">Micro OWAMP-Test</name>
as defined in Section 4 of <xref target="RFC4656">OWAMP</xref> with <t indent="0" pn="section-3.2-1">Micro OWAMP-Test reuses the OWAMP-Test
packet format and procedures
as defined in <xref target="RFC4656" sectionFormat="of" section="4" form
at="default" derivedLink="https://rfc-editor.org/rfc/rfc4656#section-4" derivedC
ontent="RFC4656"/> with
the following additions:</t> the following additions:</t>
<t indent="0" pn="section-3.2-2">The micro OWAMP Session-Sender <bcp14>M
<t>The micro OWAMP Session-Sender MUST send the micro OWAMP-Test UST</bcp14> send the micro OWAMP-Test
packets over the member link with which the session is associated. packets over the member link with which the session is associated.
When it receives a test packet, the micro OWAMP Session-Receiver MUST When it receives a test packet, the micro OWAMP Session-Receiver <bcp14> MUST</bcp14>
use the member link from which the test packet is received to use the member link from which the test packet is received to
correlate the micro OWAMP session. If there is no such a session, the correlate the micro OWAMP session. If there is no such session, the
Test packet MUST be discarded.</t> test packet <bcp14>MUST</bcp14> be discarded.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4">
<section title="Micro TWAMP Session"> <name slugifiedName="name-micro-twamp-session">Micro TWAMP Session</name>
<section title="Micro TWAMP-Control"> <section numbered="true" toc="include" anchor="micro2" removeInRFC="false"
<t>To support the micro TWAMP session, a new command, pn="section-4.1">
Request-TW-Micro-Sessions (TBD2), is defined in this document. The <name slugifiedName="name-micro-twamp-control">Micro TWAMP-Control</name
>
<t indent="0" pn="section-4.1-1">To support the micro TWAMP session, a n
ew command,
Request-TW-Micro-Sessions (11), is defined in this document. The
Request-TW-Micro-Sessions command is based on the TWAMP Request-TW-Micro-Sessions command is based on the TWAMP
Request-Session command, and uses the message format as described in Request-Session command and uses the message format as described in
Section 3.5 of <xref target="RFC5357">TWAMP</xref>. Test session <xref target="RFC5357" sectionFormat="of" section="3.5" format="default"
creation of micro TWAMP session follows the same procedure as defined derivedLink="https://rfc-editor.org/rfc/rfc5357#section-3.5" derivedContent="RF
in Section 3.5 of <xref target="RFC5357">TWAMP</xref> with the C5357"/>. Test session
creation of micro TWAMP sessions follows the same procedure as defined
in <xref target="RFC5357" sectionFormat="of" section="3.5" format="defau
lt" derivedLink="https://rfc-editor.org/rfc/rfc5357#section-3.5" derivedContent=
"RFC5357"/> with the
following additions:</t> following additions:</t>
<t indent="0" pn="section-4.1-2">When a TWAMP Server receives a Request-
<t>When a TWAMP Server receives a Request-TW-Micro-Sessions command, TW-Micro-Sessions command,
if the request is accepted, the TWAMP Server MUST build a set of micro if the request is accepted, the TWAMP Server <bcp14>MUST</bcp14> build a
set of micro
sessions for all the member links of the LAG from which the sessions for all the member links of the LAG from which the
Request-TW-Micro-Sessions message is received.</t> Request-TW-Micro-Sessions message is received.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4.2
<section title="Micro TWAMP-Test"> ">
<t>The micro TWAMP-Test protocol is based on the TWAMP-Test protocol <name slugifiedName="name-micro-twamp-test">Micro TWAMP-Test</name>
<xref target="RFC5357"/> with the following extensions.</t> <t indent="0" pn="section-4.2-1">The micro TWAMP-Test protocol is based
on the TWAMP-Test protocol
<section title="Sender Packet Format and Content"> <xref target="RFC5357" format="default" sectionFormat="of" derivedConten
<t>The micro TWAMP Session-Sender packet format is based on the t="RFC5357"/> with the extensions described in the following subsections.</t>
TWAMP Session-Sender packet format as defined in Section 4.1.2 of <section numbered="true" toc="include" removeInRFC="false" pn="section-4
<xref target="RFC5357"/>. Two new fields (Sender Micro-session ID .2.1">
<name slugifiedName="name-sender-packet-format-and-co">Sender Packet F
ormat and Content</name>
<t indent="0" pn="section-4.2.1-1">The micro TWAMP Session-Sender pack
et format is based on the
TWAMP Session-Sender packet format as defined in
<xref target="RFC5357" sectionFormat="of" section="4.1.2" format="defa
ult" derivedLink="https://rfc-editor.org/rfc/rfc5357#section-4.1.2" derivedConte
nt="RFC5357"/>. Two new fields (Sender Micro-session ID
and Reflector Micro-session ID) are added to carry the LAG member and Reflector Micro-session ID) are added to carry the LAG member
link identifiers.</t> link identifiers.</t>
<t indent="0" pn="section-4.2.1-2">For unauthenticated mode, the forma
<t>For unauthenticated mode, the format is as below:</t> t is as below:</t>
<figure anchor="TWAMPSender" align="left" suppress-title="false" pn="f
<t> igure-2">
<figure align="center" anchor="TWAMPSender" <name slugifiedName="name-micro-session-sender-packet">Micro Session
title="Micro Session-Sender Packet Format in Unauthenticated -Sender Packet Format in Unauthenticated Mode</name>
Mode"> <artwork name="" type="" align="left" alt="" pn="section-4.2.1-3.1">
<artwork><![CDATA[ 0 1 2 0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | MBZ | | Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Micro-session ID | Reflector Micro-session ID | | Sender Micro-session ID | Reflector Micro-session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Packet Padding . . Packet Padding .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> </artwork>
</figure> </figure>
</t> <t indent="0" pn="section-4.2.1-4">For authenticated and encrypted mod
e, the format is as below:</t>
<t>For authenticated mode, the format is as below:<figure <figure anchor="TWAMPSenderA" align="left" suppress-title="false" pn="
align="center" anchor="TWAMPSenderA" figure-3">
title="Micro Session-Sender Packet Format in Authenticated Mode"> <name slugifiedName="name-micro-session-sender-packet-">Micro Sessio
<artwork><![CDATA[ 0 1 2 n-Sender Packet Format in Authenticated Mode</name>
3 <artwork name="" type="" align="left" alt="" pn="section-4.2.1-5.1">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| MBZ (12 octets) | | MBZ (12 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
skipping to change at line 330 skipping to change at line 384
| | | |
| HMAC (16 octets) | | HMAC (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Packet Padding . . Packet Padding .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> </artwork>
</figure></t> </figure>
<t indent="0" pn="section-4.2.1-6">Except for the Sender Micro-session
<t>Except for the Sender/Reflector Micro-session ID field, all the ID field and the Reflector Micro-session ID field, all the
other fields are the same as defined in Section 4.1.2 of <xref other fields are the same as defined in <xref target="RFC5357" section
target="RFC5357">TWAMP</xref>, which is defined in Section 4.1.2 of Format="of" section="4.1.2" format="default" derivedLink="https://rfc-editor.org
<xref target="RFC4656">OWAMP</xref>. Therefore, it follows the same /rfc/rfc5357#section-4.1.2" derivedContent="RFC5357"/> and follow the procedure
procedure and guidelines as defined in Section 4.1.2 of <xref and guidelines defined therein.</t>
target="RFC5357">TWAMP</xref>.</t> <dl spacing="normal" indent="3" newline="false" pn="section-4.2.1-7">
<dt pn="section-4.2.1-7.1">Sender Micro-session ID (2 octets in leng
<t> th):</dt>
<list style="symbols"> <dd pn="section-4.2.1-7.2">This field is defined to carry the LAG m
<t>Sender Micro-session ID (2-octets in length): It is now ember link identifier of the Sender
defined to carry the LAG member link identifier of the Sender
side. In the future, it may be used generically to cover side. In the future, it may be used generically to cover
use-cases beyond LAG. The value of this field MUST be unique use cases beyond LAGs. The value of this field <bcp14>MUST</bcp14>
within a TWAMP session at the Session-Sender.</t> be unique
within a TWAMP session at the Session-Sender.</dd>
<t>Reflector Micro-session ID (2-octets in length): It is now <dt pn="section-4.2.1-7.3">Reflector Micro-session ID (2 octets in l
ength):</dt>
<dd pn="section-4.2.1-7.4">This field is
defined to carry the LAG member link identifier of the Reflector defined to carry the LAG member link identifier of the Reflector
side. In the future, it may be used generically to cover side. In the future, it may be used generically to cover
use-cases beyond LAG. The value of this field MUST be unique use cases beyond LAGs. The value of this field <bcp14>MUST</bcp14>
within a TWAMP session at the Session-Reflector.</t> be unique
</list> within a TWAMP session at the Session-Reflector.</dd>
</t> </dl>
<t/>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4
<section title="Sender Behavior"> .2.2">
<t>The micro TWAMP Session-Sender inherits the behaviors of the <name slugifiedName="name-sender-behavior">Sender Behavior</name>
TWAMP Session-Sender as defined in Section 4.1 of <xref <t indent="0" pn="section-4.2.2-1">The micro TWAMP Session-Sender inhe
target="RFC5357"/>. In addition, the micro TWAMP Session-Sender MUST rits the behaviors of the
TWAMP Session-Sender as defined in <xref target="RFC5357" sectionForma
t="of" section="4.1" format="default" derivedLink="https://rfc-editor.org/rfc/rf
c5357#section-4.1" derivedContent="RFC5357"/>. In addition, the micro TWAMP Sess
ion-Sender <bcp14>MUST</bcp14>
send the micro Session-Sender test packets over the member link with send the micro Session-Sender test packets over the member link with
which the session is associated.</t> which the session is associated.</t>
<t indent="0" pn="section-4.2.2-2">When sending the test packet, the m
<t>When sending the test packet, the micro TWAMP Session-Sender MUST icro TWAMP Session-Sender <bcp14>MUST</bcp14>
put the Sender member link identifier that is associated with the put the Sender member link identifier that is associated with the
micro TWAMP session in the Sender Micro-session ID. If the micro TWAMP session in the Sender Micro-session ID. If the
Session-Sender knows the Reflector member link identifier, the Session-Sender knows the Reflector member link identifier, the
Reflector Micro-session ID field (see <xref target="TWAMPSender"/> Reflector Micro-session ID field (see Figures <xref target="TWAMPSende
and <xref target="TWAMPSenderA"/>) MUST be set. Otherwise, the r" format="counter" sectionFormat="of" derivedContent="2"/>
Reflector Micro-session ID field MUST be zero.</t> and <xref target="TWAMPSenderA" format="counter" sectionFormat="of" de
rivedContent="3"/>) <bcp14>MUST</bcp14> be set. Otherwise, the
<t>A test packet with Sender member link identifier is sent to the Reflector Micro-session ID field <bcp14>MUST</bcp14> be zero.</t>
Session-Reflector, and then is reflected with the same Sender member <t indent="0" pn="section-4.2.2-3">A test packet with a Sender member
link identifier is sent to the
Session-Reflector and then is reflected with the same Sender member
link identifier. So the Session-Sender can use the Sender member link identifier. So the Session-Sender can use the Sender member
link identifier to check whether a reflected test packet is received link identifier to check whether a reflected test packet is received
from the member link associated with the correct micro TWAMP from the member link associated with the correct micro TWAMP
session.</t> session.</t>
<t indent="0" pn="section-4.2.2-4">The Reflector member link identifie
<t>The Reflector member link identifier carried in the Reflector r carried in the Reflector
Micro-session ID field is used by the Session-Reflector to check Micro-session ID field is used by the Session-Reflector to check
whether a test packet is received from the member link associated whether a test packet is received from the member link associated
with the correct micro TWAMP session. It means that the with the correct micro TWAMP session. It means that the
Session-Sender has to learn the Reflector member link identifier. Session-Sender has to learn the Reflector member link identifier.
Once the Session-Sender knows the Reflector member link identifier, Once the Session-Sender knows the Reflector member link identifier,
it MUST put the identifier in the Reflector Micro-session ID field it <bcp14>MUST</bcp14> put the identifier in the Reflector Micro-sessi
(see <xref target="TWAMPSender"/> or <xref target="TWAMPSenderA"/>) on ID field
(see Figures <xref target="TWAMPSender" format="counter" sectionFormat
="of" derivedContent="2"/> or <xref target="TWAMPSenderA" format="counter" secti
onFormat="of" derivedContent="3"/>)
of the test packets that will be sent to the Session-Reflector. The of the test packets that will be sent to the Session-Reflector. The
Reflector member link identifier can be obtained from Reflector member link identifier can be obtained from
pre-configuration or learned from the data plane (e.g., the preconfiguration or learned from the data plane (e.g., the
reflected test packet). This document does not specify the way to reflected test packet). This document does not specify the way to
obtain the Reflector member link identifier.</t> obtain the Reflector member link identifier.</t>
<t indent="0" pn="section-4.2.2-5">When receiving a reflected test pac
<t>When receiving a reflected test packet, the micro TWAMP ket, the micro TWAMP
Session-Sender MUST use the receiving member link to correlate the Session-Sender <bcp14>MUST</bcp14> use the receiving member link to co
rrelate the
reflected test packet to a micro TWAMP session. If there is no such reflected test packet to a micro TWAMP session. If there is no such
a session, the reflected test packet MUST be discarded. If a matched session, the reflected test packet <bcp14>MUST</bcp14> be discarded. I
session exists, the micro Session-Sender MUST use the Sender f a matched
session exists, the micro Session-Sender <bcp14>MUST</bcp14> use the S
ender
Micro-session ID to validate whether the reflected test packet is Micro-session ID to validate whether the reflected test packet is
correctly received from the expected member link. If the validation correctly received from the expected member link. If the validation
fails, the test packet MUST be discarded. The micro Session-Sender fails, the test packet <bcp14>MUST</bcp14> be discarded. The micro Ses
MUST use the Reflector Micro-session ID to validate the Reflector's sion-Sender
behavior. If the validation fails, the test packet MUST be <bcp14>MUST</bcp14> use the Reflector Micro-session ID to validate the
Reflector's
behavior. If the validation fails, the test packet <bcp14>MUST</bcp14>
be
discarded.</t> discarded.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4
<section title="Reflector Packet Format and Content"> .2.3">
<t>The micro TWAMP Session-Reflector packet format is based on the <name slugifiedName="name-reflector-packet-format-and">Reflector Packe
TWAMP Session-Reflector packet format as defined in Section 4.2.1 of t Format and Content</name>
<xref target="RFC5357"/>. Two new fields (Sender and Reflector <t indent="0" pn="section-4.2.3-1">The micro TWAMP Session-Reflector p
acket format is based on the
TWAMP Session-Reflector packet format as defined in
<xref target="RFC5357" sectionFormat="of" section="4.2.1" format="defa
ult" derivedLink="https://rfc-editor.org/rfc/rfc5357#section-4.2.1" derivedConte
nt="RFC5357"/>. Two new fields (Sender and Reflector
Micro-session ID) are added to carry the LAG member link Micro-session ID) are added to carry the LAG member link
identifiers.</t> identifiers.</t>
<t indent="0" pn="section-4.2.3-2">For unauthenticated mode, the forma
<t>For unauthenticated mode, the format is as below:</t> t is as below:</t>
<figure anchor="TWAMPReflector" align="left" suppress-title="false" pn
<t> ="figure-4">
<figure align="center" anchor="TWAMPReflector" <name slugifiedName="name-micro-session-reflector-pac">Micro Session
title="Micro Session-Reflector Packet Format in Unauthentica -Reflector Packet Format in Unauthenticated Mode</name>
ted Mode"> <artwork name="" type="" align="left" alt="" pn="section-4.2.3-3.1">
<artwork><![CDATA[ 0 1 2 0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | MBZ | | Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Timestamp | | Receive Timestamp |
| | | |
skipping to change at line 448 skipping to change at line 485
| Sender Error Estimate | Sender Micro-session ID | | Sender Error Estimate | Sender Micro-session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender TTL | MBZ | Reflector Micro-session ID | | Sender TTL | MBZ | Reflector Micro-session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Packet Padding . . Packet Padding .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> </artwork>
</figure> </figure>
</t> <t indent="0" pn="section-4.2.3-4">For authenticated and encrypted mod
e, the format is as below:</t>
<t>For authenticated mode, the format is as below:</t> <figure anchor="TWAMPReflectorA" align="left" suppress-title="false" p
n="figure-5">
<name slugifiedName="name-micro-session-reflector-pack">Micro Sessio
n-Reflector Packet Format in Authenticated Mode</name>
<artwork name="" type="" align="left" alt="" pn="section-4.2.3-5.1">
<t> 0 1 2 3
<figure align="center" anchor="TWAMPReflectorA" 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
title="Micro Session-Reflector Packet Format in Authenticate
d Mode">
<artwork><![CDATA[ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (12 octets) | | MBZ (12 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 508 skipping to change at line 543
| HMAC (16 octets) | | HMAC (16 octets) |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Packet Padding . . Packet Padding .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> </artwork>
</figure> </figure>
</t> <t indent="0" pn="section-4.2.3-6">Except for the Sender Micro-session
ID field and the Reflector Micro-session ID field, all the
<t>Except for the Sender/Reflector Micro-session ID field, all the other fields are the same as defined in <xref target="RFC5357" section
other fields are the same as defined in Section 4.2.1 of TWAMP <xref Format="of" section="4.2.1" format="default" derivedLink="https://rfc-editor.org
target="RFC5357"/>. Therefore, it follows the same procedure and /rfc/rfc5357#section-4.2.1" derivedContent="RFC5357"/> and follow the same proce
guidelines as defined in Section 4.2.1 of TWAMP <xref dure and guidelines defined therein.</t>
target="RFC5357"/>.</t> <dl spacing="normal" indent="3" newline="false" pn="section-4.2.3-7">
<dt pn="section-4.2.3-7.1">Sender Micro-session ID (2 octets in leng
<t> th):</dt>
<list style="symbols"> <dd pn="section-4.2.3-7.2">This field is
<t>Sender Micro-session ID (2-octets in length): It is now
defined to carry the LAG member link identifier of the Sender defined to carry the LAG member link identifier of the Sender
side. In the future, it may be used generically to cover side. In the future, it may be used generically to cover
use-cases beyond LAG. The value of this field MUST be unique use cases beyond LAGs. The value of this field <bcp14>MUST</bcp14>
within a TWAMP session at the Session-Sender.</t> be unique
within a TWAMP session at the Session-Sender.</dd>
<t>Reflector Micro-session ID (2-octets in length): It is now <dt pn="section-4.2.3-7.3">Reflector Micro-session ID (2 octets in l
ength):</dt>
<dd pn="section-4.2.3-7.4">This field is
defined to carry the LAG member link identifier of the Reflector defined to carry the LAG member link identifier of the Reflector
side. In the future, it may be used generically to cover side. In the future, it may be used generically to cover
use-cases beyond LAG. The value of this field MUST be unique use cases beyond LAGs. The value of this field <bcp14>MUST</bcp14>
within a TWAMP session at the Session-Reflector.</t> be unique
</list> within a TWAMP session at the Session-Reflector.</dd>
</t> </dl>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4
<section title="Reflector Behavior"> .2.4">
<t>The micro TWAMP Session-Reflector inherits the behaviors of a <name slugifiedName="name-reflector-behavior">Reflector Behavior</name
TWAMP Session-Reflector as defined in Section 4.2 of <xref >
target="RFC5357"/>.</t> <t indent="0" pn="section-4.2.4-1">The micro TWAMP Session-Reflector i
nherits the behaviors of a
<t>In addition, when receiving a test packet, the micro TWAMP TWAMP Session-Reflector as defined in <xref target="RFC5357" sectionFo
Session-Reflector MUST use the receiving member link to correlate rmat="of" section="4.2" format="default" derivedLink="https://rfc-editor.org/rfc
/rfc5357#section-4.2" derivedContent="RFC5357"/>.</t>
<t indent="0" pn="section-4.2.4-2">In addition, when receiving a test
packet, the micro TWAMP
Session-Reflector <bcp14>MUST</bcp14> use the receiving member link to
correlate
the test packet to a micro TWAMP session. If there is no such a the test packet to a micro TWAMP session. If there is no such a
session, the test packet MUST be discarded. If the Reflector session, the test packet <bcp14>MUST</bcp14> be discarded. If the Refl
Micro-session ID is not zero, the Reflector MUST use the Reflector ector
Micro-session ID is not zero, the Reflector <bcp14>MUST</bcp14> use th
e Reflector
Micro-session ID to validate whether it associates with the Micro-session ID to validate whether it associates with the
receiving member link. If the Reflector Micro-session ID is zero, it receiving member link. If the Reflector Micro-session ID is zero, it
will not be verified. If the validation fails, the test packet MUST will not be verified. If the validation fails, the test packet <bcp14> MUST</bcp14>
be discarded.</t> be discarded.</t>
<t indent="0" pn="section-4.2.4-3">When sending a response to the rece
<t>When sending a response to the received test packet, the micro ived test packet, the micro
TWAMP Session-Reflector MUST copy the Sender member link identifier TWAMP Session-Reflector <bcp14>MUST</bcp14> copy the Sender member lin
k identifier
from the received test packet and put it in the Sender Micro-session from the received test packet and put it in the Sender Micro-session
ID field of the reflected test packet (see <xref ID field of the reflected test packet (see Figures <xref target="TWAMP
target="TWAMPReflector"/> and <xref target="TWAMPReflectorA"/>). In Reflector" format="counter" sectionFormat="of" derivedContent="4"/> and <xref ta
addition, the micro TWAMP Session-Reflector MUST fill the Reflector rget="TWAMPReflectorA" format="counter" sectionFormat="of" derivedContent="5"/>)
Micro-session ID field (see <xref target="TWAMPReflector"/> and . In
<xref target="TWAMPReflectorA"/>) of the reflected test packet with addition, the micro TWAMP Session-Reflector <bcp14>MUST</bcp14> fill t
he Reflector
Micro-session ID field (see Figures <xref target="TWAMPReflector" form
at="counter" sectionFormat="of" derivedContent="4"/> and
<xref target="TWAMPReflectorA" format="counter" sectionFormat="of" der
ivedContent="5"/>) of the reflected test packet with
the member link identifier that is associated with the micro TWAMP the member link identifier that is associated with the micro TWAMP
session.</t> session.</t>
</section> </section>
</section> </section>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-5">
<section title="Applicability"> <name slugifiedName="name-applicability">Applicability</name>
<t>To set up the micro OWAMP sessions, the Control-Client firstly sends <t indent="0" pn="section-5-1">To set up the micro OWAMP sessions, the Con
trol-Client sends
the Request-OW-Micro-Sessions command to the OWAMP Server. The OWAMP the Request-OW-Micro-Sessions command to the OWAMP Server. The OWAMP
Server accepts the request, and builds a set of micro sessions for all Server accepts the request and builds a set of micro sessions for all
the member links of the LAG.</t> the member links of the LAG.</t>
<t indent="0" pn="section-5-2">For micro TWAMP sessions, a similar set up
<t>For micro TWAMP sessions, the similar set up procedure as micro OWAMP procedure is used. Then, the micro TWAMP Session-Sender sends micro
sessions is used. Then the micro TWAMP Session-Sender sends micro
Session-Sender packets with the Sender Micro-session ID and the Session-Sender packets with the Sender Micro-session ID and the
Reflector Micro-session ID. The micro Session-Reflector checks whether a Reflector Micro-session ID. If the Reflector Micro-session ID field is set , the micro Session-Reflector checks whether a
test packet is received from the member link associated with the correct test packet is received from the member link associated with the correct
micro TWAMP session, if the Reflector Micro-session ID field is set. micro TWAMP session.
When reflecting, the micro TWAMP Session-Reflector copies the Sender When reflecting, the micro TWAMP Session-Reflector copies the Sender
Micro-session ID from the received micro Session-Sender packet to the Micro-session ID from the received micro Session-Sender packet to the
micro Session-Reflector packet, and sets the Reflector Micro-session ID micro Session-Reflector packet; then, it sets the Reflector Micro-session ID
field with the member link identifier that is associated with the micro field with the member link identifier that is associated with the micro
TWAMP session. When receiving the micro TWAMP Session-Reflector packet, TWAMP session. When receiving the micro TWAMP Session-Reflector packet,
the micro Session-Sender uses the Sender Micro-session ID to check the micro Session-Sender uses the Sender Micro-session ID to check
whether the packet is received from the member link associated with the whether the packet is received from the member link associated with the
correct micro TWAMP session. The micro Session-Sender also uses the correct micro TWAMP session. The micro Session-Sender also uses the
Reflector Micro-session ID to validate the Reflector's behavior.</t> Reflector Micro-session ID to validate the Reflector's behavior.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn=
<section anchor="IANA" title="IANA Considerations"> "section-6">
<section title="Micro OWAMP-Control Command"> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t>This document requires the IANA to allocate the following command <section numbered="true" toc="include" removeInRFC="false" pn="section-6.1
type from OWAMP-Control Command Number Registry.</t> ">
<name slugifiedName="name-micro-owamp-control-command">Micro OWAMP-Contr
<t> ol Command</name>
<figure> <t indent="0" pn="section-6.1-1">IANA has allocated the following comman
<artwork><![CDATA[Value Description Semantics Def d
inition type from the "OWAMP-Control Command Numbers" registry.</t>
TBD1 Request-OW-Micro-Sessions This document, Section 3.1 <table anchor="micro_OWAMP" align="left" pn="table-1">
]]></artwork> <name slugifiedName="name-request-ow-micro-sessions-c">Request-OW-Micr
</figure> o-Sessions Command Number</name>
</t> <thead>
<tr>
<th align="left" colspan="1" rowspan="1">Value</th>
<th align="left" colspan="1" rowspan="1">Description</th>
<th align="left" colspan="1" rowspan="1">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left" colspan="1" rowspan="1">5</td>
<td align="left" colspan="1" rowspan="1">Request-OW-Micro-Sessions
</td>
<td align="left" colspan="1" rowspan="1">This document</td>
</tr>
</tbody>
</table>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-6.2
<section title="Micro TWAMP-Control Command"> ">
<t>This document requires the IANA to allocate the following command <name slugifiedName="name-micro-twamp-control-command">Micro TWAMP-Contr
type from TWAMP-Control Command Number Registry.</t> ol Command</name>
<t indent="0" pn="section-6.2-1">IANA has allocated the following comman
<t> d
<figure> type from the "TWAMP-Control Command Numbers" registry.</t>
<artwork><![CDATA[Value Description Semantics Def <table anchor="micro_TWAMP" align="left" pn="table-2">
inition <name slugifiedName="name-request-tw-micro-sessions-c">Request-TW-Micr
TBD2 Request-TW-Micro-Sessions This document, Section 4.1 o-Sessions Command Number</name>
]]></artwork> <thead>
</figure> <tr>
</t> <th align="left" colspan="1" rowspan="1">Value</th>
<th align="left" colspan="1" rowspan="1">Description</th>
<th align="left" colspan="1" rowspan="1">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left" colspan="1" rowspan="1">11</td>
<td align="left" colspan="1" rowspan="1">Request-TW-Micro-Sessions
</td>
<td align="left" colspan="1" rowspan="1">This document</td>
</tr>
</tbody>
</table>
</section> </section>
</section> </section>
<section anchor="Security" numbered="true" toc="include" removeInRFC="false"
<section anchor="Security" title="Security Considerations"> pn="section-7">
<t>This document does not introduce additional security requirements and <name slugifiedName="name-security-considerations">Security Considerations
mechanisms other than those described in <xref target="RFC4656"/>, and </name>
<xref target="RFC5357"/>.</t> <t indent="0" pn="section-7-1">This document does not introduce additional
</section> security requirements and
mechanisms other than those described in <xref target="RFC4656" format="de
<section anchor="Acknowledgements" title="Acknowledgements"> fault" sectionFormat="of" derivedContent="RFC4656"/> and
<t>The authors would like to thank Fang Xin, Henrik Nydell, Mach Chen, <xref target="RFC5357" format="default" sectionFormat="of" derivedContent=
Min Xiao, Jeff Tantsura, Marcus Ihlar, Richard Foote for the valuable "RFC5357"/>.</t>
comments to this work.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references pn="section-8">
<?rfc include="reference.RFC.2119"?> <name slugifiedName="name-references">References</name>
<references pn="section-8.1">
<?rfc include='reference.RFC.8174'?> <name slugifiedName="name-normative-references">Normative References</na
me>
<?rfc include='reference.RFC.8668'?> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" quoteTitle="true" derivedAnchor="RFC2119">
<?rfc include='reference.RFC.4656'?> <front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
<?rfc include='reference.RFC.5357'?> le>
</references> <author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<references title="Informative References"> <abstract>
<reference anchor="IEEE802.1AX"> <t indent="0">In many standards track documents several words are
<front> used to signify the requirements in the specification. These words are often cap
<title>IEEE Standard for Local and metropolitan area networks - Link italized. This document defines these words as they should be interpreted in IET
Aggregation</title> F documents. This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for improvements.</t
<author> >
<organization>IEEE Std. 802.1AX</organization> </abstract>
</author> </front>
<seriesInfo name="BCP" value="14"/>
<date month="November" year="2008"/> <seriesInfo name="RFC" value="2119"/>
</front> <seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference> </reference>
<reference anchor="RFC4656" target="https://www.rfc-editor.org/info/rfc4
<?rfc include='reference.RFC.7799'?> 656" quoteTitle="true" derivedAnchor="RFC4656">
<front>
<?rfc include='reference.RFC.9256'?> <title>A One-way Active Measurement Protocol (OWAMP)</title>
<author fullname="S. Shalunov" initials="S." surname="Shalunov"/>
<author fullname="B. Teitelbaum" initials="B." surname="Teitelbaum"/
>
<author fullname="A. Karp" initials="A." surname="Karp"/>
<author fullname="J. Boote" initials="J." surname="Boote"/>
<author fullname="M. Zekauskas" initials="M." surname="Zekauskas"/>
<date month="September" year="2006"/>
<abstract>
<t indent="0">The One-Way Active Measurement Protocol (OWAMP) meas
ures unidirectional characteristics such as one-way delay and one-way loss. High
-precision measurement of these one-way IP performance metrics became possible w
ith wider availability of good time sources (such as GPS and CDMA). OWAMP enable
s the interoperability of these measurements. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4656"/>
<seriesInfo name="DOI" value="10.17487/RFC4656"/>
</reference>
<reference anchor="RFC5357" target="https://www.rfc-editor.org/info/rfc5
357" quoteTitle="true" derivedAnchor="RFC5357">
<front>
<title>A Two-Way Active Measurement Protocol (TWAMP)</title>
<author fullname="K. Hedayat" initials="K." surname="Hedayat"/>
<author fullname="R. Krzanowski" initials="R." surname="Krzanowski"/
>
<author fullname="A. Morton" initials="A." surname="Morton"/>
<author fullname="K. Yum" initials="K." surname="Yum"/>
<author fullname="J. Babiarz" initials="J." surname="Babiarz"/>
<date month="October" year="2008"/>
<abstract>
<t indent="0">The One-way Active Measurement Protocol (OWAMP), spe
cified in RFC 4656, provides a common protocol for measuring one-way metrics bet
ween network devices. OWAMP can be used bi-directionally to measure one-way metr
ics in both directions between two network elements. However, it does not accomm
odate round-trip or two-way measurements. This memo specifies a Two-Way Active M
easurement Protocol (TWAMP), based on the OWAMP, that adds two-way or round-trip
measurement capabilities. The TWAMP measurement architecture is usually compris
ed of two hosts with specific roles, and this allows for some protocol simplific
ations, making it an attractive alternative in some circumstances. [STANDARDS-TR
ACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5357"/>
<seriesInfo name="DOI" value="10.17487/RFC5357"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t indent="0">RFC 2119 specifies common key words that may be used
in protocol specifications. This document aims to reduce the ambiguity by clari
fying that only UPPERCASE usage of the key words have the defined special meanin
gs.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8668" target="https://www.rfc-editor.org/info/rfc8
668" quoteTitle="true" derivedAnchor="RFC8668">
<front>
<title>Advertising Layer 2 Bundle Member Link Attributes in IS-IS</t
itle>
<author fullname="L. Ginsberg" initials="L." role="editor" surname="
Ginsberg"/>
<author fullname="A. Bashandy" initials="A." surname="Bashandy"/>
<author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
<author fullname="M. Nanduri" initials="M." surname="Nanduri"/>
<author fullname="E. Aries" initials="E." surname="Aries"/>
<date month="December" year="2019"/>
<abstract>
<t indent="0">There are deployments where the Layer 3 interface on
which IS-IS operates is a Layer 2 interface bundle. Existing IS-IS advertisemen
ts only support advertising link attributes of the Layer 3 interface. If entitie
s external to IS-IS wish to control traffic flows on the individual physical lin
ks that comprise the Layer 2 interface bundle, link attribute information about
the bundle members is required.</t>
<t indent="0">This document introduces the ability for IS-IS to ad
vertise the link attributes of Layer 2 (L2) Bundle Members.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8668"/>
<seriesInfo name="DOI" value="10.17487/RFC8668"/>
</reference>
</references>
<references pn="section-8.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="IEEE802.1AX" target="https://ieeexplore.ieee.org/docu
ment/9105034" quoteTitle="true" derivedAnchor="IEEE802.1AX">
<front>
<title>IEEE Standard for Local and Metropolitan Area Networks -- Lin
k Aggregation</title>
<author>
<organization showOnFrontPage="true">IEEE</organization>
</author>
<date month="May" year="2020"/>
</front>
<seriesInfo name="IEEE Std" value="802.1AX-2020"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9105034"/>
</reference>
<reference anchor="RFC7799" target="https://www.rfc-editor.org/info/rfc7
799" quoteTitle="true" derivedAnchor="RFC7799">
<front>
<title>Active and Passive Metrics and Methods (with Hybrid Types In-
Between)</title>
<author fullname="A. Morton" initials="A." surname="Morton"/>
<date month="May" year="2016"/>
<abstract>
<t indent="0">This memo provides clear definitions for Active and
Passive performance assessment. The construction of Metrics and Methods can be d
escribed as either "Active" or "Passive". Some methods may use a subset of both
Active and Passive attributes, and we refer to these as "Hybrid Methods". This m
emo also describes multiple dimensions to help evaluate new methods as they emer
ge.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7799"/>
<seriesInfo name="DOI" value="10.17487/RFC7799"/>
</reference>
</references>
</references> </references>
<section anchor="Acknowledgements" numbered="false" toc="include" removeInRF
C="false" pn="section-appendix.a">
<name slugifiedName="name-acknowledgements">Acknowledgements</name>
<t indent="0" pn="section-appendix.a-1">The authors would like to thank <c
ontact fullname="Fang Xin"/>, <contact fullname="Henrik Nydell"/>, <contact full
name="Mach Chen"/>,
<contact fullname="Min Xiao"/>, <contact fullname="Jeff Tantsura"/>, <cont
act fullname="Marcus Ihlar"/>, and <contact fullname="Richard Foote"/> for the v
aluable
comments to this work.</t>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.b">
<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<author fullname="Zhenqiang Li" initials="Z." surname="Li">
<organization showOnFrontPage="true">China Mobile</organization>
<address>
<postal>
<street>No. 29 Finance Avenue</street>
<cityarea>Xicheng District</cityarea>
<city>Beijing</city>
<code/>
<country>China</country>
</postal>
<email>li_zhenqiang@hotmail.com</email>
</address>
</author>
<author fullname="Tianran Zhou" initials="T." surname="Zhou">
<organization showOnFrontPage="true">Huawei</organization>
<address>
<postal>
<country>China</country>
</postal>
<email>zhoutianran@huawei.com</email>
</address>
</author>
<author fullname="Jun Guo" initials="J." surname="Guo">
<organization showOnFrontPage="true">ZTE Corp.</organization>
<address>
<postal>
<country>China</country>
</postal>
<phone/>
<email>guo.jun2@zte.com.cn</email>
<uri/>
</address>
</author>
<author fullname="Greg Mirsky" initials="G." surname="Mirsky">
<organization showOnFrontPage="true">Ericsson</organization>
<address>
<postal>
<street/>
<country>United States of America</country>
</postal>
<email>gregimirsky@gmail.com</email>
</address>
</author>
<author fullname="Rakesh Gandhi" initials="R." surname="Gandhi">
<organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
<address>
<postal>
<country>Canada</country>
</postal>
<phone/>
<email>rgandhi@cisco.com</email>
<uri/>
</address>
</author>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 96 change blocks. 
387 lines changed or deleted 849 lines changed or added

This html diff was produced by rfcdiff 1.48.