draft-gandhi-mpls-stamp-pw-05.txt   draft-gandhi-mpls-stamp-pw-06.txt 
MPLS Working Group R. Gandhi, Ed. MPLS Working Group R. Gandhi, Ed.
Internet-Draft P. Brissette Internet-Draft P. Brissette
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: 8 August 2024 E. Leyton Expires: 24 September 2024 E. Leyton
Verizon Wireless Verizon Wireless
X. Min X. Min
ZTE Corp. ZTE Corp.
5 February 2024 23 March 2024
Encapsulation of Simple TWAMP (STAMP) for Pseudowires and LSPs in MPLS Encapsulation of Simple Two-Way Active Measurement Protocol for
Networks Pseudowires and LSPs in MPLS Networks
draft-gandhi-mpls-stamp-pw-05 draft-gandhi-mpls-stamp-pw-06
Abstract Abstract
Pseudowires (PWs) and Label Switched Paths (LSPs) are used in MPLS Pseudowires (PWs) and Label Switched Paths (LSPs) are used in MPLS
networks for various services including carrying layer 2 and layer 3 networks for various services including carrying layer 2 and layer 3
data packets. This document describes the procedure for data packets. This document describes the procedure for
encapsulation of the Simple Two-Way Active Measurement Protocol encapsulation of the Simple Two-Way Active Measurement Protocol
(STAMP) defined in RFC 8762 and its optional extensions defined in (STAMP) defined in RFC 8762 and its optional extensions defined in
RFC 8972 for PWs and LSPs in MPLS networks. The procedure uses RFC 8972 for PWs and LSPs in MPLS networks. The procedure uses
Generic Associated Channel (G-ACh) to encapsulate the STAMP test Generic Associated Channel (G-ACh) to encapsulate the STAMP test
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 8 August 2024. This Internet-Draft will expire on 24 September 2024.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Examples of MPLS Data Traffic Use Cases . . . . . . . . . 5
2. Conventions Used in This Document . . . . . . . . . . . . . . 5 2. Conventions Used in This Document . . . . . . . . . . . . . . 5
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6
2.3. STAMP Reference Topology . . . . . . . . . . . . . . . . 6 2.3. STAMP Reference Topology . . . . . . . . . . . . . . . . 6
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Using STAMP for MPLS LSPs and MPLS-TP LSPs . . . . . . . 8 3.1. Using STAMP for MPLS PWs and MPLS-TP PWs . . . . . . . . 7
3.2. Example Use Cases of STAMP Header Formats for MPLS Data 3.1.1. G-ACh Types for STAMP . . . . . . . . . . . . . . . . 8
Traffic Type . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Using STAMP for MPLS LSPs and MPLS-TP LSPs . . . . . . . 8
3.3. Applicability of Control Channel Types to STAMP Test 3.3. Applicability of Control Channel Types to STAMP Test
Packets for MPLS . . . . . . . . . . . . . . . . . . . . 8 Packets for MPLS PWs and LSPs . . . . . . . . . . . . . . 9
4. Session-Sender Test Packet . . . . . . . . . . . . . . . . . 9 4. Session-Sender Test Packet . . . . . . . . . . . . . . . . . 9
4.1. Session-Sender Test Packet with IP/UDP Header . . . . . . 9 4.1. Session-Sender Test Packet with IP/UDP Header . . . . . . 9
4.2. Session-Sender Test Packet without IP/UDP Header . . . . 11 4.2. Session-Sender Test Packet without IP/UDP Header . . . . 11
5. Session-Reflector Test Packet . . . . . . . . . . . . . . . . 12 5. Session-Reflector Test Packet . . . . . . . . . . . . . . . . 12
5.1. Session-Reflector Test Packet with IP/UDP Header . . . . 12 5.1. Session-Reflector Test Packet with IP/UDP Header . . . . 12
5.2. Session-Reflector Test Packet without IP/UDP Header . . . 14 5.2. Session-Reflector Test Packet without IP/UDP Header . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
The Simple Two-way Active Measurement Protocol (STAMP) provides The Simple Two-way Active Measurement Protocol (STAMP) provides
capabilities for the measurement of various metrics in IP networks capabilities for the measurement of various metrics in IP networks
[RFC8762] without the use of a control channel to pre-signal session [RFC8762] without the use of a control channel to pre-signal session
parameters. [RFC8972] defines optional extensions for STAMP. parameters. [RFC8972] defines optional extensions for STAMP.
Pseudowires (PWs) are used in MPLS networks for various services Pseudowires (PWs) are used in MPLS networks for various services
including carrying layer 2 and layer 3 data packets [RFC6658]. The including carrying layer 2 and layer 3 data packets [RFC6658]. The
skipping to change at page 3, line 24 skipping to change at page 3, line 20
other control messages over MPLS data plane. The G-ACh types other control messages over MPLS data plane. The G-ACh types
identify the various OAM messages being transported over the channel. identify the various OAM messages being transported over the channel.
Virtual Circuit Connectivity Verification (VCCV) is used as Control Virtual Circuit Connectivity Verification (VCCV) is used as Control
Channel for PWs as described in [RFC5085]. A G-ACh can be used as a Channel for PWs as described in [RFC5085]. A G-ACh can be used as a
VCCV channel as described in [RFC7708]. VCCV channel as described in [RFC7708].
This document describes the procedure for encapsulation of the STAMP This document describes the procedure for encapsulation of the STAMP
defined in [RFC8762] and its optional extensions defined in [RFC8972] defined in [RFC8762] and its optional extensions defined in [RFC8972]
for point-to-point PWs and LSPs in MPLS networks. The procedure uses for point-to-point PWs and LSPs in MPLS networks. The procedure uses
G-ACh to encapsulate the STAMP test packets with or without an IP/UDP G-ACh to encapsulate STAMP test packets with or without an IP/UDP
header. This document defines two new G-ACh types when using STAMP header. This document defines two new G-ACh types when using STAMP
without IP/UDP header, those are PW demultiplexer agnostic and hence without IP/UDP header, those are PW demultiplexer agnostic and hence
applicable to both MPLS PWs and Layer 2 Tunneling Protocol version 3 applicable to both MPLS PWs and Layer 2 Tunneling Protocol version 3
(L2TPv3) PW demultiplexers. This document uses existing G-ACh types (L2TPv3) PW demultiplexers. This document uses existing G-ACh types
for IPv4 and IPv6 when using STAMP with IP/UDP header. for IPv4 and IPv6 when using STAMP with IP/UDP header.
1.1. Requirements 1.1. Requirements
The STAMP test packets need to be transmitted with the same MPLS The STAMP test packets need to be transmitted with the same MPLS
label stack that is used by the PW and LSP data traffic to ensure label stack that is used by the PW and LSP data traffic to ensure
skipping to change at page 5, line 11 skipping to change at page 5, line 17
o The Session-Reflector test packets MAY follow the same reverse ECMP o The Session-Reflector test packets MAY follow the same reverse ECMP
underlay path taken by Session-Sender test packets. underlay path taken by Session-Sender test packets.
This document concerns with the STAMP operation for the Single- This document concerns with the STAMP operation for the Single-
Segment PWs (SS-PWs). Segment PWs (SS-PWs).
The procedure for STAMP operation for point-to-multipoint (P2MP) PWs The procedure for STAMP operation for point-to-multipoint (P2MP) PWs
is outside the scope of this document. is outside the scope of this document.
1.2. Examples of MPLS Data Traffic Use Cases
Examples of MPLS data traffic use cases for STAMP test packets with
IP/UDP headers:
1. MPLS PW Data Traffic (with CW and IP header)
2. MPLS-TP PW Data Traffic (with CW and IP header)
3. MPLS LSP Data Traffic (with IP header)
Examples of MPLS data traffic use cases for STAMP test packets
without IP/UDP headers:
1. MPLS Ethernet PW Data Traffic [RFC4448]
2. L2-Specific Sublayer (L2SS) used in L2TPv3 PW Data Traffic
[RFC3931]
3. Private Line Emulation [I-D.ietf-pals-ple] PW Data Traffic
4. TDM over IP [RFC5087] PW Data Traffic (with no IP header)
5. MPLS-TP LSP Data Traffic
2. Conventions Used in This Document 2. Conventions Used in This Document
2.1. Requirements Language 2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at page 6, line 18 skipping to change at page 7, line 5
packet PW or LSP to transport data between Provider Edge (PE) packet PW or LSP to transport data between Provider Edge (PE)
Endpoints S1 and R1. The STAMP Session-Sender on PE S1 initiates a Endpoints S1 and R1. The STAMP Session-Sender on PE S1 initiates a
Session-Sender test packet and the STAMP Session-Reflector on PE R1 Session-Sender test packet and the STAMP Session-Reflector on PE R1
transmits a reply test packet. The Session-Reflector reply test transmits a reply test packet. The Session-Reflector reply test
packet may be transmitted to the STAMP Session-Sender on the same packet may be transmitted to the STAMP Session-Sender on the same
path (same set of links and nodes) in the reverse direction of the path (same set of links and nodes) in the reverse direction of the
path taken towards the Session-Reflector. The T1 is a transmit path taken towards the Session-Reflector. The T1 is a transmit
timestamp and T4 is a receive timestamp added by S1. The T2 is a timestamp and T4 is a receive timestamp added by S1. The T2 is a
receive timestamp and T3 is a transmit timestamp added by R1. receive timestamp and T3 is a transmit timestamp added by R1.
|<-------- Pseudowire ------->| |<------ MPLS Pseudowire ---->|
|<-------- LSP -------------->| |<------ MPLS LSP ----------->|
| | | |
| T1 T2 | | T1 T2 |
| / \ | | / \ |
+-------+ Test Packet +-------+ +-------+ Test Packet +-------+
| | - - - - - - - - - ->| | | | - - - - - - - - - ->| |
| S1 |=====================| R1 | | S1 |=====================| R1 |
| |<- - - - - - - - - - | | | |<- - - - - - - - - - | |
+-------+ Reply Test Packet +-------+ +-------+ Reply Test Packet +-------+
\ / \ /
T4 T3 T4 T3
STAMP Session-Sender STAMP Session-Reflector STAMP Session-Sender STAMP Session-Reflector
Provider Edge Endpoint Provider Edge Endpoint Provider Edge Endpoint Provider Edge Endpoint
Figure 1: STAMP Reference Topology using PW and LSP Figure 1: STAMP Reference Topology using MPLS PW and LSP
3. Overview 3. Overview
The STAMP Session-Sender and Session-Reflector test packets defined The STAMP Session-Sender and Session-Reflector test packets defined
in [RFC8972] are encapsulated and transmitted over the PWs in MPLS in [RFC8972] are encapsulated and transmitted over the PWs in MPLS
networks. The base STAMP test packets can be encapsulated using an networks. The base STAMP test packets can be encapsulated using an
IP/UDP header and may use destination UDP port 862 [RFC8762]. The IP/UDP header and may use destination UDP port 862 [RFC8762]. The
source UDP port is dynamically selected by the Session-Sender. source UDP port is chosen by the Session-Sender.
3.1. Using STAMP for MPLS PWs and MPLS-TP PWs
The STAMP test packets are encapsulated with MPLS header using the The STAMP test packets are encapsulated with MPLS header using the
same label stack as the PW data traffic (including PW Label) and same label stack as the PW data traffic (including PW Label) and
G-ACh header (instead of Control Word header used by the data G-ACh header (instead of Control Word header used by the data
traffic). The encapsulation allows the STAMP test packets to follow traffic). The encapsulation allows the STAMP test packets to follow
the same path as the PW data traffic, and provide the same ECMP the same path as the PW data traffic, and provide the same ECMP
behaviour on the intermediate nodes. behaviour on the intermediate nodes.
There are two ways in which STAMP test packets may be encapsulated
over a G-ACh, either using an IP/UDP header or without using an IP/
UDP header.
For encapsulating the STAMP test packets over a G-ACh with an IP/UDP
header, IPv4 and IPv6 channel types [RFC4385] are used for both
Session-Sender and Session-Reflector test packets. The destination
UDP port number in the Session-Sender and Session-Reflector test
packets discriminate the test packets. The IP version (IPv4 or IPv6)
MUST match the IP version used for signaling for dynamically
established PWs or IP version MUST be configured for statically
provisioned PWs.
For encapsulating the STAMP test packets over a G-ACh without adding
an IP/UDP header, two new channel types are defined in this document,
one for the Session-Sender test packets and one for the Session-
Reflector test packets. The different channel types are required for
the Session-Sender and Session-Reflector test packets as the STAMP
test packets do not have a way to discriminate them.
The IPv4 Time to Live (TTL), IPv6 Hop Limit and Generalized TTL The IPv4 Time to Live (TTL), IPv6 Hop Limit and Generalized TTL
Security Mechanism (GTSM) procedures from [RFC5082] also apply to the Security Mechanism (GTSM) procedures from [RFC5082] also apply to the
encapsulation of STAMP test packets, and hence the IPv4 TTL and IPv6 encapsulation of STAMP test packets, and hence the IPv4 and MPLS TTL
Hop Limit MUST be set to 255. and IPv6 Hop Limit MUST be set to 255.
The OAM Control Channel traffic between two Provider Edge (PE) The OAM Control Channel traffic between two Provider Edge (PE)
endpoints is not forwarded past the PE endpoints towards the Customer endpoints is not forwarded past the PE endpoints towards the Customer
Edge (CE) devices; instead, the OAM messages are intercepted at the Edge (CE) devices; instead, the OAM messages are intercepted at the
PE endpoints for exception processing in control-plane. [RFC5085] PE endpoints for exception processing in control-plane. [RFC5085]
defines mechanisms for VCCV Control Channel to carry OAM messages for defines mechanisms for VCCV Control Channel to carry OAM messages for
MPLS PWs. Specifically, the method for "TTL Expiry VCCV (Type 3)" MPLS PWs. Specifically, the method for "TTL Expiry VCCV (Type 3)"
defined in Section 5.1.3 of [RFC5085] allows to terminate the OAM defined in Section 5.1.3 of [RFC5085] allows to terminate the OAM
messages on the remote PE endpoint nodes. This method is also messages on the remote PE endpoint nodes. This method is also
applicable to the STAMP test packets to force test packets to be applicable to the STAMP test packets to force test packets to be
skipping to change at page 8, line 5 skipping to change at page 8, line 17
Session-Sender and Session-Reflector test packets. Session-Sender and Session-Reflector test packets.
The VCCC Type 2 is also referred to as 'MPLS Router Alert Label" The VCCC Type 2 is also referred to as 'MPLS Router Alert Label"
[RFC5085]. This approach could result in a different Equal Cost [RFC5085]. This approach could result in a different Equal Cost
Multi-Path (ECMP) hashing behavior than pseudowire PDUs, and thus Multi-Path (ECMP) hashing behavior than pseudowire PDUs, and thus
result in the VCCV control channel traffic taking a path which result in the VCCV control channel traffic taking a path which
differs from that of the actual data traffic under test [RFC5085]. differs from that of the actual data traffic under test [RFC5085].
Hence, the VCCV Type 2 is not supported for STAMP for monitoring MPLS Hence, the VCCV Type 2 is not supported for STAMP for monitoring MPLS
PW and MPLS LSP traffic. PW and MPLS LSP traffic.
3.1. Using STAMP for MPLS LSPs and MPLS-TP LSPs 3.1.1. G-ACh Types for STAMP
There are two ways in which STAMP test packets may be encapsulated
over a G-ACh, either using an IP/UDP header or without using an IP/
UDP header.
For encapsulating the STAMP test packets over a G-ACh with IP/UDP
headers (Format1), IPv4 and IPv6 channel types [RFC4385] are used for
both Session-Sender and Session-Reflector test packets. The
destination UDP port number in the Session-Sender and Session-
Reflector test packets discriminate the test packets. The IP version
(IPv4 or IPv6) MUST match the IP version used for signaling for
dynamically established PWs or IP version MUST be configured for
statically provisioned PWs.
For encapsulating the STAMP test packets over a G-ACh without adding
IP/UDP headers (Format2), two new channel types are defined in this
document, one for the Session-Sender test packets and one for the
Session-Reflector test packets. The different channel types are
required for the Session-Sender and Session-Reflector test packets as
the STAMP test packets do not have a way to discriminate them.
3.2. Using STAMP for MPLS LSPs and MPLS-TP LSPs
The procedure defined in this document to encapsulate STAMP test The procedure defined in this document to encapsulate STAMP test
packets is also aplicable to MPLS LSPs and MPLS-TP LSPs. For packets is also aplicable to MPLS LSPs and MPLS-TP LSPs. For
monitoring data traffic over MPLS LSPs (no Control Word case) using monitoring data traffic over MPLS LSPs (no Control Word case) using
IP header, STAMP test packet format 1 (with IP/UDP headers) is used. IP header, STAMP test packet Format1 (with IP/UDP headers) is used.
For monoitoring data traffic over MPLS-TP LSPs (with Control Word), For monoitoring data traffic over MPLS-TP LSPs (with Control Word),
not using IP header, STAMP test packets with format 2 (without IP/UDP not using IP header, STAMP test packets with Format2 (without IP/UDP
headers) are transmitted with TTL value 1 with the ultimate label in headers) are transmitted with TTL value 1 with the ultimate label in
the MPLS header. the MPLS header.
The G-ACh label (GAL) [RFC5586] along with Generic Associated Channel The G-ACh label (GAL) [RFC5586] along with Generic Associated Channel
(G-ACh) types defined in this document can be used with STAMP test (G-ACh) types defined in this document can be used with STAMP test
packets format 2 (without IP/UDP header), for example, in case of packets Format2 (without IP/UDP header), for example, in case of
MPLS-TP LSPs (STAMP headers similar to [RFC6374]). MPLS-TP LSPs (STAMP headers similar to [RFC6374]).
3.2. Example Use Cases of STAMP Header Formats for MPLS Data Traffic
Type
For STAMP test packet format1 with IP/UDP headers:
1. MPLS PW Data Traffic (Using CW and IP Header)
2. MPLS-TP PW Data Traffic (Using CW and IP header)
3. MPLS LSP Data Traffic (Using IP Header)
For STAMP test packet format2 without IP/UDP headers:
1. MPLS Ethernet PW Data Traffic [RFC4448]
2. L2-Specific Sublayer (L2SS) used in L2TPv3 PW Data Traffic
[RFC3931]
3. Private Line Emulation [I-D.ietf-pals-ple] PW Data Traffic
4. TDM over IP [RFC5087] PW Data Traffic (no IP Header case)
5. MPLS-TP LSP Data Traffic
3.3. Applicability of Control Channel Types to STAMP Test Packets for 3.3. Applicability of Control Channel Types to STAMP Test Packets for
MPLS MPLS PWs and LSPs
Editor's Note: Convert this into a table.
Control Channel Types defined in [RFC5085] are applicable to STAMP Control Channel Types defined in [RFC5085] are applicable to STAMP
Test Packets for MPLS as follows: Test Packets for MPLS as follows:
Control Channel Type 1 : In-band: Control Word with 0001b as first +==============+==================+==============+=================+
nibble : No IP/UDP Headers Format 2 : G-ACH Type STAMP G-ACH (TBD1/ | Control | Control Channel | STAMP Header | G-ACh Type |
TBD2) | Channel Type | Name | Format | |
+==============+==================+==============+=================+
Control Channel Type 2 : Out-of-band: MPLS Router Alert Label : Not | Type 1 | In-band: Control | Format2 (No | G-ACH Type |
supported : Not supported | | Word with 0001b | IP/UDP | STAMP G-ACH |
| | as first nibble | Headers) | (TBD1/TBD2) |
Control Channel Type 3 : TTL Expiry: MPLS PW Label with TTL as 1 : +--------------+------------------+--------------+-----------------+
IP/UDP Headets Format 1 : IPv4 G-ACH (0x21) and IPv6 G-ACH (0x57) | Type 2 | Out-of-band: | Not | Not supported |
| | MPLS Router | supported | |
| | Alert Label | | |
+--------------+------------------+--------------+-----------------+
| Type 3 | TTL Expiry: MPLS | Format 1 | IPv4 G-ACH |
| | PW Label with | (IP/UDP | (0x21) and IPv6 |
| | TTL as 1 | Headets) | G-ACH (0x57) |
+--------------+------------------+--------------+-----------------+
| Type 3 | TTL Expiry: MPLS | Format2 (No | G-ACH Type |
| | PW Label with | IP/UDP | STAMP G-ACH |
| | TTL as 1 | Headers) | (TBD1/TBD2) |
+--------------+------------------+--------------+-----------------+
Control Channel Type 3 : TTL Expiry: MPLS PW Label with TTL as 1 : No Table 1: Control Channel Types for MPLS PWs and LSPs
IP/UDP Headets Format 2 : G-ACH Type STAMP G-ACH (TBD1/TBD2)
4. Session-Sender Test Packet 4. Session-Sender Test Packet
4.1. Session-Sender Test Packet with IP/UDP Header 4.1. Session-Sender Test Packet with IP/UDP Header
The content of an example STAMP Session-Sender test packet for a PW The content of an example STAMP Session-Sender test packet for a PW
encapsulated using a G-ACh and an IP/UDP header is shown in Figure 2. encapsulated using a G-ACh and an IP/UDP header is shown in Figure 2.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 15, line 24 skipping to change at page 15, line 24
Version: The Version field is set to 0, as defined in [RFC4385]. Version: The Version field is set to 0, as defined in [RFC4385].
Reserved: Reserved Bits MUST be set to zero upon transmission and Reserved: Reserved Bits MUST be set to zero upon transmission and
ignored upon receipt. ignored upon receipt.
Channel Type: G-ACh type for STAMP Session-Reflector packet (TBD2). Channel Type: G-ACh type for STAMP Session-Reflector packet (TBD2).
6. Security Considerations 6. Security Considerations
The procedures defined in this document is intended for deployment in The procedures defined in this document is intended for deployment in
a single operator network domain. As such, the Session-Sender a single network administrative domain. As such, the Session-Sender
address, Session-Reflector address, and IP and MPLS forward and address, Session-Reflector address, and IP and MPLS forward and
return paths are provisioned by the operator for the STAMP session. return paths are provisioned by the operator for the STAMP session.
It is assumed that the operator has verified the integrity of the IP It is assumed that the operator has verified the integrity of the IP
and MPLS forward and return paths used to transmit STAMP test and MPLS forward and return paths used to transmit STAMP test
packets. packets.
The security considerations specified in [RFC8762] and [RFC8972] also The security considerations specified in [RFC8762] and [RFC8972] also
apply to the procedure described in this document. Specifically, the apply to the procedure described in this document. Specifically, the
message integrity protection using HMAC, as defined in Section 4.4 of message integrity protection using HMAC, as defined in Section 4.4 of
[RFC8762], also apply to the procedure described in this document. [RFC8762], also apply to the procedure described in this document.
Routers that support G-ACh are subject to the same security Routers that support G-ACh are subject to the same security
considerations as defined in [RFC4385] and [RFC5586]. considerations as defined in [RFC4385] and [RFC5586].
The message throttling mechanisms described in Security Section of The message throttling mechanisms described in Security Section of
[RFC5085] also apply to the procedure described in this document. [RFC5085] also apply to the procedure described in this document.
STAMP uses the well-known UDP port number that could become a target
of denial of service (DoS) or could be used to aid on-path attacks.
Thus, the security considerations and measures to mitigate the risk
of the attack documented in Section 6 of [RFC8545] equally apply to
the STAMP extensions in this document.
If desired, attacks can be mitigated by performing basic validation
checks of the timestamp fields (such as T2 is later than T1 in the
STAMP Reference Topology shown in Figure 1 in received reply test
packets at the Session-Sender. The minimal state associated with
these protocols also limit the extent of measurement disruption that
can be caused by a corrupt or invalid test packet to a single test
cycle.
7. IANA Considerations 7. IANA Considerations
IANA maintains G-ACh Type Registry (see IANA maintains G-ACh Type Registry (see
https://www.iana.org/assignments/g-ach-parameters/g-ach- https://www.iana.org/assignments/g-ach-parameters/g-ach-
parameters.xhtml). IANA is requested to allocate values for the parameters.xhtml). IANA is requested to allocate values for the
G-ACh Types for STAMP from "MPLS Generalized Associated Channel G-ACh Types for STAMP from "MPLS Generalized Associated Channel
(G-ACh) Types (including Pseudowire Associated Channel Types)" (G-ACh) Types (including Pseudowire Associated Channel Types)"
registry. registry.
+=======+====================================+===============+ +=======+====================================+===============+
| Value | Description | Reference | | Value | Description | Reference |
+=======+====================================+===============+ +=======+====================================+===============+
| TBD1 | STAMP Session-Sender G-ACh Type | This document | | TBD1 | STAMP Session-Sender G-ACh Type | This document |
+-------+------------------------------------+---------------+ +-------+------------------------------------+---------------+
| TBD2 | STAMP Session-Reflector G-ACh Type | This document | | TBD2 | STAMP Session-Reflector G-ACh Type | This document |
+-------+------------------------------------+---------------+ +-------+------------------------------------+---------------+
Table 1: STAMP G-ACh Type Table 2: STAMP G-ACh Type
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 18, line 16 skipping to change at page 18, line 36
(VCCV) Capability Advertisement for MPLS Transport Profile (VCCV) Capability Advertisement for MPLS Transport Profile
(MPLS-TP)", RFC 7189, DOI 10.17487/RFC7189, March 2014, (MPLS-TP)", RFC 7189, DOI 10.17487/RFC7189, March 2014,
<https://www.rfc-editor.org/info/rfc7189>. <https://www.rfc-editor.org/info/rfc7189>.
[RFC7708] Nadeau, T., Martini, L., and S. Bryant, "Using a Generic [RFC7708] Nadeau, T., Martini, L., and S. Bryant, "Using a Generic
Associated Channel Label as a Virtual Circuit Connectivity Associated Channel Label as a Virtual Circuit Connectivity
Verification Channel Indicator", RFC 7708, Verification Channel Indicator", RFC 7708,
DOI 10.17487/RFC7708, November 2015, DOI 10.17487/RFC7708, November 2015,
<https://www.rfc-editor.org/info/rfc7708>. <https://www.rfc-editor.org/info/rfc7708>.
[RFC8545] Morton, A., Ed. and G. Mirsky, Ed., "Well-Known Port
Assignments for the One-Way Active Measurement Protocol
(OWAMP) and the Two-Way Active Measurement Protocol
(TWAMP)", RFC 8545, DOI 10.17487/RFC8545, March 2019,
<https://www.rfc-editor.org/info/rfc8545>.
[I-D.ietf-pals-ple] [I-D.ietf-pals-ple]
Gringeri, S., Whittaker, J., Leymann, N., Schmutzer, C., Gringeri, S., Whittaker, J., Leymann, N., Schmutzer, C.,
and C. Brown, "Private Line Emulation over Packet Switched and C. Brown, "Private Line Emulation over Packet Switched
Networks", Work in Progress, Internet-Draft, draft-ietf- Networks", Work in Progress, Internet-Draft, draft-ietf-
pals-ple-01, 21 October 2023, pals-ple-01, 21 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-pals- <https://datatracker.ietf.org/doc/html/draft-ietf-pals-
ple-01>. ple-01>.
Acknowledgments Acknowledgments
 End of changes. 29 change blocks. 
86 lines changed or deleted 120 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/