51学通信

04-控制平面协议扩展

46分钟阅读

IPv6随路遥测驱动网络运维新变革 第 4 篇：控制平面协议扩展

摘要

本文将带你深入了解IPv6随路遥测的控制平面协议扩展机制，帮助你掌握IGP、BGP、BGP-LS、BGP SR Policy和PCEP等协议如何支持随路遥测的自动化部署和能力通告。你将学到IGP扩展的IFIT能力通告机制、BGP-LS扩展实现拓扑信息上报、BGP SR Policy扩展的IOAM选项、PCEP扩展的集中控制机制以及协议选择与部署策略。

学习目标

阅读完本文后，你将能够：

  • 能力1：理解IGP（IS-IS和OSPFv3）扩展的IFIT能力通告机制，掌握节点和链路能力TLV的格式和用法
  • 能力2：掌握BGP-LS扩展如何将IFIT能力信息上报给控制器，理解节点和链路TLV的结构
  • 能力3：了解BGP SR Policy扩展的IFIT属性，学会通过BGP策略自动部署随路测量实例
  • 能力4：理解PCEP扩展如何实现集中式随路遥测控制，掌握PCEP消息格式和流程
  • 能力5：掌握不同协议扩展的选择策略，能够在实际网络中设计合理的随路遥测部署方案

引言

在前面的文章中，我们详细介绍了IPv6随路遥测的架构设计和数据平面技术。这些技术解决了”如何测量”的问题，但还有一个同样重要的问题需要解决：如何自动化地部署和管理这些测量功能？

传统的网络运维方式需要管理员在每个设备上手动配置测量实例，这种方式不仅工作量大，而且容易出错。更重要的是，它无法适应现代网络的动态特性——流量路径会随网络状况变化而调整，测量配置也需要跟随动态调整。

控制平面协议扩展正是为了解决这些问题。通过扩展现有的路由协议和信令协议，让网络设备能够自动通告自己的随路遥测能力，让控制器能够基于全网拓扑信息自动部署测量实例，实现真正的”零配置”随路遥测。

51学通信认为，控制平面协议扩展是随路遥测技术从实验走向商用的关键。没有自动化能力，随路遥测只能在特定的实验环境或小型网络中使用；有了自动化能力，它才能在大规模的运营商网络中落地生根。

本文将详细介绍各种控制平面协议的扩展机制，帮助读者全面理解随路遥测的自动化部署原理。

1. IGP扩展的IFIT能力通告

IGP（Interior Gateway Protocol，内部网关协议）是AS内部使用的路由协议，主要包括IS-IS和OSPFv3。通过IGP扩展，网络节点可以相互通告自己支持的随路遥测能力，为后续的测量实例部署奠定基础。

1.1 IGP IFIT能力TLV格式

draft-wang-lsr-igp-extensions-ifit定义了IGP IFIT能力通告的统一格式。这个能力TLV由一系列的元组组成，每个元组包含两个部分：Namespace-ID和Option-Type enabled Flag。

flowchart TD
    A[IGP IFIT Capability TLV] --> B[Type字段]
    A --> C[Length字段]
    A --> D[能力元组数组]

    D --> E[元组1]
    D --> F[元组2]
    D --> G[元组N]

    E --> H[Namespace-ID 2字节]
    E --> I[Option-Type enabled Flag 2字节]

    I --> J[P bit: Pre-allocated Trace]
    I --> K[I bit: Incremental Trace]
    I --> L[D bit: Direct Export]
    I --> M[E bit: E2E Option]
    I --> N[M bit: Alternate Marking]

图表讲解：

上图展示了IGP IFIT能力TLV的基本结构。每个能力元组包含一个Namespace-ID字段和一个Option-Type enabled Flag字段。Namespace-ID用于隔离不同的测量域，同一测量域内的节点使用相同的Namespace-ID值。0x0000是默认的Namespace-ID，所有支持IOAM的节点都必须支持。

Option-Type enabled Flag是一个16位的位图，每个比特位对应一种随路遥测能力。P bit置位表示节点支持IOAM Pre-allocated Trace；I bit置位表示支持IOAM Incremental Trace；D bit置位表示支持IOAM Direct Export；E bit置位表示支持IOAM Edge-to-Edge；M bit置位表示支持Alternate Marking方法。

