跳到主要内容

RFC 5462 - 多协议标签交换 (MPLS) 标签栈条目: "EXP" 字段重命名为 "Traffic Class" 字段

Network Working Group L. Andersson Request for Comments: 5462 Acreo AB Updates: 3032, 3270, 3272, 3443, 3469, R. Asati 3564, 3985, 4182, 4364, 4379, Cisco Systems 4448, 4761, 5129 February 2009 Category: Standards Track

    Multiprotocol Label Switching (MPLS) Label Stack Entry:
          "EXP" Field Renamed to "Traffic Class" Field

本备忘录的状态​

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

版权声明​

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

本文档受 BCP 78 以及 IETF Trust 在本文件发布之日有效的与 IETF 文档相关的法律条款 (http://trustee.ietf.org/license-info) 约束. 请仔细审阅这些文档, 因其描述了您对本文件的权利与限制.

摘要​

早期的多协议标签交换 (Multiprotocol Label Switching, MPLS) 文档定义了 MPLS 标签栈条目的格式. 其中包括一个称为 "EXP field" 的三位字段. 这些文档并未定义该字段的确切用途, 仅说明其 "reserved for experimental use" (保留用于实验用途).

尽管 EXP 字段的预期用途是作为 "Class of Service" (CoS) 字段, 但这些早期文档并未将其命名为 CoS 字段, 因为此类 CoS 字段的用法当时被认为尚未充分定义. 如今, 若干标准文档已将其用法定义为 CoS 字段.

为避免对该字段可如何使用产生误解, 越来越有必要重命名该字段. 本文档将该字段的名称更改为 "Traffic Class field" ("TC field"). 与此同时, 本文档还更新了定义 EXP 字段当前用法的文档.

目录​

  1. 引言
  2. 变更细节 2.1. RFC 3032 2.2. RFC 3270 2.3. RFC 5129 2.4. 本变更的范围
  3. TC 字段的使用
  4. 安全考虑
  5. 致谢
  6. 参考文献 6.1. 规范性引用 6.2. 资料性引用

1. 引言​

MPLS 标签栈条目的格式由 RFC 3032 [RFC3032] 定义, 其中包括一个称为 "EXP field" 的三位字段. RFC 3032 并未定义该字段的确切用途, 仅说明其 "reserved for experimental use" (保留用于实验用途).

从一开始, EXP 字段就被设计为承载 "Class of Service" (CoS) 信息. 在作为 RFC 3032 发布的工作组文档的早期版本中, 该字段实际上被称为 "Class of Service field". 然而, 在 RFC 3032 发布时, 该 "Class of Service" 字段的确切用法尚未达成一致, 因此该字段被指定为 "experimental use"; 自此以后名称一直是 "EXP field".

"for experimental use" 的指定导致其他标准制定组织 (Standards Development Organizations, SDO) 以及实现者假定该字段可用于其他目的. 本文档更改该字段的名称, 以明确表明其用作流量分类字段.

起初, 我们讨论过使用原来的 "CoS field" 作为该字段的名称, 但有人指出, 该名称无法涵盖自 RFC 3032 发布以来其用法所发生的下列变化.

  1. EXP 字段的用法首先在 RFC 3270 [RFC3270] 中定义, 其中规定了一种定义 Diffserv 标签交换路径 (Label Switched Path, LSP) 变体的方法, 称为 EXP-Inferred-PSC LSP (E-LSP). PSC 是一个两阶段缩写, 展开为 PHB (Per Hop Behavior) Scheduling Class (PSC).

  2. RFC 3270 中定义的 EXP 字段用法在 RFC 5129 [RFC5129] 中得到进一步扩展, 其中定义了在 MPLS 中进行显式拥塞标记的方法.

因此, 本文档使用名称 "Traffic Class field (TC field)", 它更好地涵盖了潜在用途. MPLS TC 字段与 MPLS 封装分组的关系, 与 IPv6 TC 字段与 IPv6 封装分组的关系, 或 IPv4 Precedence 字段与 IPv4 封装分组的关系相同.

RFC 3270 与 RFC 5129 中关于如何使用 EXP 字段的定义是完全清晰的. 然而, 这些 RFC 并未明确声明它们更新了 RFC 3032, 且直至本文档工作开始后, 该事实才被记入 RFC 仓库.

本文档更新 RFC 3032, RFC 3270 和 RFC 5129, 以澄清 TC 字段的预期用法. 对这些 RFC 的变更要求对其实际文本做一些修改; 第 2 节解释这些变更.

本文档还更新了若干其他 RFC; 见第 2.4 节. 对这些文档, 变更仅限于更改标签栈条目字段的名称.

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

2. 变更细节​

RFC 3032, 3270 和 5129 现根据下列内容予以更新.

2.1. RFC 3032​

RFC 3032 在第 4 页声明:

     3.  Experimental Use

     This three-bit field is reserved for experimental use.

该段现更改为:

     3.  Traffic Class (TC) field

     This three-bit field is used to carry traffic class information,
     and the change of the name is applicable to all places it occurs
     in IETF RFCs and other IETF documents.

     RFC 3270 and RFC 5129 update the definition of the TC field and
     describe how to use the field.

在 RFC 3032 第 3 页的图 1 中, 标签栈条目的格式规定为:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
|                Label                  | Exp |S|       TTL     | Stack
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry

                    Label:  Label Value, 20 bits
                    Exp:    Experimental Use, 3 bits
                    S:      Bottom of Stack, 1 bit
                    TTL:    Time to Live, 8 bits

                             Figure 1

RFC 3032 中的图 1 现更改为与更名为 TC 字段相一致:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
|                Label                  | TC  |S|       TTL     | Stack
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry

                    Label:  Label Value, 20 bits
                    TC:     Traffic Class field, 3 bits
                    S:      Bottom of Stack, 1 bit
                    TTL:    Time to Live, 8 bits

                              Figure 1 (new)

注意: 将上图标为 "Figure 1 (new)" 是为了在本文档中区分各图. 在 RFC 3032 中它仍将是 "Figure 1".

2.2. RFC 3270​

RFC 3270 在第 6 页写到:

1.2 EXP-Inferred-PSC LSPs (E-LSP)

   A single LSP can be used to support one or more OAs.  Such LSPs
   can support up to eight BAs of a given FEC, regardless of how many
   OAs these BAs span.  With such LSPs, the EXP field of the MPLS
   Shim Header is used by the LSR to determine the PHB to be applied
   to the packet.  This includes both the PSC and the drop
   preference.

   We refer to such LSPs as "EXP-inferred-PSC LSPs" (E-LSP), since
   the PSC of a packet transported on this LSP depends on the EXP
   field value for that packet.

   The mapping from the EXP field to the PHB (i.e., to PSC and drop
   precedence) for a given such LSP, is either explicitly signaled at
   label set-up or relies on a pre-configured mapping.

   Detailed operations of E-LSPs are specified in section 3 below.

RFC 3270 现按如下方式更新:

a. 在第 1 节 "Introduction" 末尾增加一段新段落:

       The EXP field has been renamed the TC field, and thus all
       references in RFC 3270 to the EXP field now refer to the TC
       field.

b. 在第 1.1 节 "Terminology" 中增加一个新术语:

       TC        Traffic Class (replaces the term EXP)

c. 在第 1.1 节 "Terminology" 中, 缩写 E-LSP 现理解为:

       E-LSP     Explicitly TC-encoded-PSC LSP

RFC 3270 第 6 页的第 1.2 节现更改为:

1.2 Explicitly TC-encoded-PSC LSPs (E-LSP)

   The EXP field has been renamed to the TC field, and thus all
   references in RFC 3270 to EXP field now refer to the TC field.
   However, we retain the acronym E-LSP (Explicitly TC-encoded-PSC
   LSP) as the acronym is in widespread use.

   A single LSP can be used to support one or more OAs.  Such LSPs
   can support up to eight BAs of a given FEC, regardless of how many
   OAs these BAs span.  With such LSPs, the TC field of the MPLS Shim
   Header is used by the LSR to determine the PHB to be applied to
   the packet.  This includes both the PSC and the drop preference.

   We refer to such LSPs as "Explicitly TC-encoded-PSC LSPs"
   (E-LSPs), since the PSC of a packet transported on this LSP
   depends on the TC field (previously called the EXP field) value
   for that packet.

   The mapping from the TC field to the PHB (i.e., to PSC and drop
   precedence) for a given such LSP is either explicitly signaled at
   label set-up or relies on a pre-configured mapping.

   This is an update to RFC 3032 [RFC3032], in line with the original
   intent of how this field in the MPLS Shim Header should be used
   (as a TC field).  RFC 3270 has itself been updated by RFC 5129
   [RFC5129].

   Detailed operations of E-LSPs are specified in Section 3 of RFC
   3270.

2.3. RFC 5129​

RFC 5129 现按如下方式更新:

在第 1.1 节 "Background" 末尾增加一段新段落:

   The EXP field has been renamed to the TC field, and thus all
   references in RFC 5129 to the EXP field now refer to the TC field.

RFC 5129 第 7 页第 2 节 (第 5 点) 写到:

o  A third possible approach was suggested by [Shayman].  In this
   scheme, interior LSRs assume that the endpoints are ECN-capable,
   but this assumption is checked when the final label is popped.  If
   an interior LSR has marked ECN in the EXP field of the shim
   header, but the IP header says the endpoints are not ECN-capable,
   the edge router (or penultimate router, if using penultimate hop
   popping) drops the packet.  We recommend this scheme, which we
   call `per-domain ECT checking', and define it more precisely in
   the following section.  Its chief drawback is that it can cause
   packets to be forwarded after encountering congestion only to be
   dropped at the egress of the MPLS domain.  The rationale for this
   decision is given in Section 8.1.

RFC 5129 第 2 节 (第 5 点) 现更新为:

o  A third possible approach was suggested by [Shayman].  In this
   scheme, interior LSRs assume that the endpoints are ECN-capable,
   but this assumption is checked when the final label is popped.  If
   an interior LSR has marked ECN in the TC field of the shim header,
   but the IP header says the endpoints are not TC-capable, the edge
   router (or penultimate router, if using penultimate hop popping)
   drops the packet.  We recommend this scheme, which we call `per-
   domain ECT checking', and define it more precisely in the
   following section.  Its chief drawback is that it can cause
   packets to be forwarded after encountering congestion only to be
   dropped at the egress of the MPLS domain.  The rationale for this
   decision is given in Section 8.1.  This scheme is an update to RFC
   3032 [RFC3032] and RFC 3270 [RFC3270].

2.4. 本变更的范围​

在被本文档明确更新的 RFC 中, 有多处引用 "Exp field", 有时称为 "Exp bits", "EXP bits" 或 "EXP". 在所有这些情形中, 这些引用现均指向 TC 字段.

还有其他 RFC (例如 RFC 3272 [RFC3272], RFC 3443 [RFC3443], RFC 3469 [RFC3469], RFC 3564 [RFC3564], RFC 3985 [RFC3985], RFC 4182 [RFC4182], RFC 4364 [RFC4364], RFC 4379 [RFC4379], RFC 4448 [RFC4448] 和 RFC 4761 [RFC4761]) 引用 "Exp field"; 有时称为 "Exp bits", "EXP bits" 和 "EXP". 对所有 RFC (包括但不限于本段提到的那些), 此类引用现均指向 TC 字段.

3. TC 字段的使用​

由于 TC 字段中的位数有限, 其用于 QoS 和 ECN (Explicit Congestion Notification) 功能的意图是保持灵活. 这些功能可能重写 TC 字段中的全部或部分位.

当前实现会在有无标签上下文的情况下查看 TC 字段, 并且 TC 字段可能被复制到压入标签栈的标签栈条目中. 这样做是为了避免压入既有标签栈的标签栈条目与其余标签栈条目具有不同的 TC 字段.

4. 安全考虑​

本文档仅更改 MPLS shim 头中一个字段的名称, 因此不引入任何新的安全考虑.

5. 致谢​

作者感谢 Stewart Bryant, Bruce Davie, George Swallow 和 Francois Le Faucheur 对当前文档的输入与审阅.

作者还感谢 George Swallow, Khatri Paresh 和 Phil Bedard 在语法与拼写方面的帮助; 特别感谢 Adrian Farrel 仔细审阅并帮助在 RFC 之海中搜寻引用 EXP 字段的 RFC.

6. 参考文献​

6.1. 规范性引用​

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

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

[RFC3270] 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.

[RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002.

[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003.

[RFC3469] Sharma, V. and F. Hellstrand, "Framework for Multi- Protocol Label Switching (MPLS)-based Recovery", RFC 3469, February 2003.

[RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003.

[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture", RFC 3985, March 2005.

[RFC4182] Rosen, E., "Removing a Restriction on the use of MPLS Explicit NULL", RFC 4182, September 2005.

[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.

[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.

[RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.

[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007.

[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion Marking in MPLS", RFC 5129, January 2008.

6.2. 资料性引用​

[Shayman] Shayman, M. and R. Jaeger, "Using ECN to Signal Congestion Within an MPLS Domain", Work in Progress, November 2000.

作者地址​

Loa Andersson
Acreo AB

EMail: [email protected]

Rajiv Asati
Cisco Systems

EMail: [email protected]

最后于 更新