多协议标签交换 (MPLS) 网络中的生存时间 (TTL) 处理

发布时间:2022-02-16 13:50:06 作者:V小编阅读:0

[导读]:RFC3443:Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks,January 2003...

RFC3443:Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks,January 2003

本备忘录的状态

本文档为 Internet 社区指定了 Internet 标准跟踪协议,并请求讨论和改进建议。本协议的标准化状态和现状请参考当前版本的《互联网官方协议标准》(STD 1)。本备忘录的分发不受限制。

版权声明

版权所有 (C) 互联网协会 (2003)。版权所有。

梗概

本文档描述了分层多协议标签交换 (Multi-Protocol Label Switching,MPLS) 网络中的生存时间 (Time To Live,TTL) 处理,其动机是为了将 MPLS 标签交换路径的 TTL 透明操作模式形式化。它更新了 RFC 3032-“MPLS 标签栈编码”(MPLS 标签栈编码)。管道和统一模型分层隧道中的 TTL 处理均通过“压入”和“弹出”情况的示例指定。该文件还补充了 RFC 3270,“MPLS 对差异化服务的支持”,并将该文件中引入的术语与分层 MPLS 网络中的 TTL 处理联系在一起。

本文档中使用的约定

本文档中的关键词“必须”、“不得”、“需要”、“应该”、“不应”、“应该”、“不应该”、“推荐”、“可以”和“可选”是解释为 [RFC-2119] (在 RFC 中用于表示需求级别的关键词)中的描述。

1、 介绍和动机

本文档描述分层 MPLS 网络中的生存时间 (TTL) 处理。我们相信本文档添加了 [MPLS-ARCH(MPLS:多协议标签交换架构), MPLS-ENCAPS] 中未解决的细节,并且本文档中介绍的方法补充了 [MPLS-DS]。

特别是,引入了一种新的操作模式(称为管道模型)来支持配置 MPLS LSP 的做法,以便通过 LSP 的数据包将隧道视为单跳,而不管中间标签交换路由器 (label switch routers,LSR) 的数量如何。TTL 管道模型目前正在多个网络中使用,并作为网络运营商可配置的选项提供给多个供应商。

本文档将 MPLS 网络中的 TTL 处理形式化,并将其与 [MPLS-DS] 中引入的术语联系起来。

2、 MPLS 网络中的 TTL 处理

2.1、 对 RFC 3032 [MPLS-ENCAPS] 的更改

a) [MPLS-ENCAPS] 仅涵盖统一模型,不涉及管道模型或短管道模型。本文档介绍了这两种模型,并且为了完整起见,还将介绍统一模型。

b) [MPLS-ENCAPS] 不包括分层 LSP。本文档解决了这个问题。

c) [MPLS-ENCAPS] 没有定义存在倒数第二跳弹出 (Penultimate Hop Popping,PHP) 时的 TTL 处理。本文档解决了这个问题。

2.2、 术语和背景

如 [MPLS-ENCAPS] 中所定义,MPLS 数据包使用 MPLS shim 标头,指示有关数据包的以下信息:

a) MPLS 标签(20 位)

b) TTL      (8 位)

c) 栈底     (1 位)

d) 实验位   (3 位)

实验位后来在 [MPLS-DS] 中重新定义,以指示可能与 MPLS 数据包相关联的调度和整形行为。

[MPLS-DS] 还为 MPLS 隧道操作定义了两种模型:管道模型和统一模型。在管道模型中,当 MPLS 数据包穿过网络时,MPLS 网络就像一个电路,这样隧道外的节点只能看到 LSP 入口和出口点。[MPLS-DS] 中还定义了管道模型的短变体,以区分不同的出口转发和 QoS 处理。另一方面,统一模型使 LSP 遍历的所有节点对隧道外的节点可见。我们将在以下部分扩展管道和统一模型以包括 TTL 处理。此外,本文档还描述了执行 PHP 时的 TTL 处理。有关管道和均匀模型的详细说明,请参阅 [MPLS-DS]。

MPLS 网络中的 TTL 处理可以分解为两个逻辑块:

(i) 传入 TTL 确定以考虑由于 MPLS Pop 操作引起的任何隧道出口;

(ii)(可能)暴露的数据包和传出的 TTL 的数据包处理。