通过这种位图设计，一个TLV就可以通告多种不同的能力，既节省了协议开销，又保证了扩展性。未来如果需要定义新的随路遥测能力，只需要使用尚未使用的比特位即可。

51学通信建议，在实际部署中应该根据网络设备的实际能力设置这些标志位。如果设备只支持Alternate Marking而不支持IOAM，就只设置M bit；如果设备全面支持各种随路遥测功能，可以将所有相关bit都置位。

1.2 IS-IS扩展实现

IS-IS协议使用Router Capability TLV（RFC 7981）来通告路由器的各种能力。随路遥测能力可以通过定义新的子TLV的方式来通告。

flowchart TD
    A[IS-IS Router Capability TLV] --> B[Type=242]

    B --> C[子TLV数组]

    C --> D[Node IFIT Capability Sub-TLV]
    C --> E[Link IFIT Capability Sub-TLV]

    D --> F[Type: 待分配]
    D --> G[Length]
    D --> H[Node-IFIT-Capability]

    E --> I[Type: 待分配]
    E --> J[Length]
    E --> K[Link-IFIT-Capability]

    H --> L[包含节点级能力]
    K --> M[包含链路级能力]

图表讲解：

上图展示了IS-IS中IFIT能力的通告方式。Node IFIT Capability Sub-TLV用于通告节点的随路遥测能力，表示这个节点本身支持哪些测量功能。Link IFIT Capability Sub-TLV用于通告特定链路的能力，这对于节点不同接口有不同能力的情况很有用。

Link IFIT Capability Sub-TLV可以携带在多种IS-IS TLV中，包括Extended IS Reachability TLV（类型22）、IS Neighbor Attribute TLV（类型23）、L2 Bundle Member Attributes TLV（类型25）等。这种灵活的携带方式使得IS-IS可以在各种链路状态通告中携带随路遥测能力信息。

51学通信特别提醒，IS-IS扩展已经相对成熟，多个厂商设备已经实现了相关功能。在部署IS-IS扩展时，需要确保网络中的所有IS-IS设备都支持新的Sub-TLV，或者至少能够透明转发这些Sub-TLV，以避免协议解析错误。

1.3 OSPFv3扩展实现

OSPFv3使用Router Information（RI）LSA来通告可选的路由器能力信息。随路遥测能力可以通过定义新的TLV的方式在RI LSA中通告。

flowchart TD
    A[OSPFv3 RI LSA] --> B[TLV数组]

    B --> C[Node IFIT Capability TLV]
    B --> D[其他能力TLV]

    C --> E[Type: 待分配]
    C --> F[Length]
    C --> G[Node-IFIT-Capability]

    G --> H[Namespace-ID + Flag数组]

    D --> I[链路级能力]

    I --> J[作为Extensible Router-Link TLV的子TLV]
    J --> K[Link IFIT Capability Sub-TLV]

图表讲解：

上图展示了OSPFv3中IFIT能力的通告方式。与IS-IS类似，OSPFv3也区分节点级能力和链路级能力。节点级能力通过RI LSA中的专用TLV通告，链路级能力通过Extensible Router-Link TLV的子TLV通告。

OSPFv3的链路级能力通告稍微复杂一些。Extensible Router-Link TLV是OSPFv3扩展LSA（E-Router-LSA）的一部分，用于传递路由器链路的详细信息。Link IFIT Capability Sub-TLV作为这个TLV的子TLV，可以携带特定链路的随路遥测能力。

IS-IS和OSPFv3虽然实现细节不同，但采用的设计理念是一致的：通过扩展现有的协议能力通告机制，以最小化对现有协议的影响。这种增量式扩展的方式有利于平滑升级和部署。

1.4 能力协商与部署决策

网络节点通过IGP扩展相互通告自己的随路遥测能力后，控制器或入口节点可以基于这些信息做出部署决策。

flowchart TD
    A[入口节点] --> B{查询IFIT能力}

    B --> C[获取路径信息]
    B --> D[获取节点能力]

    C --> E[链路状态数据库]
    D --> F[IGP能力通告]

    E --> G{路径完整性检查}
    F --> G

    G --> H{所有节点支持所需能力?}

    H -->|是| I[部署测量实例]
    H -->|否| J[调整测量策略]

    J --> K{端到端支持?}
    K -->|是| L[使用端到端模式]
    K -->|否| M[分段部署]

