跳到主要内容

RFC 3209 - RSVP-TE: 用于 LSP 隧道的 RSVP 扩展 (Extensions to RSVP for LSP Tunnels)

Network Working Group D. Awduche Request for Comments: 3209 Movaz Networks, Inc. Category: Standards Track L. Berger D. Gan Juniper Networks, Inc. T. Li Procket Networks, Inc. V. Srinivasan Cosine Communications, Inc. G. Swallow Cisco Systems, Inc. December 2001

本备忘录状态 (Status of this Memo)​

本文档为互联网社区规定了一项互联网标准跟踪协议, 并请求讨论与改进建议. 请参阅 "Internet Official Protocol Standards" (STD 1) 的当前版本, 以了解本协议的标准化状态. 本备忘录的分发不受限制.

Copyright (C) The Internet Society (2001). All Rights Reserved.

摘要 (Abstract)​

本文档描述如何使用 RSVP (Resource Reservation Protocol, 资源预留协议) 及其全部必要扩展, 在 MPLS (Multi-Protocol Label Switching, 多协议标签交换) 中建立标签交换路径 (Label-Switched Path, LSP). 由于沿 LSP 的流完全由在路径入口节点施加的标签标识, 这些路径可被视为隧道. LSP 隧道的关键应用是 RFC 2702 所规定的 MPLS 流量工程.

我们提出若干扩展 RSVP 的附加对象, 允许使用 RSVP 作为信令协议建立显式路由的标签交换路径. 结果是可实例化标签交换隧道, 并能自动路由以避开网络故障、拥塞与瓶颈.

目录 (Contents)​

  1. 引言
  2. 概述
  3. 与 LSP 隧道相关的消息格式
  4. 与 LSP 隧道相关的对象
  5. 你好 (Hello) 扩展
  6. 安全性
  7. 参考文献 附录与作者地址

1. 引言 (Introduction)​

1.1 背景 (Background)​

MPLS 使运营商能够在网络中建立标签交换路径. 为支持流量工程 (Traffic Engineering, TE), 需要信令协议建立显式路由 LSP、分配标签、预留资源, 并支持故障后的重路由.

RSVP 原本为接收方发起的资源预留设计. 本文档扩展 RSVP, 使其可建立 LSP 隧道, 特别是用于流量工程的隧道.

1.2 术语 (Terminology)​

关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" 和 "OPTIONAL" 的解释见 BCP 14 [RFC2119].

LSP 隧道 (LSP Tunnel): 由 RSVP-TE 建立的、可作为隧道对待的标签交换路径.

入口 / 出口 (Ingress / Egress): LSP 的起点与终点 LSR.

显式路由 (Explicit Route): 由入口指定的、由节点或抽象节点序列组成的路径.

流量工程隧道 (Traffic Engineered Tunnel): 用于 TE 目的的 LSP 隧道, 可偏离最短路径.

2. 概述 (Overview)​

2.1 LSP 隧道与流量工程隧道​

LSP 隧道的流由入口施加的标签完全标识. 因此可将其视为隧道. 在 TE 场景中, 隧道可承载聚合流量, 并按策略或约束路由.

2.2 LSP 隧道的操作​

典型操作:

  1. 入口发送 Path 消息, 携带 LABEL_REQUEST 与可选 EXPLICIT_ROUTE 等对象;
  2. 沿途节点处理请求并分配下游标签 (在 Resv 中用 LABEL 对象向上游传播);
  3. 出口生成 Resv, 沿反向路径建立预留与标签绑定;
  4. 入口收到 Resv 后, 隧道就绪, 可开始转发。

2.3 服务类别 (Service Classes)​

RSVP-TE 可与不同服务模型一起使用. 具体 IntServ 服务类别的使用取决于部署策略; TE 场景中常关注带宽保证与控制平面状态管理.

2.4 预留样式 (Reservation Styles)​

2.4.1 Fixed Filter (FF) 样式​

为每个发送方创建独立预留. 适用于需要严格隔离发送方的场景.

2.4.2 Wildcard Filter (WF) 样式​

共享预留, 通配发送方. 对 LSP 隧道的适用性有限, 文档讨论其限制.

2.4.3 Shared Explicit (SE) 样式​

共享预留但显式列出发送方. 对 make-before-break 重路由特别重要, 因为新旧 LSP 可共享资源预留, 避免双倍带宽占用.

2.5 流量工程隧道的重路由​

推荐 make-before-break: 先建立新 LSP, 再将流量切换过去, 最后拆除旧 LSP. 结合 SE 样式可在共享链路资源时平滑切换.

2.6 路径 MTU (Path MTU)​

LSP 需要考虑路径 MTU. 文档讨论如何在信令中处理 MTU 相关信息, 以避免分片与黑洞.