我们还注意到,LSP 类型(管道、短管道或统一模型)的信令超出了本文档的范围,并且在当前版本的标签分发协议中也没有解决,例如LDP [MPLS-LDP] 和 RSVP-TE [MPLS-RSVP]。目前,LSP 类型由网络运营商通过命令行或网络管理界面手动配置。

2.3、 新术语

iTTL:incoming TTL,用作传入 TTL 的 TTL 值。不对 iTTL 执行任何检查。

oTTL:outgoing TTL,这是用作传出 TTL 值的 TTL 值(有关例外情况,请参见第 3.5 节)。除非另有说明,否则它始终为 (iTTL - 1)。

oTTL Check:检查oTTL 是否大于0。如果oTTL Check 为false,则不转发数据包。请注意,仅当任何传出 TTL(IP 或 MPLS)设置为 oTTL 时才执行 oTTL 检查(有关例外情况,请参阅第 3.5 节)。

3、 不同模型中的TTL处理

本节描述了在存在/不存在 PHP(如果适用)的情况下对符合 3 个模型(统一、短管道和管道)中的每一个的 LSP 的 TTL 处理。

3.1、 统一模型 LSP 的 TTL 处理(有或没有 PHP)

(与 [MPLS-ENCAPS] 一致):

多协议标签交换 (MPLS) 网络中的生存时间 (TTL) 处理

(n) 表示对应头部中的TTL值

(x) 代表无意义的 TTL 信息

(I) 代表 LSP 入口节点

(P) 代表 LSP 倒数第二个节点

(E) 代表 LSP Egress 节点

此图显示了统一模型 MPLS LSP 的 TTL 处理。请注意,数据包的内部和外部 TTL 在隧道入口和出口处同步。

3.2、 短管道模型 LSP 的 TTL 处理

3.2.1、 没有 PHP 的短管道模型 LSP 的 TTL 处理

多协议标签交换 (MPLS) 网络中的生存时间 (TTL) 处理

(N) 代表TTL值(可能与n没有关系)

(n) 表示封装报头中的隧道 TTL 值

(I) 代表 LSP 入口节点

(E) 代表 LSP Egress 节点

在[MPLS-DS]中引入了短管模型。在短管道模型中,出口 LSR 的转发处理基于隧道数据包,而不是封装数据包。

3.2.2、 使用 PHP 对短管道模型的 TTL 处理

多协议标签交换 (MPLS) 网络中的生存时间 (TTL) 处理

(N) 代表TTL值(可能与n没有关系)

(n) 表示封装报头中的隧道 TTL 值

(I) 代表 LSP 入口节点

(P) 代表 LSP 倒数第二个节点

(E) 代表 LSP 出口节点。

由于标签已经被 LSP 的倒数第二个节点弹出,LSP 出口节点只是递减标头 TTL。

另请注意,在 Short Pipe Model LSP 的末尾,隧道数据包的 TTL 已减 2,无论是否使用 PHP。

3.3、 管道模型 LSP 的 TTL 处理(仅不含 PHP)

多协议标签交换 (MPLS) 网络中的生存时间 (TTL) 处理

(N) 代表TTL值(可能与n没有关系)

(n) 表示封装报头中的隧道 TTL 值

(I) 代表 LSP 入口节点

(E) 代表 LSP Egress 节点

从 TTL 的角度来看,管道模型 LSP 的处理与没有 PHP 的短管道模型相同。

3.4、 传入 TTL (iTTL) 确定

如果传入数据包是 IP 数据包,则 iTTL 是传入 IP 数据包的 TTL 值。

如果传入的数据包是 MPLS 数据包并且我们正在执行 Push/Swap/PHP,则 iTTL 是最顶层传入标签的 TTL。

如果传入的数据包是 MPLS 数据包并且我们正在执行 Pop(隧道端点),则 iTTL 基于被弹出的 LSP 的隧道类型(管道或统一)。如果弹出的标签属于管道模型 LSP,则 iTTL 是标头的 TTL 字段的值,在标签弹出后公开(注意,就本文档而言,公开的标头可能是 IP 标头或 MPLS 标签)。如果弹出的标签属于统一模型 LSP,则 iTTL 等于弹出标签的 TTL。如果连续执行多个弹出操作,则重复上面给出的过程,但有一个例外:上次弹出时计算的 iTTL 用作后续弹出标签的 TTL;即包含在后续标签中的 TTL 基本上被忽略并替换为在前一个 pop 期间计算的 iTTL。

3.5、 传出 TTL 确定和数据包处理