图表讲解：

上图展示了基于IGP能力通告的部署决策流程。入口节点在部署测量实例前，首先需要查询路径上所有节点的随路遥测能力。这些能力信息通过IGP协议在网络中扩散，每个节点都维护着全网的能力信息。

如果路径上所有节点都支持所需的测量能力（如都支持Alternate Marking），就可以直接部署端到端的测量实例。如果只有部分节点支持，则需要调整测量策略，例如只部署端到端测量而不启用逐跳测量，或者将测量路径分段，每段内部独立部署。

这种基于能力感知的部署决策机制是随路遥测自动化的基础。它确保了测量实例只部署在支持相应能力的设备和链路上，避免了在不支持的环境中部署测量功能导致的异常行为。

51学通信认为，IGP能力通告是整个自动化部署体系的基础。没有这个基础，控制器或入口节点就无法知道网络中哪些地方可以部署哪种测量功能，自动化也就无从谈起。

2. BGP-LS扩展实现拓扑信息上报

BGP-LS（BGP Link-State）是一种将IGP链路状态信息通过BGP协议上报给控制器的机制。通过扩展BGP-LS，可以将随路遥测能力信息上报给控制器，实现集中式的网络视图和智能的测量部署。

2.1 BGP-LS节点能力TLV

draft-wang-idr-bgpls-extensions-ifit定义了BGP-LS中的IFIT能力TLV格式。这个TLV与IGP中的能力TLV格式相同，都包含Namespace-ID和Option-Type enabled Flag数组。

flowchart TD
    A[BGP-LS更新消息] --> B[NLRI: Node]

    B --> C[Attributes]

    C --> D[Node Attributes TLV]

    D --> E[Node IFIT Capability TLV]

    E --> F[Type: 待分配]
    E --> G[Length]
    E --> H[Node-IFIT-Capability]

    H --> I[Namespace-ID元组1]
    H --> J[Namespace-ID元组2]
    H --> K[...]

    I --> L[Namespace-ID + Flags]
    J --> L

图表讲解：

上图展示了BGP-LS节点能力TLV的封装方式。BGP-LS通过BGP UPDATE消息传递链路状态信息，其中NLRI（Network Layer Reachability Information）字段标识信息所属的节点或链路，Attributes字段携带具体的属性信息。

Node IFIT Capability TLV作为Node Attributes的一部分，携带节点的随路遥测能力信息。由于一个节点可能同时参与多个测量域（使用不同的Namespace-ID），TLV中可以包含多个Namespace-ID元组，每个元组描述一个测量域中的能力信息。

控制器通过收集所有节点的BGP-LS信息，可以构建出包含随路遥测能力的全网拓扑视图。这个视图是智能测量部署的基础——控制器可以基于这个视图分析哪些路径支持端到端测量，哪些路径需要分段部署，哪些链路由于能力限制需要绕行。

2.2 BGP-LS链路能力TLV

除了节点能力，BGP-LS还可以上报链路级的随路遥测能力。这对于那些不同接口有不同能力的设备特别有用。

flowchart TD
    A[BGP-LS更新消息] --> B[NLRI: Link]

    B --> C[Attributes]

    C --> D[Link Attributes TLV]

    D --> E[Link IFIT Capability TLV]

    E --> F[Type: 待分配]
    E --> G[Length]
    E --> H[Link-IFIT-Capability]

    H --> I[与Node TLV格式相同]
    I --> J[应用于特定链路]

    J --> K[本地链路]
    J --> L[远程链路]

图表讲解：

上图展示了BGP-LS链路能力TLV的封装方式。Link IFIT Capability TLV作为Link Attributes的一部分，携带特定链路的随路遥测能力。TLV的格式与Node TLV相同，都包含Namespace-ID和Option-Type enabled Flag数组。

链路级能力的上报使得控制器可以更精细地理解网络的测量能力分布。例如，一个设备的某个接口可能由于硬件限制不支持某种测量功能，但其他接口支持。通过链路级能力上报，控制器可以了解这种细粒度的能力差异，并在部署测量实例时做出更精确的决策。

51学通信特别提醒，BGP-LS扩展是连接IGP域和控制器的关键桥梁。IGP扩展在网络内部扩散能力信息，BGP-LS扩展将这些信息”翻译”成控制器可以理解的格式上报。这种分层的设计使得随路遥测能力可以在多域网络中部署，每个域内部使用IGP扩散能力信息，域与域之间通过BGP-LS上报信息。

