7. 操作考虑事项
7.1. 时间准确度
就时钟精度而言, [RFC5153] 第 4.5 节中为 IPFIX 定义的相同建议也适用于本文档.
7.2. 平均延迟
平均路径延迟可以在 IPFIX 数据收集时, 在收集时间通过将 pathDelaySumDeltaMicroseconds(533) 除以 packetDeltaCount(2) 来计算, 而不是在 IPFIX Exporter 导出时间计算.
7.3. 缩减尺寸编码
pathDelaySumDeltaMicroseconds 选择 unsigned64 作为类型, 是为了支持延迟数值较大且统计大量数据包的情况. 例如, 对于路径延迟为 100 毫秒的特定 Flow Record, 若不使 unsigned32 计数器溢出, 能观测的数据包数量不能超过 42949 个. 如果 unsigned32 足够大且不会回绕, 可以应用 [RFC7011] 第 6.2 节所述过程, 以减少 IPFIX Exporter 与 Collector 之间的网络带宽.
7.4. 测量间隔
通过比较每个收到的数据包中的 OAM 时间戳与收到该数据包时的时间戳, 可以在 Flow Record 生命周期内计算延迟指标. 对于长时间运行的 Flow, IPFIX Metering Process 可能会遗漏延迟的时间分布 (例如, 仅在 Flow 开始时存在较长延迟). 如果这构成操作问题, 可以为 IPFIX Metering Process 配置更小的过期超时 (见 [RFC5470] 第 5.1.1 节 "Flow Expiration").
7.5. 数据包内 OAM 应用
可以使用多种方法计算本文档定义的延迟性能指标. 这类方法的一些示例包括 IOAM [RFC9197] 和 Enhanced Alternate Marking [ENH-ALT-MARKING].
对于 IOAM, 这些性能指标可以使用 Edge-to-Edge 和 Direct Exporting Option-Type 来计算.
[RFC9197] 第 4.6 节所述的 IOAM Edge-to-Edge Option-Type 可以使用比特 2 和 3. 在这种情况下, 时间戳按照 [RFC9197] 第 4.4.2.3 节和第 4.4.2.4 节中的定义进行编码. 该时间戳可用于计算 OAM header encapsulating node 与 decapsulating node 之间的延迟.
[RFC9326] 中所述的 IOAM Direct Exporting Option-Type 可以使用 [IOAM-DEX] 中定义的 Extension-Flag, 在 OAM header encapsulating node 中插入时间戳. 时间戳按照 [RFC9197] 第 4.4.2.3 节和第 4.4.2.4 节中的定义进行编码. 该时间戳可用于计算所插入的时间戳与 OAM header transit node 和 decapsulating node 之间的延迟.
对于 Enhanced Alternate Marking Method, [ENH-ALT-MARKING] 第 2 节和 [RFC9947] 第 3.2 节定义了可以在 metaInfo 中, 于 OAM header encapsulating node 内编码纳秒时间戳, 并由 OAM header intermediate node 和 decapsulating node 读取该时间戳以计算 On-path delay. [RFC9343] 定义了如何将其应用于 IPv6 extensions header, [RFC9947] 定义了如何将其应用于 SRv6 Segment Routing Header [RFC8754].
鉴于无论采用何种方法, 延迟测量都是使用在 OAM header encapsulating node 上引入的时间戳计算的, 实现应当记录该时间戳是在转发平面的哪个点引入的 (例如, 节点收到数据包的时间, 节点发送数据包的时间等). 基于这些信息, 可以采取不同的操作.