在进行 iTTL 计算后,进行 oTTL 检查。如果 oTTL 检查成功,则计算(标记/未标记)数据包的传出 TTL,并按如下定义更新数据包标头。

如果数据包作为 IP 数据包路由,则 IP 数据包的 TTL 值设置为 oTTL (iTTL - 1)。任何压入标签的 TTL 值如第 3.6 节所述确定。

对于作为 MPLS 路由的数据包,我们有四种情况:

1) Swap-only:路由标签与另一个标签交换,出标签的TTL字段设置为oTTL。

2) 交换后压入:交换操作如 (1) 中所述执行。任何压入标签的 TTL 值都按照第 3.6 节中的描述确定。

3) Penultimate Hop Pop (PHP):弹出路由标签。无论是否使用 oTTL 更新传出标头的 TTL 字段,都应执行 oTTL 检查。如果 PHPed 标签属于短管道模型 LSP,则 PHP 公开标头的 TTL 字段既不会检查也不会更新。如果 PHPed 标签是 Uniform Model LSP,则 PHP 公开标头的 TTL 字段设置为 oTTL。附加标签的 TTL 值如第 3.6 节所述确定。

4) Pop:pop 操作发生在路由之前,因此这里不考虑。

3.6、 隧道入口处理(压入)

对于每个压入的统一模型标签,TTL 是从其正下方的标签/IP 数据包中复制的。

对于每个压入的管道模型或短管道模型标签,TTL 字段设置为网络运营商配置的值。在大多数实现中,该值默认设置为 255。

3.7、 实施备注

1) 虽然iTTL可以在更新或正在确定oTTL时递减大于1的值,但该功能应该仅用于补偿无法递减TTL值的网络节点。

2) 每当 iTTL 递减时,实施者必须确保该值不会变为负数。

3) 在启用PHP的Short Pipe Model中,PHP操作后隧道包的TTL不变。

4、 结论

该 Internet 文档描述了如何在 MPLS 网络中处理 TTL 字段。我们阐明了在存在分层隧道的情况下应用的各种方法,并完成了管道和统一模型与 TTL 处理的集成。

5、 安全考虑

除了在[MPLS-ENCAPS, MPLS-DS]中定义的问题之外,本文件没有增加任何新的安全问题。特别是,该文件没有定义新协议或扩展现有协议,也没有将安全问题引入现有协议。作者认为,MPLS 网络中 TTL 处理的澄清有利于服务提供商及其客户,因为故障排除得以简化。

6、 参考文献

6.1、 规范参考

[RFC-2119] Bradner, S. "Key words for use in RFC's to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[MPLS-ARCH] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.

[MPLS-ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.

[MPLS-DS] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P. and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.

6.2、 参考资料

[MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001.

[MPLS-RSVP] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.

7、 致谢

作者要感谢 MPLS 工作组成员的反馈。我们要特别感谢 Shahram Davari 和 Loa Andersson 对文件的仔细审阅和他们的意见。

8、 完整的版权声明

版权所有 (C) 互联网协会 (2003)。版权所有。

本文件及其译文可能会被复制和提供给他人,并且可以全部或部分地准备、复制、出版和分发对其进行评论或以其他方式解释或协助其实施的衍生作品,不受任何限制,前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是,不得以任何方式修改本文档本身,例如通过删除版权声明或对 Internet 协会或其他 Internet 组织的引用,除非出于制定 Internet 标准的需要,在这种情况下,版权程序定义在必须遵循 Internet 标准流程,或按照要求将其翻译成英语以外的语言。

上述授予的有限权限是永久性的,不会被互联网协会或其继任者或受让人撤销。

本文档和其中包含的信息按“原样”提供,互联网协会和互联网工程工作队不提供所有明示或暗示的保证,包括但不限于任何保证,即使用此处的信息不会侵犯任何有关适销性或特定用途适用性的权利或任何默示保证。

致谢

RFC 编辑器功能的资金目前由互联网协会提供。

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:sales@vecloud.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

标题:多协议标签交换 (MPLS) 网络中的生存时间 (TTL) 处理

TAG标签:MPLS

地址:http://www.kd010.com/hyzs/667.html

上一篇:租用海外主机能否掀起下一波企业数字化浪潮?
下一篇:外贸独立站英文网站如何搭建,网站建设有什么技巧

Vecloud云网络解决方案

点击获取方案