2.3 控制器应用场景

控制器收集到全网的能力信息后，可以实现多种智能应用。

flowchart TD
    A[控制器] --> B[收集BGP-LS信息]

    B --> C[构建拓扑能力视图]

    C --> D[智能应用]

    D --> E[测量路径规划]
    D --> F[测量策略生成]
    D --> G[故障影响分析]
    D --> H[能力可视化]

    E --> I[选择最优路径]
    F --> J[自动配置下发]
    G --> K[预测故障影响]
    H --> L[运维人员查看]

图表讲解：

上图展示了控制器基于BGP-LS信息的智能应用。测量路径规划是基于能力拓扑视图的典型应用。控制器可以分析多条候选路径的测量能力支持情况，选择最能满足测量需求的路径。例如，如果需要进行逐跳丢包测量，控制器会选择所有节点都支持相应测量能力的路径。

测量策略生成是指控制器根据业务需求和网络能力自动生成测量配置。例如，对于高优先级的业务，控制器可以启用精细的逐跳测量；对于普通业务，可以只部署端到端测量以节省资源。

故障影响分析是预测性的应用。当网络中某个节点或链路发生故障时，控制器可以快速分析这个故障对现有测量实例的影响，并自动调整测量配置。例如，如果某个测量路径中断，控制器可以自动为该业务重新规划测量路径。

能力可视化则是面向运维人员的应用。通过图形化的界面展示全网的能力分布，运维人员可以直观地了解哪些区域支持哪些测量功能，哪些地方需要升级设备以支持新的测量能力。

51学通信认为，控制器是随路遥测自动化部署的”大脑”，而BGP-LS扩展是控制器的”眼睛”。没有BGP-LS扩展上报的能力信息，控制器就无法做出智能的部署决策，随路遥测的自动化也就无从谈起。

3. BGP SR Policy扩展的IFIT属性

BGP SR Policy是一种通过BGP协议下发SRv6路径策略的机制。通过扩展BGP SR Policy，可以在下发路径策略的同时携带随路遥测配置参数，实现测量实例的自动部署。

3.1 SR Policy IFIT属性结构

draft-ietf-idr-sr-policy-ifit定义了BGP SR Policy中的IFIT属性结构。这个属性作为Tunnel Encapsulation Attribute的一部分，与SR Policy信息一起下发。

flowchart TD
    A[BGP SR Policy] --> B[ Tunnel Encapsulation Attribute]

    B --> C[SR Policy特定的TLV]

    C --> D[IFIT Attribute Sub-TLV]

    D --> E[Type: 待分配]
    D --> F[Length]
    D --> G[Sub-TLVs]

    G --> H[IOAM Pre-allocated Trace Sub-TLV]
    G --> I[IOAM Incremental Trace Sub-TLV]
    G --> J[IOAM Direct Export Sub-TLV]
    G --> K[IOAM Edge-to-Edge Sub-TLV]
    G --> L[Enhanced Alternate Marking Sub-TLV]

图表讲解：

上图展示了BGP SR Policy IFIT属性的封装结构。IFIT Attribute Sub-TLV作为SR Policy的一部分，可以包含多个不同的Sub-TLV，每个Sub-TLV对应一种随路遥测方法。

这种模块化的设计使得BGP SR Policy可以灵活地携带各种随路遥测配置。如果业务只需要丢包测量，可以只携带Alternate Marking Sub-TLV；如果需要详细的路径追踪，可以同时携带IOAM Trace Sub-TLV。

BGP协议的优势在于它的可扩展性和自动化能力。通过BGP SR Policy扩展，随路遥测配置可以与SRv6路径配置同步下发，确保测量实例与业务路径的一致性。当业务路径发生变化时，测量配置也会随之自动调整。

51学通信建议，对于已经部署了BGP SR Policy的网络，优先考虑使用BGP SR Policy扩展来部署随路遥测。这样可以最大程度地复用现有的控制平面基础设施，降低部署复杂度。

3.2 IOAM Sub-TLV详解

BGP SR Policy支持多种IOAM Sub-TLV，每种Sub-TLV对应一种IOAM选项类型。以下是几种主要的IOAM Sub-TLV：