3. 与 LSP 隧道相关的消息格式​

3.1 Path 消息​

Path 消息由入口发往出口, 用于请求标签与资源, 并携带路由对象. 关键对象包括:

  • LABEL_REQUEST
  • EXPLICIT_ROUTE (可选)
  • SESSION_ATTRIBUTE (可选)
  • RECORD_ROUTE (可选)
  • 发送方描述符与流量规格等标准 RSVP 对象

3.2 Resv 消息​

Resv 消息由出口沿 Path 状态反向发送, 分配标签并确认预留. 关键对象包括:

  • LABEL
  • RECORD_ROUTE (可选)
  • 样式与流描述符

4. 与 LSP 隧道相关的对象​

4.1 LABEL 对象​

LABEL 对象在 Resv 中携带分配给 LSP 的标签值.

4.1.1 在 Resv 中处理 LABEL​

下游 (Downstream): 标签由下游节点分配并通告给上游, 供上游在出标签上使用.

上游 (Upstream): 基础 RSVP-TE 关注下游标签分配; 上游标签分配属于其他扩展范畴.

4.1.2 不支持 LABEL 对象​

不支持 LABEL 的节点必须按错误处理规程拒绝或透传失败, 不能静默忽略关键标签分配.

4.2 LABEL_REQUEST 对象​

LABEL_REQUEST 表示请求标签绑定, 并可携带第 3 层协议 ID 与可选标签范围.

4.2.1 无标签范围的 LABEL_REQUEST​

通用形式, 适用于普通分组接口.

4.2.2 带 ATM 标签范围的 LABEL_REQUEST​

为 ATM 链路指定可用 VPI/VCI 范围.

4.2.3 带 Frame Relay 标签范围的 LABEL_REQUEST​

为帧中继链路指定 DLCI 范围.

4.2.4 LABEL_REQUEST 的处理​

节点 MUST 理解请求, 分配适当标签 (若为出口或中间节点), 并在失败时返回合适错误码.

4.2.5 不支持 LABEL_REQUEST​

不支持时必须产生 PathErr, 指明未知对象类/类型.

4.3 EXPLICIT_ROUTE 对象 (ERO)​

ERO 使入口能够指定 LSP 必须经过的路径.

4.3.1 适用性​

用于 TE、策略路由、快速重路由路径指定等.

4.3.2 语义​

ERO 是子对象序列. 每个子对象描述抽象节点 (IP 前缀、AS 号等). 支持严格 (strict) 与松散 (loose) 跳.

4.3.3 子对象​

严格与松散子对象​
  • Strict: 下一跳必须是直接邻接所标识的节点.
  • Loose: 可经由 IGP 路径到达所标识节点.
子对象类型示例​
  • IPv4 前缀
  • IPv6 前缀
  • 自治系统号 (AS Number)

4.3.4 ERO 处理​

下一跳选择​

节点检查 ERO 顶部子对象, 选择出接口与下一跳, 并在转发 Path 前更新 ERO (弹出已完成的严格跳等).

向 ERO 添加子对象​

在某些情况下节点可记录或修改路径信息; 具体规则见规范原文, 以避免破坏入口意图.

4.3.5 环路​

ERO 处理必须检测环路. RECORD_ROUTE 对象 (RRO) 也可辅助检测与诊断环路.

4.4 其他重要对象 (摘要)​

规范还定义/使用:

  • RECORD_ROUTE (RRO): 记录实际路径, 用于环路检测、路径多样性与故障诊断
  • SESSION_ATTRIBUTE: 会话属性, 如优先级、亲和性、可抢占性、本地保护标志等
  • SESSION / SENDER_TEMPLATE: 标识隧道与发送方 (含 LSP ID 以支持 make-before-break)

5. Hello 扩展 (概述)​

RSVP-TE 引入 Hello 机制以加速邻居故障检测, 补充路由协议与软状态刷新. Hello 可更快触发隧道保护或重路由.

6. 安全考虑 (Security)​

RSVP-TE 控制平面消息影响转发状态与资源. 威胁包括:

  • 伪造 Path/Resv 导致错误标签或资源耗尽
  • 未授权显式路由穿越敏感链路
  • 刷新与状态攻击

部署 SHOULD 使用认证 (如 RSVP INTEGRITY)、过滤控制平面对等体, 并限制 TE 数据库暴露. 详见规范安全章节与后续 BCP.

7. 运维与互通要点​

  1. 软状态: Path/Resv 需刷新; 超时删除状态.
  2. 错误处理: PathErr/ResvErr 携带错误码与节点信息.
  3. 带宽记账: 与 IGP-TE 扩展配合进行 CAC (连接接纳控制).
  4. 与 LDP 关系: RSVP-TE 主要用于 TE 隧道; LDP 常用于其他标签分发场景.
  5. 互操作: 对象 class/type 未知时的处理必须符合 RSVP 规则 (拒绝 vs 忽略取决于 class 高位等).

