Simple Two-way Active Measurement Protocol (STAMP) for MPLS Label Switched Paths (LSPs)
draft-mirsky-mpls-stamp-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | Greg Mirsky | ||
| Last updated | 2022-07-28 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-mirsky-mpls-stamp-00
MPLS Working Group G. Mirsky
Internet-Draft Ericsson
Intended status: Standards Track 28 July 2022
Expires: 29 January 2023
Simple Two-way Active Measurement Protocol (STAMP) for MPLS Label
Switched Paths (LSPs)
draft-mirsky-mpls-stamp-00
Abstract
Simple Two-way Active Measurement Protocol (STAMP), defined in RFC
8762 and RFC 8972, is expected to be able to monitor the performance
of paths between systems that use a wide variety of encapsulations.
This document defines encapsulation and bootstrapping of a STAMP test
session over an MPLS Label Switched Path.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 29 January 2023.
Copyright Notice
Copyright (c) 2022 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.
Mirsky Expires 29 January 2023 [Page 1]
Internet-Draft STAMP for MPLS LSPs July 2022
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in this Document . . . . . . . . . . . . 2
1.1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3
2. Encapsulation of a STAMP Test Packet . . . . . . . . . . . . 3
3. Bootstrap STAMP Using LSP Ping . . . . . . . . . . . . . . . 3
3.1. STAMP Session Identifier TLV . . . . . . . . . . . . . . 4
4. STAMP Session Establishment . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
5.1. STAMP Session Identifier TLV . . . . . . . . . . . . . . 5
5.2. Return Code . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. References> . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informational References . . . . . . . . . . . . . . . . 7
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
[RFC8762] and [RFC8972] defined the base specification and extensions
of the Simple Two-Way Active Measurement Protocol (STAMP). STAMP can
be used to measure packet loss, packet delay, detect packet re-
ordering, and unwanted multiple copies of a STAMP packet. This
document defines the encapsulation of the STAMP test message over an
Multiprotocol Label Switching (MPLS ) Label Switched Path (LSP).
Also, the use of LSP Ping [RFC8029] to bootstrap and control the path
for the reflected STAMP test packet is discussed in the document.
This document defines the Reflected Packet Path TLV as an extension
to LSP Ping [RFC8029]. It is to be used to instruct the STAMP
Session-Reflector how to demultiplex incoming STAMP test sessions and
a path to use for the reflected STAMP test packets. The TLV will be
allocated from the TLV and sub-TLV registry defined in [RFC8029]. As
a special case, forward and reverse directions of the STAMP test
session can form a bi-directional co-routed associated channel.
1.1. Conventions Used in this Document
1.1.1. Acronyms
STAMP: Simple Tw-way Active Measurement Protocol
MPLS: Multiprotocol Label Switching
LSP: Label Switching Path
Mirsky Expires 29 January 2023 [Page 2]
Internet-Draft STAMP for MPLS LSPs July 2022
SSID: STAMP Session Identifier
1.1.2. 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. Encapsulation of a STAMP Test Packet
STAMP can be used to measure one-way packet loss and packet delay,
and detect packet re-ordering, and unwarranted replication of a STAMP
test packet. [RFC8762] defined formats of a STAMP test packet and
reflected STAMP test packet in unauthenticated and authenticated
modes, respectively. These STAMP test packets can be encapsulated in
IP/UDP to be transmitted over an MPLS LSP as follows:
* The STAMP test packet sent by the ingress LSR SHOULD be a UDP
packet with a well-known destination port 672 [RFC8762] and a
source port assigned by the sender. The destination UDP port MAY
be selected from the Dynamic UDP ports range. The mechanism used
to select the port number from the Dynamic range is outside the
scope of this document.
* The destination IP address MUST be randomly chosen from the 127/8
range for IPv4. For IPv6, the ::1/128 address MUST be used.
* For the STAMP test packet, the sender MUST set the IP TTL or hop
limit to 255 [RFC5082].
* The source IP address is a routable address of the sender.
* The reflected STAMP test packets are UDP packets.
* The source IP address of a reflected STAMP test packet is a
routable address of the STAMP Session-Reflector.
3. Bootstrap STAMP Using LSP Ping
A STAMP test session over an MPLS LSP can be bootstrapped using LSP
ping, defined in [RFC8029]. To bootstrap a STAMP test session, STAMP
Session Identifier TLV MUST be used. This document defines a new
SSID TLV. The STAMP Session Identifier TLV MUST contain the STAMP
Session Identifier (SSID) ([RFC8972]) value and MAY contain none, one
or more sub-TLVs that can be used to carry information about the path
for reflected STAMP test packet.
Mirsky Expires 29 January 2023 [Page 3]
Internet-Draft STAMP for MPLS LSPs July 2022
3.1. STAMP Session Identifier TLV
The STAMP Session Identifier TLV is an optional TLV within the LSP
ping [RFC8029]. The STAMP Session Identifier TLV carries SSID value
and, optionally, information about the path onto which the STAMP
Session-Reflector MUST transmit reflected STAMP test packets for the
given STAMP test session. The format of the STAMP Session Identifier
TLV is as presented in Figure 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| STAMP Session Id TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Reflected Packet Path ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: STAMP Session Identifier TLV
STAMP Session Identifier Type is a two-octet field and has a value of
TBD1 (to be assigned by IANA as requested in Section 5).
Length field is a two-octet field equal to the length in octets of
the SSID and Reflected Packet Path fields. The minimum value MUST be
four.
SSID field is a four-octet field that identifies the STAMP test
session at the STAMP Session-Sender.
Reflected Packet Path field contains none, one or more sub-TLVs. Any
Target FEC Stack sub-TLV (already defined, or to be defined in the
future) for TLV Types 1, 16, and 21 of MPLS LSP Ping Parameters
registry MAY be used in this field. The Non-FEC Path TLV, defined in
[I-D.ietf-spring-bfd], MAY be used to specify the path for a STAMP
reflected test packet in the SR-MPLS environment. None, one or more
sub-TLVs MAY be included in the Reflected Packet Path TLV. If no
sub-TLVs are found in the STAMP Session Identifier TLV, the STAMP
Session-Reflector MUST revert to transmitting the STAMP reflected
packets over the IP network.
Mirsky Expires 29 January 2023 [Page 4]
Internet-Draft STAMP for MPLS LSPs July 2022
If the STAMP Session-Reflector cannot find the path specified in the
Reflected Packet Path TLV, it MUST send Echo Reply with the received
STAMP Session Identifier TLV and set the Return Code to "The
specified Reflected Packet Path was not found" Section 5.2.
The STAMP Session Identifier TLV MAY be used in the bootstrapping of
a STAMP test session. A system that supports this specification MUST
support using the STAMP Session Identifier TLV after the STAMP test
session has been established. If a system that supports this
specification receives an LSP Ping with the STAMP Session Identifier
TLV that has no sub-TLVs in the Reflected Packet Path field, even
though the reflected test packets for the specified STAMP test
session has been transmitted according to the previously received
STAMP Session Identifier TLV, the egress LSR MUST transition to
transmitting reflected STAMP packets over an IP network.
4. STAMP Session Establishment
A STAMP test session can be bootstrapped using LSP Ping. To monitor
performance for a particular MPLS LSP and FEC combination LSP Ping
Echo request and Echo reply packets, in the ping mode, exchanged
between the STAMP Session-Sender and Session-Reflector for that MPLS
LSP and FEC combination. If LSP Ping is used to establishing a STAMP
test session, an LSP Ping Echo request message MUST carry the SSID
value assigned by the Session-Sender for the STAMP test session.
This MUST subsequently be used as the SSID field in the STAMP test
session packets sent by the STAMP Session-Sender.
On receipt of the LSP Ping Echo request message, the STAMP Session-
Reflector MUST send an LSP Ping Echo response, if the validation of
the FEC in the LSP Ping Echo request message succeeds. The Session-
Reflector SHOULD use the value in the SSID field and source IP
address in the received LSP Ping Echo request message to demultiplex
STAMP test sessions.
If the MPLS network includes an equal-cost multipath environment, a
STAMP Session-Sender MUST use the same value of an Entropy Label
([RFC6790] and [RFC8662]) in the LSP Ping Echo request that
bootstraps the STAMP test session and consecutive STAMP test packets.
5. IANA Considerations
5.1. STAMP Session Identifier TLV
The IANA is requested to assign a new value for the STAMP Session
Identifier TLV from the "Multiprotocol Label Switching Architecture
(MPLS) Label Switched Paths (LSPs) Ping Parameters - TLVs" registry,
"TLVs and sub-TLVs" sub-registry.
Mirsky Expires 29 January 2023 [Page 5]
Internet-Draft STAMP for MPLS LSPs July 2022
+=========+==============================+===============+
| Value | Description | Reference |
+=========+==============================+===============+
| (TBD1) | STAMP Session Identifier TLV | This document |
+---------+------------------------------+---------------+
Table 1: New BFD Reverse Type TLV
5.2. Return Code
The IANA is requested to assign a new Return Code value from the
"Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs)
Ping Parameters" registry, "Return Codes" sub-registry, as follows
using a Standards Action value.
+=========+============================+===============+
| Value | Description | Reference |
+=========+============================+===============+
| (TBD2) | The specified Reflected | This document |
| | Packet Path was not found. | |
+---------+----------------------------+---------------+
Table 2: New Return Code
6. Security Considerations
Security considerations discussed in [RFC8029], [RFC8762], and
[RFC8972] apply to this document.
7. References>
7.1. Normative References
[I-D.ietf-spring-bfd]
Mirsky, G., Tantsura, J., Varlashkin, I., Chen, M., and J.
Wenying, "Bidirectional Forwarding Detection (BFD) in
Segment Routing Networks Using MPLS Dataplane", Work in
Progress, Internet-Draft, draft-ietf-spring-bfd-04, 26
April 2022, <https://datatracker.ietf.org/doc/html/draft-
ietf-spring-bfd-04>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", DOI 10.17487/RFC2119, BCP 14,
RFC 2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Mirsky Expires 29 January 2023 [Page 6]
Internet-Draft STAMP for MPLS LSPs July 2022
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012,
<https://www.rfc-editor.org/info/rfc6790>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", DOI 10.17487/RFC8174, RFC 8174, BCP 14,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8662] Kini, S., Kompella, K., Sivabalan, S., Litkowski, S.,
Shakir, R., and J. Tantsura, "Entropy Label for Source
Packet Routing in Networking (SPRING) Tunnels", RFC 8662,
DOI 10.17487/RFC8662, December 2019,
<https://www.rfc-editor.org/info/rfc8662>.
[RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple
Two-Way Active Measurement Protocol",
DOI 10.17487/RFC8762, RFC 8762, March 2020,
<https://www.rfc-editor.org/info/rfc8762>.
[RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A.,
and E. Ruffini, "Simple Two-Way Active Measurement
Protocol Optional Extensions", DOI 10.17487/RFC8972,
RFC 8972, January 2021,
<https://www.rfc-editor.org/info/rfc8972>.
7.2. Informational References
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
<https://www.rfc-editor.org/info/rfc5082>.
Appendix A. Acknowledgments
The authors greatly appreciate a thorough review and the most helpful
comments from Eric Gray and Carlos Pignataro. The authors much
appreciate the help of Qian Xin, who provided information about the
implementation of this specification.
Author's Address
Mirsky Expires 29 January 2023 [Page 7]
Internet-Draft STAMP for MPLS LSPs July 2022
Greg Mirsky
Ericsson
Email: gregimirsky@gmail.com
Mirsky Expires 29 January 2023 [Page 8]