flowchart TD
    A[IOAM Sub-TLVs] --> B[Pre-allocated Trace]
    A --> C[Incremental Trace]
    A --> D[Direct Export]
    A --> E[Edge-to-Edge]

    B --> F[Namespace-ID 16bit]
    B --> G[IOAM Trace-type 24bit]
    B --> H[Flags 4bit]

    C --> F
    C --> G
    C --> H

    D --> I[Namespace-ID 16bit]
    D --> J[Flags 16bit]
    D --> K[IOAM Trace-type 24bit]
    D --> L[Flow ID 32bit]

    E --> M[Namespace-ID 16bit]
    E --> N[E2E-Type 16bit]

图表讲解：

上图对比了几种主要IOAM Sub-TLV的字段结构。Pre-allocated Trace和Incremental Trace的结构类似，都包含Namespace-ID、IOAM Trace-type和Flags字段。IOAM Trace-type是一个24位的位图，定义了需要采集的数据类型（节点ID、接口ID、时间戳等）。

Direct Export Sub-TLV额外包含Flow ID字段，这是因为在Direct Export模式下，每个节点直接上报数据，需要一个公共的Flow ID来关联不同节点的数据。Edge-to-Edge Sub-TLV使用E2E-Type字段定义需要携带的端到端数据类型（如序列号、时间戳等）。

这些Sub-TLV的设计充分考虑了与IOAM数据平面格式的一致性。BGP SR Policy携带的配置参数可以直接映射到数据平面的封装格式中，无需复杂的转换处理。

3.3 冲突处理与兼容性

BGP SR Policy IFIT Attribute中可能包含多个Sub-TLV，需要处理潜在的冲突情况。

flowchart TD
    A[接收BGP SR Policy] --> B[解析IFIT Attribute]

    B --> C[检查Sub-TLVs]

    C --> D{存在冲突?}

    D -->|是| E[冲突类型判断]

    E --> F[相同类型多个Sub-TLV]
    E --> G[不同类型冲突]

    F --> H[忽略所有相关Sub-TLV]
    G --> I[忽略不支持的Sub-TLV]

    D -->|否| J[正常处理]

    H --> K[不启用相关测量]
    I --> L[启用支持的测量]
    J --> L

图表讲解：

上图展示了BGP SR Policy IFIT Attribute的冲突处理机制。如果IFIT Attribute中包含多个相同类型的Sub-TLV（例如两个Pre-allocated Trace Sub-TLV），这表示配置存在冲突，节点应该忽略所有相关的Sub-TLV，不启用相应的测量功能。

如果IFIT Attribute中包含不同类型的Sub-TLV（例如同时包含Pre-allocated Trace和Incremental Trace），这也是配置冲突，但处理方式稍有不同。节点可以选择忽略不支持的那个Sub-TLV，只处理支持的那个。这种处理方式保证了良好的向后兼容性——新版本的节点支持更多功能，但也能与旧版本节点共存。

对于节点无法识别的Sub-TLV，节点应该直接忽略，继续处理其他的Sub-TLV。这种”忽略未知”的设计原则确保了协议的平滑演进——新的功能可以通过定义新的Sub-TLV来添加，而不影响不支持新功能的旧节点。

51学通信特别提醒，BGP SR Policy扩展的自动化能力非常强大，但也需要谨慎使用。错误的配置可能在大范围内快速传播，影响大量业务。建议在部署初期进行充分的测试，并使用适当的配置验证和保护机制。

4. PCEP扩展实现集中控制

PCEP（Path Computation Element Protocol）是一种用于路径计算的协议，常用于SDN场景下的集中式路径计算。通过扩展PCEP，可以实现集中式的随路遥测控制。

4.1 PCEP消息扩展

PCEP使用各种消息类型进行通信，包括PCReq（路径计算请求）、PCRep（路径计算回复）等。通过定义新的TLV或对象，可以在这些消息中携带随路遥测配置。

flowchart TD
    A[PCEP消息] --> B{消息类型}

    B -->|PCReq| C[PCC发送请求]
    B -->|PCRep| D[PCE返回响应]
    B -->|PCInitiate| E[PCE发起配置]
    B -->|PCUpd| F[PCE更新配置]

    C --> G[携带IFIT能力需求]
    D --> H[携带IFIT配置参数]
    E --> I[携带IFIT实例配置]
    F --> J[携带IFIT配置更新]

    I --> K[SRP对象]
    I --> L[LSP对象]
    I --> M[IFIT TLV]

