diff options
Diffstat (limited to 'doc/rfc/rfc9533.txt')
| -rw-r--r-- | doc/rfc/rfc9533.txt | 610 |
1 files changed, 610 insertions, 0 deletions
diff --git a/doc/rfc/rfc9533.txt b/doc/rfc/rfc9533.txt new file mode 100644 index 0000000..f25347d --- /dev/null +++ b/doc/rfc/rfc9533.txt @@ -0,0 +1,610 @@ + + + + +Internet Engineering Task Force (IETF) Z. Li +Request for Comments: 9533 China Mobile +Category: Standards Track T. Zhou +ISSN: 2070-1721 Huawei + J. Guo + ZTE Corp. + G. Mirsky + Ericsson + R. Gandhi + Cisco Systems, Inc. + January 2024 + + + One-Way and Two-Way Active Measurement Protocol Extensions for + Performance Measurement on a Link Aggregation Group + +Abstract + + This document defines extensions to the One-Way Active Measurement + Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) + to implement performance measurement on every member link of a Link + Aggregation Group (LAG). Knowing the measured metrics of each member + link of a LAG enables operators to enforce the performance-based + traffic steering policy across the member links. + +Status of This Memo + + This is an Internet Standards Track document. + + 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. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9533. + +Copyright Notice + + Copyright (c) 2024 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) 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. + +Table of Contents + + 1. Introduction + 1.1. Requirements Language + 2. Micro Sessions on a LAG + 3. Micro OWAMP Session + 3.1. Micro OWAMP-Control + 3.2. Micro OWAMP-Test + 4. Micro TWAMP Session + 4.1. Micro TWAMP-Control + 4.2. Micro TWAMP-Test + 4.2.1. Sender Packet Format and Content + 4.2.2. Sender Behavior + 4.2.3. Reflector Packet Format and Content + 4.2.4. Reflector Behavior + 5. Applicability + 6. IANA Considerations + 6.1. Micro OWAMP-Control Command + 6.2. Micro TWAMP-Control Command + 7. Security Considerations + 8. References + 8.1. Normative References + 8.2. Informative References + Acknowledgements + Authors' Addresses + +1. Introduction + + A Link Aggregation Group (LAG), as defined in [IEEE802.1AX], provides + mechanisms to combine multiple physical links into a single logical + link. This logical link offers higher bandwidth and better + resiliency because, if one of the physical member links fails, the + aggregate logical link can continue to forward traffic over the + remaining operational physical member links. + + Usually, when forwarding traffic over a LAG, a hash-based mechanism + is used to load balance the traffic across the LAG member links. The + link delay might vary between member links because of different + transport paths, especially when a LAG is used in a wide area + network. To provide low-latency service for time-sensitive traffic, + we need to explicitly steer 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 of every member link of a LAG. + Hence, the measured performance metrics can work together with Layer + 2 bundle member link attributes advertisement [RFC8668] for traffic + steering. + + According to the classifications in [RFC7799], OWAMP [RFC4656] and + TWAMP [RFC5357] are active measurement methods, and they can + complement passive and hybrid methods. With either method, one test + session over the LAG can be used to measure the performance of a + member link using a specially constructed 5-tuple. The session can + be used to measure an average of some or all member links 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 link. + + This document extends OWAMP and TWAMP to implement performance + 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 loss. + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2. Micro Sessions on a LAG + + This document addresses the scenario where a LAG directly connects + two nodes. An example of this is in Figure 1, where the LAG + consisting of four links connects nodes A and B. The goal is to + measure the performance of each link of the LAG. + + +---+ +---+ + | |-----------------------| | + | A |-----------------------| B | + | |-----------------------| | + | |-----------------------| | + +---+ +---+ + + Figure 1: Performance Measurement on a LAG + + To measure the performance metrics of every member link of a LAG, + multiple sessions (one session for each member link) need to be + established between the two endpoints that are connected by the LAG. + These sessions are called "micro sessions" in the remainder of this + document. Although micro sessions are in fact OWAMP or TWAMP + sessions established on member links of a LAG, test packets of micro + TWAMP sessions MUST carry member link information for validation. + + All micro sessions of a LAG share the same Sender IP Address and + Receiver IP Address. As for the UDP port, the micro sessions may + share the same Sender Port and Receiver Port pair or each micro + session may be configured with a different Sender Port and Receiver + Port pair. From the operational point of view, the former is simpler + and is RECOMMENDED. + + Test packets of a micro session MUST 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 test packet is from the expected member link. + +3. Micro OWAMP Session + +3.1. Micro OWAMP-Control + + To support the micro OWAMP session, a new command, Request-OW-Micro- + Sessions (5), is defined in this document. The Request-OW-Micro- + Sessions command is based on the OWAMP Request-Session command and + uses the message format as described in Section 3.5 of [RFC4656]. + Test session creation of micro OWAMP sessions follows the same + procedure as defined in Section 3.5 of [RFC4656] with the following + additions: + + When an OWAMP Server receives a Request-OW-Micro-Sessions command, if + the request is accepted, the OWAMP Server MUST build a set of micro + sessions for all the member links of the LAG from which the Request- + OW-Micro-Sessions message is received. + +3.2. Micro OWAMP-Test + + Micro OWAMP-Test reuses the OWAMP-Test packet format and procedures + as defined in Section 4 of [RFC4656] with the following additions: + + The micro OWAMP Session-Sender MUST send the micro OWAMP-Test packets + over the member link with which the session is associated. When it + receives a test packet, the micro OWAMP Session-Receiver MUST use the + member link from which the test packet is received to correlate the + micro OWAMP session. If there is no such session, the test packet + MUST be discarded. + +4. Micro TWAMP Session + +4.1. Micro TWAMP-Control + + To support the micro TWAMP session, a new command, Request-TW-Micro- + Sessions (11), is defined in this document. The Request-TW-Micro- + Sessions command is based on the TWAMP Request-Session command and + uses the message format as described in Section 3.5 of [RFC5357]. + Test session creation of micro TWAMP sessions follows the same + procedure as defined in Section 3.5 of [RFC5357] with the following + additions: + + When a TWAMP Server receives a Request-TW-Micro-Sessions command, if + the request is accepted, the TWAMP Server MUST build a set of micro + sessions for all the member links of the LAG from which the Request- + TW-Micro-Sessions message is received. + +4.2. Micro TWAMP-Test + + The micro TWAMP-Test protocol is based on the TWAMP-Test protocol + [RFC5357] with the extensions described in the following subsections. + +4.2.1. Sender Packet Format and Content + + The micro TWAMP Session-Sender packet format is based on the TWAMP + Session-Sender packet format as defined in Section 4.1.2 of + [RFC5357]. Two new fields (Sender Micro-session ID and Reflector + Micro-session ID) are added to carry the LAG member link identifiers. + + For unauthenticated mode, the format is as below: + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Timestamp | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Error Estimate | MBZ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sender Micro-session ID | Reflector Micro-session ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . Packet Padding . + . . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: Micro Session-Sender Packet Format in Unauthenticated Mode + + For authenticated and encrypted mode, the format is as below: + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | MBZ (12 octets) | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Timestamp | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Error Estimate | MBZ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sender Micro-session ID | Reflector Micro-session ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | HMAC (16 octets) | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . Packet Padding . + . . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: Micro Session-Sender Packet Format in Authenticated Mode + + Except for the Sender Micro-session ID field and the Reflector Micro- + session ID field, all the other fields are the same as defined in + Section 4.1.2 of [RFC5357] and follow the procedure and guidelines + defined therein. + + Sender Micro-session ID (2 octets in length): This field is defined + to carry the LAG member link identifier of the Sender side. In + the future, it may be used generically to cover use cases beyond + LAGs. The value of this field MUST be unique within a TWAMP + session at the Session-Sender. + + Reflector Micro-session ID (2 octets in length): This field is + defined to carry the LAG member link identifier of the Reflector + side. In the future, it may be used generically to cover use + cases beyond LAGs. The value of this field MUST be unique within + a TWAMP session at the Session-Reflector. + +4.2.2. Sender Behavior + + The micro TWAMP Session-Sender inherits the behaviors of the TWAMP + Session-Sender as defined in Section 4.1 of [RFC5357]. In addition, + the micro TWAMP Session-Sender MUST send the micro Session-Sender + test packets over the member link with which the session is + associated. + + When sending the test packet, the micro TWAMP Session-Sender MUST put + the Sender member link identifier that is associated with the micro + TWAMP session in the Sender Micro-session ID. If the Session-Sender + knows the Reflector member link identifier, the Reflector Micro- + session ID field (see Figures 2 and 3) MUST be set. Otherwise, the + Reflector Micro-session ID field MUST be zero. + + 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 to check whether a reflected test packet is received + from the member link associated with the correct micro TWAMP session. + + The Reflector member link identifier carried in the Reflector Micro- + session ID field is used by the Session-Reflector to check whether a + test packet is received from the member link associated with the + correct micro TWAMP session. It means that the Session-Sender has to + learn 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 (see Figures 2 or + 3) of the test packets that will be sent to the Session-Reflector. + The Reflector member link identifier can be obtained from + preconfiguration or learned from the data plane (e.g., the reflected + test packet). This document does not specify the way to obtain the + Reflector member link identifier. + + When receiving a reflected test packet, the micro TWAMP Session- + Sender MUST use the receiving member link to correlate the reflected + test packet to a micro TWAMP session. If there is no such session, + the reflected test packet MUST be discarded. If a matched session + exists, the micro Session-Sender MUST use the Sender Micro-session ID + to validate whether the reflected test packet is correctly received + from the expected member link. If the validation fails, the test + packet MUST be discarded. The micro Session-Sender MUST use the + Reflector Micro-session ID to validate the Reflector's behavior. If + the validation fails, the test packet MUST be discarded. + +4.2.3. Reflector Packet Format and Content + + The micro TWAMP Session-Reflector packet format is based on the TWAMP + Session-Reflector packet format as defined in Section 4.2.1 of + [RFC5357]. Two new fields (Sender and Reflector Micro-session ID) + are added to carry the LAG member link identifiers. + + For unauthenticated mode, the format is as below: + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Timestamp | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Error Estimate | MBZ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Receive Timestamp | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sender Sequence Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sender Timestamp | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sender Error Estimate | Sender Micro-session ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sender TTL | MBZ | Reflector Micro-session ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . . + . Packet Padding . + . . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: Micro Session-Reflector Packet Format in + Unauthenticated Mode + + For authenticated and encrypted mode, the format is as below: + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MBZ (12 octets) | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Timestamp | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Error Estimate | MBZ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sender Micro-session ID | Reflector Micro-session ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Receive Timestamp | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MBZ (8 octets) | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sender Sequence Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MBZ (12 octets) | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sender Timestamp | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sender Error Estimate | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | MBZ (6 octets) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sender TTL | | + +-+-+-+-+-+-+-+-+ + + | | + | | + | MBZ (15 octets) | + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + | HMAC (16 octets) | + | | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . Packet Padding . + . . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: Micro Session-Reflector Packet Format in Authenticated Mode + + Except for the Sender Micro-session ID field and the Reflector Micro- + session ID field, all the other fields are the same as defined in + Section 4.2.1 of [RFC5357] and follow the same procedure and + guidelines defined therein. + + Sender Micro-session ID (2 octets in length): This field is defined + to carry the LAG member link identifier of the Sender side. In + the future, it may be used generically to cover use cases beyond + LAGs. The value of this field MUST be unique within a TWAMP + session at the Session-Sender. + + Reflector Micro-session ID (2 octets in length): This field is + defined to carry the LAG member link identifier of the Reflector + side. In the future, it may be used generically to cover use + cases beyond LAGs. The value of this field MUST be unique within + a TWAMP session at the Session-Reflector. + +4.2.4. Reflector Behavior + + The micro TWAMP Session-Reflector inherits the behaviors of a TWAMP + Session-Reflector as defined in Section 4.2 of [RFC5357]. + + In addition, when receiving a test packet, the micro TWAMP Session- + Reflector MUST use the receiving member link to correlate the test + packet to a micro TWAMP session. If there is no such a session, the + test packet MUST be discarded. If the Reflector Micro-session ID is + not zero, the Reflector MUST use the Reflector Micro-session ID to + validate whether it associates with the receiving member link. If + the Reflector Micro-session ID is zero, it will not be verified. If + the validation fails, the test packet MUST be discarded. + + When sending a response to the received test packet, the micro TWAMP + Session-Reflector MUST copy the Sender member link identifier from + the received test packet and put it in the Sender Micro-session ID + field of the reflected test packet (see Figures 4 and 5). In + addition, the micro TWAMP Session-Reflector MUST fill the Reflector + Micro-session ID field (see Figures 4 and 5) of the reflected test + packet with the member link identifier that is associated with the + micro TWAMP session. + +5. Applicability + + To set up the micro OWAMP sessions, the Control-Client sends 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 + the member links of the LAG. + + For micro TWAMP sessions, a similar set up procedure is used. Then, + the micro TWAMP Session-Sender sends micro Session-Sender packets + with the Sender Micro-session ID and the 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 micro TWAMP session. When + reflecting, the micro TWAMP Session-Reflector copies the Sender + Micro-session ID from the received micro Session-Sender packet to the + micro Session-Reflector packet; then, it sets the Reflector Micro- + session ID field with the member link identifier that is associated + with the micro TWAMP session. When receiving the micro TWAMP + Session-Reflector packet, the micro Session-Sender uses the Sender + Micro-session ID to check whether the packet is received from the + member link associated with the correct micro TWAMP session. The + micro Session-Sender also uses the Reflector Micro-session ID to + validate the Reflector's behavior. + +6. IANA Considerations + +6.1. Micro OWAMP-Control Command + + IANA has allocated the following command type from the "OWAMP-Control + Command Numbers" registry. + + +=======+===========================+===============+ + | Value | Description | Reference | + +=======+===========================+===============+ + | 5 | Request-OW-Micro-Sessions | This document | + +-------+---------------------------+---------------+ + + Table 1: Request-OW-Micro-Sessions Command Number + +6.2. Micro TWAMP-Control Command + + IANA has allocated the following command type from the "TWAMP-Control + Command Numbers" registry. + + +=======+===========================+===============+ + | Value | Description | Reference | + +=======+===========================+===============+ + | 11 | Request-TW-Micro-Sessions | This document | + +-------+---------------------------+---------------+ + + Table 2: Request-TW-Micro-Sessions Command Number + +7. Security Considerations + + This document does not introduce additional security requirements and + mechanisms other than those described in [RFC4656] and [RFC5357]. + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. + Zekauskas, "A One-way Active Measurement Protocol + (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, + <https://www.rfc-editor.org/info/rfc4656>. + + [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. + Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", + RFC 5357, DOI 10.17487/RFC5357, October 2008, + <https://www.rfc-editor.org/info/rfc5357>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, + M., and E. Aries, "Advertising Layer 2 Bundle Member Link + Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, + December 2019, <https://www.rfc-editor.org/info/rfc8668>. + +8.2. Informative References + + [IEEE802.1AX] + IEEE, "IEEE Standard for Local and Metropolitan Area + Networks -- Link Aggregation", IEEE Std 802.1AX-2020, + DOI 10.1109/IEEESTD.2020.9105034, May 2020, + <https://ieeexplore.ieee.org/document/9105034>. + + [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with + Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, + May 2016, <https://www.rfc-editor.org/info/rfc7799>. + +Acknowledgements + + The authors would like to thank Fang Xin, Henrik Nydell, Mach Chen, + Min Xiao, Jeff Tantsura, Marcus Ihlar, and Richard Foote for the + valuable comments to this work. + +Authors' Addresses + + Zhenqiang Li + China Mobile + No. 29 Finance Avenue + Xicheng District + Beijing + China + Email: li_zhenqiang@hotmail.com + + + Tianran Zhou + Huawei + China + Email: zhoutianran@huawei.com + + + Jun Guo + ZTE Corp. + China + Email: guo.jun2@zte.com.cn + + + Greg Mirsky + Ericsson + United States of America + Email: gregimirsky@gmail.com + + + Rakesh Gandhi + Cisco Systems, Inc. + Canada + Email: rgandhi@cisco.com |