跳到主要内容

RFC 4379 - 1. Introduction

1. 引言 (Introduction)​

本文档描述一种简单, 高效的机制, 可用于检测多协议标签交换 (Multi-Protocol Label Switching, MPLS) 标签交换路径 (Label Switched Path, LSP) 中的数据平面故障. 本文档包含两部分: 在 MPLS "echo request" 与 "echo reply" 中携带的信息, 以及用于传送 echo reply 的机制. 第一部分旨在提供足够的信息以检查数据平面的正确运作, 并提供一种对照控制平面验证数据平面的机制, 从而定位故障. 第二部分为 echo request 消息提出两种可靠应答通道的方法, 以实现更稳健的故障隔离.

本设计中的一项重要考虑是, MPLS echo request 走的是普通 MPLS 分组会经过的同一条数据路径. MPLS echo request 主要用于验证数据平面, 其次用于对照控制平面验证数据平面. 用于检查控制平面的机制很有价值, 但不在本文档的讨论范围内.

本文档特别使用了 127/8 地址范围. 这是对 RFC 1122 [RFC1122] 所定义行为的一处例外, 并更新了该 RFC. 此项变更的动机以及这一例外用法的细节将在下文第 2.1 节中讨论.

1.1. 约定 (Conventions)​

本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" 和 "OPTIONAL" 按 RFC 2119 [KEYWORDS] 中的描述进行解释.

术语 "Must Be Zero" (MBZ) 在对象描述中用于保留字段. 这些字段在发送时 MUST 置零, 在接收时被忽略.

与 L2 和 L3 虚拟专用网络 (Virtual Private Network, VPN) 相关的术语定义于 [RFC4026].

由于本文档提及 MPLS 生存时间 (Time to Live, TTL) 的次数远多于 IP TTL, 作者采用的约定是: 不加限定的 "TTL" 表示 "MPLS TTL", 而 "IP TTL" 表示 IP 首部中的 TTL 值.

1.2. 文档结构 (Structure of This Document)​

本备忘录的正文包含四个主要部分: 动机, MPLS echo request/reply 分组格式, LSP ping 操作, 以及一条可靠的返回路径. 建议初次阅读的读者跳过具体的分组格式, 先阅读操作理论 (Theory of Operation); 本文档之所以这样组织, 是为了避免前向引用.

1.3. 贡献者 (Contributors)​

以下人员对本文档的各方面做出了重要贡献, 其中许多材料来自该小组内部的辩论与讨论.

  • Ronald P. Bonica, Juniper Networks, Inc.
  • Dave Cooper, Global Crossing
  • Ping Pan, Hammerhead Systems
  • Nischal Sheth, Juniper Networks, Inc.
  • Sanjay Wadhwa, Juniper Networks, Inc.