图表讲解：

上图展示了PCEP扩展的各种消息类型。PCReq消息由PCC（Path Computation Client）发送给PCE（Path Computation Element），请求计算一条满足特定要求的路径，这个要求可以包括随路遥测能力需求。

PCRep消息由PCE返回给PCC，包含计算出的路径和相应的配置参数，其中可以包含随路遥测的配置参数。PCInitiate消息由PCE主动发起，用于创建或修改LSP（Label Switched Path），可以携带完整的随路遥测实例配置。

PCUpd消息用于更新现有的LSP配置，可以携带随路遥测配置的更新信息。例如，当检测到网络异常时，PCE可以通过PCUpd消息动态调整随路遥测的测量粒度或模式。

PCEP扩展的优势在于它支持集中式的智能决策。PCE拥有全网的拓扑和资源信息，可以做出更优的路径计算和测量部署决策。PCC负责具体的执行，两者分工明确，便于实现大规模网络的自动化管理。

4.2 PCE与BGP SR Policy协同

PCEP和SR Policy可以协同工作，实现更灵活的随路遥测部署。

flowchart TD
    A[控制器] --> B{部署方式选择}

    B -->|简单场景| C[直接使用BGP SR Policy]
    B -->|复杂场景| D[使用PCE计算 + BGP下发]

    C --> E[控制器直接下发SR Policy]
    E --> F[携带IFIT配置]

    D --> G[PCE计算最优路径]
    G --> H[考虑IFIT能力分布]
    H --> I[生成SR Policy]
    I --> J[BGP下发SR Policy]

    F --> K[设备执行测量]
    J --> K

图表讲解：

上图展示了PCEP和BGP SR Policy协同工作的两种模式。在简单场景中，控制器可以直接使用BGP SR Policy下发配置，无需PCE参与。这种方式实现简单，适合网络规模较小或部署需求较简单的情况。

在复杂场景中，可以使用PCE进行路径计算，然后通过BGP SR Policy下发配置。PCE可以基于全网的随路遥测能力分布，计算出最优的路径和测量配置。计算出的路径策略通过BGP SR Policy下发，利用BGP的自动化能力实现配置的快速扩散。

这种混合模式结合了PCE的智能决策能力和BGP的自动化下发能力，是大规模网络部署的理想选择。PCE负责复杂的计算和优化，BGP负责配置的分发和维护。

51学通信认为，PCEP扩展在多域网络中特别有价值。通过层次化的PCE架构（父PCE和子PCE），可以实现跨域的随路遥测部署，每个域内部由子PCE管理，域间协调由父PCE负责。

5. 协议选择与部署策略

不同的控制平面协议扩展各有优势，实际部署中需要根据网络场景和技术条件选择合适的协议。

5.1 协议特性对比

协议扩展优势适用场景复杂度
IGP扩展快速扩散能力信息单域内部部署低
BGP-LS扩展集中式能力视图多域网络、控制器场景中
BGP SR Policy扩展与路径同步部署已部署SRv6的网络中
PCEP扩展集中式智能决策SDN网络、多域优化高

表格讲解：

上表对比了四种主要协议扩展的特性。IGP扩展是最基础的能力扩散机制，适合在单域网络中使用。它的优势是实现简单，不需要引入新的协议组件，但缺点是只能在本域内扩散信息，无法实现跨域的能力交换。

BGP-LS扩展适合多域网络和基于控制器的部署场景。它可以将各域的能力信息集中上报给控制器，由控制器进行统一的分析和决策。这种方式适合大规模网络，但需要部署BGP-LS和相应的控制器组件。

BGP SR Policy扩展适合已经部署了SRv6的网络。它可以与SRv6路径配置同步下发随路遥测配置，实现真正的”零配置”部署。这种方式的复杂度适中，但需要网络支持SRv6和BGP SR Policy。

PCEP扩展适合SDN网络和需要复杂优化的场景。PCE可以基于全网信息进行智能决策，实现最优的随路遥测部署。但PCEP的部署复杂度较高，需要额外的PCE服务器和相应的配置。

5.2 分阶段部署策略

对于大多数运营商网络，随路遥测的部署是一个渐进的过程，可以采用分阶段的策略。

