跳到主要内容

1. 简介

[RFC9341] 和 [RFC9342] 描述了一种 passive performance measurement method, 可用于在 live traffic 上测量 packet loss, latency 和 jitter. 由于该方法基于对连续的 packet batches 进行标记, 因此通常称为 "Alternate-Marking Method".

Alternate-Marking Method 需要一个 marking field, 以便区分和标识 packet flows. [RFC9343] 定义了一项标准, 说明为实现 Alternate Marking, 如何在 IPv6 packet 的 Hop-by-Hop 或 Destination Options Headers 中的新 TLV 内编码 marking field. 该机制同样适用于 Segment Routing for IPv6 (SRv6) networks [RFC8402].

本文档描述一种替代性的实验方法, 该方法将 marking field 编码在 SRv6 packet 的 Segment Routing Header (SRH) [RFC8754] 中承载的新 TLV 内. 此方法仅适用于 SRv6 部署. 其意图是利用这样一种假设: Segment Routing (SR) nodes 应该支持对 SRH 的快速解析和处理, 而 SR nodes 可能无法正确处理 Destination Options, 如 [RFC9098] 和 [EH-LIMITS] 中所讨论. 此实验旨在确定该方法是否为社区带来显著且有吸引力的优势: 如果有, 该工作可以带回 IETF 考虑.

此 protocol extension 是在 IETF 之外开发的, 作为 IETF Standards Track 规范 [RFC9343] 的替代方案; 它不具有 IETF 共识. 在此发布它, 是为了指导实验性实现, 并确保实现之间的互操作性, 以便更好地确定此方法的价值. 如 [IETF-EXPERIMENTS] 中也强调的, 当提出两个 protocol extensions 来解决同一个问题时, 可以启动实验以收集运行经验并 "determine which, if either, of the protocols should be progressed to the standards track." 这正是本文档的目的. 关于该实验的更多细节见第 5 节.

1.1. 对 RFC 9343 的观察​

与任何其他 IPv6 用例一样, 当存在 SRH 时, 也可以使用 Hop-by-Hop 和 Destination Options. 如 [RFC8200] 所规定, Hop-by-Hop Options Header 用于承载需要路径上每一跳检查的可选信息, 而 Destination Options Header 用于承载仅需要 packet 的 destination node(s) 检查的可选信息.

当存在 Routing Header 时, 由于 SRH 是 Routing Header, IPv6 packet 中位于 SRH header 之前的 Destination Options 将由 SRH route list 中指示的 destination 处理. 如 [RFC8754] 所规定, SR segment endpoint nodes 处理与 packet destination address 对应的本地 Segment Identifier (SID). 随后, destination address 根据 segment list 更新. 如果节点经本地配置这样做, SRH TLV 会在处理 SID 时为 segment processing 提供 metadata. 位于 SRH 之前的 Destination Options Header 和 SRH TLV 都在 IPv6 header 的 destination address field 所指示的节点处处理.

对于穿越某一网络的 SRv6 packets, 如果相邻 segment endpoints 之间的路径包含多跳, 这些替代方案之间的差异最为明显. 如果使用 Hop-by-Hop Option, 路径上的每一跳都会处理 AltMark data. 如果使用位于 SRH 之前的 Destination Option, 或者使用 SRH AltMark TLV, 则只有 segment endpoints 会处理 AltMark data, 除非中间节点具有不同的优先级规则.

[RFC9343] 和本文档规定的方法可以共存. 事实上, 本文档不会更改或废止 [RFC9343] 中定义的任何程序. 但是, 如下文进一步讨论, 可能出现部署问题.

本文档其余部分结构如下:

  • 第 2 节介绍 Alternate-Marking Method 到 SRv6 的应用,

  • 第 3 节规定用于承载 base data fields (第 3.1 节) 和 extended data fields (第 3.2 节) 的 AltMark SRH TLV,

  • 第 4 节讨论 AltMark TLV 的使用, 以及

  • 第 5 节描述该实验和实验目标 (第 5.1 节).

1.2. 需求语言​

本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" 和 "OPTIONAL" 在且仅在以此处所示全大写形式出现时, 应按 BCP 14 [RFC2119] [RFC8174] 中的描述解释.

最后于 更新