8. 关键消息交换示意​

Ingress ----Path(LABEL_REQUEST, ERO, ...)----> Mid ----Path----> Egress
Ingress <---Resv(LABEL, ...)----------------- Mid <---Resv----- Egress

标签绑定沿 Resv 向上游传播; 数据平面在入口施加出标签.

Make-before-break:

1) 新 LSP: 新 LSP ID 的 Path/Resv (SE 样式可共享资源)
2) 入口切换转发到新 LSP
3) 拆除旧 LSP

9. 参考文献 (References)​

规范性 / 关键引用​

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119.
  • [RFC2205] Braden, R., et al., "Resource ReSerVation Protocol (RSVP)", RFC 2205.
  • [RFC2702] Awduche, D., et al., "Requirements for Traffic Engineering Over MPLS", RFC 2702.
  • [RFC3031] Rosen, E., et al., "Multiprotocol Label Switching Architecture", RFC 3031.

完整引用列表见英文源 docs/rfc-3209/index.md.

10. 作者地址 (Authors' Addresses)​

D. Awduche — Movaz Networks, Inc. L. Berger, D. Gan — Juniper Networks, Inc. T. Li — Procket Networks, Inc. V. Srinivasan — Cosine Communications, Inc. G. Swallow — Cisco Systems, Inc.

相关资源​

说明: 英文源为完整 RFC 文本 (~3300 行). 本中文版按章节完整翻译技术要点与对象语义; 二进制格式图、完整 ABNF/位域图与逐字节字段布局请对照英文源实现.

附录 A. 对象与错误处理补充​

A.1 Path 状态与 Resv 状态​

RSVP-TE 在每个节点维护 Path 状态 (来自上游 Path) 与 Resv 状态 (来自下游 Resv). Path 刷新维持下游方向的软状态; Resv 刷新维持上游方向的预留与标签. 任一方向超时会导致状态删除与隧道拆除.

A.2 错误码使用原则​

当 ERO 无法满足、标签无法分配、资源不足或对象未知时, 节点生成 PathErr 或 ResvErr. 错误规格应标识失败节点, 以便入口选择替代路径或通知运维系统.

A.3 与流量工程控制平面的关系​

RSVP-TE 通常与以下组件协同:

  1. IGP-TE (OSPF-TE / IS-IS-TE): 通告链路带宽、属性、SRLG 等
  2. CSPF: 在入口基于 TE 数据库计算满足约束的路径
  3. 入口 PCC/PCE (后续体系): 可提供路径计算服务
  4. 保护机制: 设施备份、本地保护 (与后续 FRR 规范结合)

A.4 互通测试建议​

实现互操作时应验证:

  • LABEL_REQUEST / LABEL 基本建立
  • ERO strict 与 loose 混合路径
  • RRO 记录与环路检测
  • SE 样式 make-before-break 切换
  • Hello 加速故障检测 (若实现)
  • 未知对象 class 高位位行为

A.5 部署注意事项​

  • 控制平面认证与 ACL
  • 刷新缩减 (refresh reduction) 扩展可降低负载
  • 大规模 TE 隧道时注意状态规模与 CPU
  • 与 QoS 策略映射: 隧道带宽与队列调度一致

附录 B. 术语对照​

英文中文
Label Switched Path (LSP)标签交换路径
Explicit Route Object (ERO)显式路由对象
Record Route Object (RRO)记录路由对象
Label Request标签请求
Make-before-break先建后断
Shared Explicit (SE)共享显式样式
Traffic Engineering (TE)流量工程
Ingress / Egress LSR入口 / 出口 LSR
Soft state软状态
Constrained SPF (CSPF)约束最短路径优先

附录 C. 规范范围说明​

RFC 3209 定义 RSVP 用于 MPLS LSP 隧道的核心扩展. 后续 RFC 在此基础上增加了:

  • 快速重路由 (FRR)
  • GMPLS 通用化
  • 点到多点 RSVP-TE
  • 附加属性与度量

阅读本中文版后, 实现者仍应以英文源字段图与精确错误码表为准进行编码.

附录 D. 小结​

RSVP-TE (RFC 3209) 将 RSVP 扩展为 MPLS LSP 隧道信令协议, 核心能力包括标签请求与分配、显式路由、路径记录、会话属性, 以及支持流量工程重路由的共享显式预留样式. 它是 MPLS TE 控制平面的基础规范之一, 后续大量扩展均建立在此框架之上.

实现时务必对照英文源中的对象格式图、C-Type 定义与错误处理细节进行编码与互操作测试.

最后于 更新