flowchart TD
    A[阶段1: 基础能力部署] --> B[启用IGP扩展]
    B --> C[节点间通告能力]

    A --> D[手动配置关键业务测量]

    C --> E[阶段2: 局部自动化]
    E --> F[部署控制器]
    F --> G[启用BGP-LS上报]
    G --> H[自动化单域部署]

    H --> I[阶段3: 全网自动化]
    I --> J[启用BGP SR Policy]
    J --> K[部署PCE可选]
    K --> L[智能多域部署]

图表讲解：

上图展示了一个典型的分阶段部署策略。第一阶段专注于建立基础的能力，通过IGP扩展在网络内部扩散随路遥测能力信息，同时手动配置一些关键业务的测量实例，验证技术的可行性。

第二阶段引入控制器和BGP-LS，实现单域内的自动化部署。控制器收集全域能力信息，自动为业务规划测量路径并下发配置。这个阶段可以大幅降低运维工作量，提高部署效率。

第三阶段实现全网范围的自动化，可能包括多个域的协同。通过BGP SR Policy或PCEP，实现跨域的智能测量部署。这个阶段的目标是实现真正的”零配置”——业务上线时自动创建测量实例，业务下线时自动删除测量实例。

51学通信特别提醒，分阶段部署的关键是每个阶段都要有明确的目标和验收标准。不要急于进入下一阶段，要确保当前阶段的功能稳定可靠后再继续推进。

常见问题解答

Q1：IGP扩展和BGP-LS扩展有什么区别？应该优先部署哪种？

答：IGP扩展和BGP-LS扩展是互补的技术，分别解决不同层面的问题。IGP扩展用于在AS内部扩散随路遥测能力信息，是基础的能力扩散机制。所有参与随路遥测的设备都需要支持IGP扩展，否则能力信息无法在网络中传播。BGP-LS扩展用于将IGP收集的能力信息上报给控制器，是实现集中式智能分析的关键。如果要部署基于控制器的自动化解决方案，BGP-LS扩展是必需的。从部署优先级来看，应该先部署IGP扩展，建立基础的能力信息扩散能力。然后再根据需要部署BGP-LS扩展，如果计划使用控制器进行集中管理，BGP-LS就是必需的；如果计划使用分布式的自动化方式（如BGP SR Policy），BGP-LS可能不是必需的。51学通信建议，在大多数运营商网络中，两种扩展都需要部署，IGP扩展建立基础，BGP-LS扩展向上层提供信息，两者共同构成完整的自动化能力体系。

Q2：BGP SR Policy扩展是否要求全网设备都支持SRv6？

答：BGP SR Policy扩展确实依赖于SRv6基础设施，但不一定要求全网设备都支持SRv6。SRv6的部署可以是渐进的，可以先在核心区域部署SRv6，接入区域继续使用传统的IP/MPLS。在这种情况下，BGP SR Policy可以用于SRv6域内的随路遥测自动化部署，非SRv6域则可以使用其他方式（如IGP扩展加手动配置）。从技术实现来看，BGP SR Policy携带的随路遥测配置只在SRv6域内生效，非SRv6设备不会处理这些配置，只会透明转发SRv6数据包。这种混合部署模式在过渡阶段很常见。需要注意的是，跨域的端到端测量在这种混合环境中会比较复杂，可能需要将测量路径分段，SRv6域内使用BGP SR Policy自动化部署，非SRv6域使用手动配置或其他自动化机制。51学通信认为，SRv6是网络演进的方向，但演进过程是渐进的。在规划随路遥测部署时，应该考虑网络当前的SRv6部署情况和未来的演进计划，选择适合当前阶段的技术方案。

Q3：PCEP扩展相比其他协议扩展有什么独特价值？什么时候需要使用PCEP？

答：PCEP扩展的独特价值在于集中式的智能路径计算。IGP、BGP-LS、BGP SR Policy等协议主要用于信息扩散和配置下发，它们本身不包含复杂的路径计算逻辑。PCEP则不同，它专门用于路径计算，PCE可以基于全网的详细信息（包括随路遥测能力分布）计算出最优的路径和测量配置。PCEP在以下几种场景中特别有价值：多域网络中，不同域可能使用不同的IGP，甚至不同的技术（如SRv6和MPLS共存），这时需要PCE进行跨域的路径计算和测量配置协调；复杂的优化需求，如需要同时考虑多种约束条件（带宽、时延、成本、测量能力等）的优化场景；动态调整需求，如需要根据网络状况动态调整测量策略的场景。如果网络相对简单，测量需求也比较标准，可能不需要PCEP的复杂度。但如果网络规模大、结构复杂、优化需求多，PCEP的价值就会体现出来。51学通信建议，在部署PCEP前要仔细评估投入产出比。PCEP的部署和维护成本较高，只有在确实需要复杂优化能力的场景中才是值得的。

Q4：多厂商环境下的协议扩展兼容性如何保证？有哪些注意事项？

答：多厂商环境下的兼容性是部署随路遥测时需要重点关注的问题。虽然协议扩展标准定义了统一的格式，但不同厂商的实现可能存在差异，这些差异可能影响互操作性。保证兼容性的关键措施包括：在部署前进行充分的互操作性测试，验证不同厂商设备之间的协议交互是否正常；使用标准定义的字段和格式，尽量避免使用厂商私有扩展；对于可能存在多种实现方式的功能，明确部署时应采用的具体方式；建立完善的测试和验证流程，在设备升级或配置变更时进行充分的测试。部署时的注意事项包括：如果某个厂商设备不支持特定的协议扩展，需要规划相应的过渡方案，如暂时使用手动配置；对于关键业务，建议使用同一厂商的设备组成端到端路径，避免跨厂商的实现差异；建立清晰的版本管理策略，确保所有设备使用兼容的软件版本。51学通信特别提醒，协议标准的制定和实际产品的实现往往存在时间差，某些新功能可能需要等待所有主流厂商都支持后才能大规模部署。在规划部署时，应该调研目标厂商产品的功能支持情况，制定切实可行的部署计划。

Q5：如何选择合适的数据上报协议？gRPC、UDP Telemetry和IPFIX各有什么特点？

答：这三种协议分别适用于不同的场景，选择时需要考虑数据量、实时性、可靠性等因素。gRPC是一种基于TCP的可靠传输协议，适合传输关键的配置和控制信息。它的优势是可靠性高、支持双向通信、有完善的安全机制（如TLS加密），但开销相对较大，不适合高频的海量数据上报。UDP Telemetry是一种基于UDP的高效数据上报协议，适合高频的海量数据上报。它的优势是开销小、性能高、支持硬件加速，但UDP本身不保证可靠性，需要在上层实现丢包检测和重传机制。IPFIX是一种基于流的数据上报协议，适合上报流量统计类的数据。它的优势是标准化程度高、支持模板机制、适合流数据上报，但实时性相对较低，不太适合秒级的高频数据上报。选择建议：对于随路遥测的配置管理，使用gRPC；对于高频的测量数据上报，使用UDP Telemetry；对于周期性的流量统计上报，可以使用IPFIX。51学通信认为，一个完整的随路遥测系统往往需要结合多种协议，不同协议承担不同的角色，协同工作才能实现完整的自动化能力。

总结

本文详细介绍了IPv6随路遥测的各种控制平面协议扩展机制。IGP扩展实现了能力信息在网络内部的扩散，是自动化部署的基础；BGP-LS扩展将能力信息上报给控制器，实现了集中式的智能分析；BGP SR Policy扩展将测量配置与路径配置同步下发，实现了真正的”零配置”部署；PCEP扩展提供了集中式的智能路径计算，适合复杂的多域网络场景。

这些协议扩展不是相互替代的关系，而是相互补充的关系。一个完整的随路遥测自动化系统往往需要结合多种协议，不同协议承担不同的角色。IGP扩展建立基础的信息扩散能力，BGP-LS扩展向上层提供信息，BGP SR Policy或PCEP负责配置的下发和维护。

控制平面协议扩展是随路遥测从”手动配置”走向”自动化部署”的关键技术。通过这些扩展，随路遥测可以在大规模网络中高效部署，真正发挥其技术价值。

下篇预告

下一篇我们将深入探讨IPv6随路遥测的实际部署方法与应用案例，带你了解IP RAN、高品质专线、金融广域网等场景的部署实践，以及控制器配置与故障排查的具体操作。

本文由”51学通信”（公众号：51学通信，站长：爱卫生）原创分享。如需深入交流或获取更多通信技术资料，欢迎添加微信：gprshome201101。

关系图谱