Network Working Group P. Calhoun
Request for Comments: 3308 Black Storm Networks
Category: Standards Track W. Luo
Cisco Systems, Inc.
D. McPherson
TCB
K. Peirce
Malibu Networks, Inc.
November 2002
Network Working Group P. Calhoun
Request for Comments: 3308 Black Storm Networks
Category: Standards Track W. Luo
Cisco Systems, Inc.
D. McPherson
TCB
K. Peirce
Malibu Networks, Inc.
November 2002
Layer Two Tunneling Protocol (L2TP) Differentiated Services Extension
第二层隧道协议（L2TP）区分服务扩展
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document describes mechanisms which enable the Layer Two Tunneling Protocol (L2TP) to negotiate desired Per Hop Behavior (PHB) code for the L2TP control connection, as well as individual sessions within an L2TP tunnel.
本文档描述了使第二层隧道协议（L2TP）能够协商L2TP控制连接所需的每跳行为（PHB）代码以及L2TP隧道内的各个会话的机制。
L2TP provides a standard method for tunneling PPP packets. The current specification provides no provisions for supporting Differentiated Services (diffserv) over the L2TP control connection or subsequent data sessions. As a result, no standard mechanism currently exists within L2TP to provide L2TP protocol negotiations for service discrimination.
L2TP提供了隧道PPP数据包的标准方法。当前规范未提供通过L2TP控制连接或后续数据会话支持区分服务（diffserv）的规定。因此，L2TP中目前没有标准机制为服务歧视提供L2TP协议协商。
Table of Contents
目录
1. Specification of Requirements ............................... 2
2. Introduction ................................................ 2
3. Control Connection Operation ................................ 3
3.1. Control Connection DS AVP (SCCRQ, SCCRP) .................... 4
4. Session Operation ........................................... 4
4.1. Session DS AVP (ICRQ, ICRP, OCRQ, OCRP) ..................... 6
5. DS AVPs Correlation ......................................... 6
6. PHB Encoding ................................................ 6
7. DSCP Selection .............................................. 7
8. Packet Reordering and Sequence Numbers ...................... 7
9. Crossing Differentiated Services Boundaries ................. 7
10. IANA Considerations ......................................... 8
11. Security Considerations ..................................... 8
12. Acknowledgements ............................................ 8
13. References .................................................. 8
14. Authors' Addresses .......................................... 9
15. Full Copyright Statement .................................... 10
1. Specification of Requirements ............................... 2
2. Introduction ................................................ 2
3. Control Connection Operation ................................ 3
3.1. Control Connection DS AVP (SCCRQ, SCCRP) .................... 4
4. Session Operation ........................................... 4
4.1. Session DS AVP (ICRQ, ICRP, OCRQ, OCRP) ..................... 6
5. DS AVPs Correlation ......................................... 6
6. PHB Encoding ................................................ 6
7. DSCP Selection .............................................. 7
8. Packet Reordering and Sequence Numbers ...................... 7
9. Crossing Differentiated Services Boundaries ................. 7
10. IANA Considerations ......................................... 8
11. Security Considerations ..................................... 8
12. Acknowledgements ............................................ 8
13. References .................................................. 8
14. Authors' Addresses .......................................... 9
15. Full Copyright Statement .................................... 10
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC 2119]中所述进行解释。
The L2TP specification currently provides no mechanism for supporting diffserv (DS). This document describes mechanisms that enable L2TP to indicate desired PHB code, as defined in [RFC 3140], to be associated with an L2TP control connection, as well as individual sessions within an L2TP tunnel.
L2TP规范目前没有提供支持区分服务（DS）的机制。本文档描述了使L2TP能够指示[RFC 3140]中定义的与L2TP控制连接关联的所需PHB代码的机制，以及L2TP隧道中的各个会话。
The actual bit interpretation of the DS field is beyond the scope of this document, and is purposefully omitted. This document is concerned only with defining a uniform exchange and subsequent mapping mechanism for the DS AVPs.
DS字段的实际位解释超出了本文档的范围，有意省略。本文档仅涉及为DS AVP定义统一交换和后续映射机制。
As defined in [RFC 2661], a control connection operates in-band over a tunnel to control the establishment, release, and maintenance of sessions and of the tunnel itself. As such, this document provides a mechanism to enable discrimination of L2TP control messages from other packets. For this purpose, we introduce the Control Connection DS (CCDS) AVP.
如[RFC 2661]中所定义，控制连接在隧道上的频带内运行，以控制会话和隧道本身的建立、释放和维护。因此，本文档提供了一种机制，用于区分L2TP控制消息与其他数据包。为此，我们引入了控制连接DS（CCDS）AVP。
The presence of the CCDS AVP serves as an indication to the peer (LAC or LNS) that the tunnel initiator wishes both the tunnel initiator and terminator to use the per-hop behavior(s) (PHB(s)) indicated by the AVP's PHB code for all packets within the tunnel's control connection. A PHB is a description of the externally observable forwarding behavior of a DS node applied to a particular DS behavior aggregate, as defined in [RFC 2475]. The most simple example of a PHB is one which guarantees a minimal bandwidth allocation of a link to a behavior aggregate.
CCDS AVP的存在用作向对等方（LAC或LNS）指示隧道发起方希望隧道发起方和终止方对隧道的控制连接内的所有分组使用由AVP的PHB代码指示的每跳行为（PHB）。PHB是应用于特定DS行为聚合的DS节点的外部可观察转发行为的描述，如[RFC 2475]中所定义。PHB最简单的例子是保证将链路分配到行为聚合的带宽最小化。
Upon receipt of a Start-Control-Connection-Request (SCCRQ) containing the CCDS AVP, if the tunnel terminator provides no support for the CCDS AVP it MUST ignore the AVP and send an SCCRP to the tunnel initiator without the CCDS AVP. The tunnel initiator interprets the absence of the CCDS AVP in the SCCRP as an indication that the tunnel terminator is incapable of supporting CCDS.
在收到包含CCDS AVP的启动控制连接请求（SCCRQ）后，如果隧道终止程序不支持CCDS AVP，则必须忽略AVP，并在不使用CCDS AVP的情况下向隧道启动器发送SCCRP。隧道发起者将SCCRP中缺少CCD AVP解释为隧道终止器无法支持CCD的指示。
Upon receipt of an SCCRP that contains no CCDS AVP in response to a SCCRQ that contained a CCDS AVP, if the tunnel initiator wants to continue tunnel establishment it sends an SCCCN. Otherwise, it sends a StopCCN to the tunnel terminator to end the connection. The StopCCN control message MUST contain the Result Code 8 that indicates CCDS AVP value (47) as the reason for sending the StopCCN.
在收到不包含CCDS AVP的SCCRP以响应包含CCDS AVP的SCCRQ时，如果隧道发起方希望继续建立隧道，则发送SCCCN。否则，它将向隧道终端发送StopCCN以结束连接。StopCCN控制消息必须包含结果代码8，该代码指示CCDS AVP值（47）作为发送StopCCN的原因。
If the tunnel terminator provides support for CCDS, it SHOULD use the Host Name AVP embedded in SCCRQ to consult its local policy, and to determine whether local policy permits the requested PHB code to be used on this control connection. If it is unwilling or unable to support the requested PHB code after consulting the local policy, the tunnel terminator MUST send an SCCRP control message containing a CCDS AVP indicating the value it is willing to use. If the CCDS AVP value is the same as the one in the SCCRQ, it signals the acceptance of the requested PHB code. If the value is different it serves as a counter-offer by the tunnel terminator.
如果隧道终端提供对CCD的支持，则应使用SCCRQ中嵌入的主机名AVP来咨询其本地策略，并确定本地策略是否允许在该控制连接上使用请求的PHB代码。如果在咨询当地政策后不愿意或无法支持请求的PHB代码，则隧道终止器必须发送包含CCDS AVP的SCCRP控制消息，指示其愿意使用的值。如果CCDS AVP值与SCCRQ中的值相同，则表示接受请求的PHB代码。如果价值不同，则作为隧道终止方的还盘。
If the tunnel initiator receives an SCCRP that contains a CCDS AVP with a value other than that requested in the SCCRQ, the tunnel initiator SHOULD check the PHB code against its own policy. If it is unwilling to use the value, the tunnel initiator MUST send a StopCCN control message containing the Result Code 8 that indicates CCDS AVP value (47) as the reason for sending the StopCCN.
如果隧道启动器收到一个SCCRP，其中包含一个CCDS AVP，其值不是SCCRQ中请求的值，则隧道启动器应根据自己的策略检查PHB代码。如果不愿意使用该值，隧道启动器必须发送包含结果代码8的StopCCN控制消息，该结果代码指示CCDS AVP值（47）作为发送StopCCN的原因。
The CCDS AVP is encoded as Vendor ID 0, and the Attribute Type is 47.
CCDS AVP编码为供应商ID 0，属性类型为47。
Each CCDS AVP is encoded as follows:
每个CCD AVP编码如下：
Vendor ID = 0 Attribute = 47
供应商ID=0属性=47
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 47 | PHB Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 47 | PHB Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP MAY be present in the following message types: SCCRQ and SCCRP. This AVP MAY be hidden (the H-bit set to 0 or 1) and is optional (M-bit not set). The length (before hiding) of this AVP MUST be 8 octets. The encoding of the PHB code is described in Section 6.
此AVP可能存在于以下消息类型中：SCCRQ和SCCRP。该AVP可以隐藏（H位设置为0或1）并且是可选的（M位未设置）。此AVP的长度（隐藏前）必须为8个八位字节。第6节描述了PHB代码的编码。
As defined in [RFC 2661], an L2TP session is connection-oriented. The LAC and LNS maintain states for each call that is initiated or answered by an LAC. An L2TP session is created between the LAC and LNS when an end-to-end connection is established between a Remote System and the LNS. Datagrams related to the connection are sent over the tunnel between the LAC and LNS. As such, this document provides a mechanism to enable discrimination for packets within a particular session from those in other sessions. For this purpose, we introduce the Session DS (SDS) AVP.
如[RFC 2661]中所定义，L2TP会话是面向连接的。LAC和LN维护由LAC发起或应答的每个呼叫的状态。在远程系统和LNS之间建立端到端连接时，会在LAC和LNS之间创建L2TP会话。与连接相关的数据报通过LAC和LN之间的隧道发送。因此，本文档提供了一种机制，以使特定会话中的数据包能够与其他会话中的数据包区分开来。为此，我们介绍了会话DS（SDS）AVP。
The presence of the SDS AVP serves as an indication to the peer (LAC or LNS) that the session initiator wishes both the session initiator and terminator to use the per-hop behavior(s) (PHB(s)) indicated by the AVP's PHB code for all packets within the session.
SDS-AVP的存在用作向对等方（LAC或LNS）指示会话发起方希望会话发起方和终止方对会话内的所有分组使用由AVP的PHB代码指示的每跳行为（PHB）。
Upon receipt of an Incoming-Call-Request (ICRQ) or Outgoing-Call-Request (OCRQ) containing the SDS AVP if the session terminator provides no support for the requested PHB code, the session terminator MUST ignore the SDS AVP and send an ICRP or OCRP to the session initiator without the SDS AVP. The session initiator interprets the absence of the SDS AVP in the ICRP or OCRP as an indication that the session terminator is incapable of supporting SDS.
在收到包含SDS AVP的传入呼叫请求（ICRQ）或传出呼叫请求（OCRQ）后，如果会话终止程序不支持请求的PHB代码，则会话终止程序必须忽略SDS AVP，并在不使用SDS AVP的情况下向会话发起程序发送ICRP或OCRP。会话发起方将ICRP或OCRP中缺少SDS AVP解释为会话终止方无法支持SDS的指示。
Upon receipt of an ICRP or OCRP that contains no SDS AVP in response to an ICRQ or OCRQ that contained an SDS AVP, if the session initiator is willing to omit employing SDS AVP it continues session establishment as defined in [RFC 2661]. Otherwise, it sends a CDN to the session terminator to end the connection. The CDN control message MUST contain the Result Code 12 that indicates SDS AVP value (48) as the reason for sending the CDN.
在收到不包含SDS AVP的ICRP或OCRP以响应包含SDS AVP的ICRQ或OCRQ时，如果会话发起人愿意省略使用SDS AVP，则它将继续按照[RFC 2661]中的定义建立会话。否则，它将向会话终止程序发送CDN以结束连接。CDN控制消息必须包含结果代码12，该代码指示SDS AVP值（48）作为发送CDN的原因。
In order to help the session terminator to distinguish one session from another when consulting the local policy of the PHB code, the session initiator MAY use the identifier or a combination of identifiers embedded in AVPs such as Proxy Authen Name AVP, Calling Number AVP, Called Number AVP, and Sub-Address AVP. When Proxy Authen Name AVP is used as a distinguishor, it SHOULD be present in the ICRQ or OCRQ. The designated DS identifier(s) used for looking up the PHB code SHOULD be configurable.
为了在咨询PHB代码的本地策略时帮助会话终止器区分一个会话与另一个会话，会话发起方可以使用嵌入AVP中的标识符或标识符的组合，例如代理身份验证名AVP、主叫号码AVP、被叫号码AVP和子地址AVP。当代理身份验证名AVP用作区分符时，它应该出现在ICRQ或OCRQ中。用于查找PHB代码的指定DS标识符应是可配置的。
If the session terminator provides support for SDS, it SHOULD use the the designated DS identification AVP (via out-of-band agreement between the administrators of the LAC and LNS) to consult the local policy and determinate whether the local policy permits the requested PHB code to be used on this session. If it is unwilling or unable to support the requested PHB code the session terminator MUST do one of the following:
如果会话终止程序为SDS提供支持，则应使用指定的DS标识AVP（通过LAC和LNS管理员之间的带外协议）咨询本地策略，并确定本地策略是否允许在该会话上使用请求的PHB代码。如果不愿意或无法支持请求的PHB代码，会话终止程序必须执行以下操作之一：
1) Send a CDN message containing the Result Code 12 that indicates SDS AVP value (48) as the reason for sending the CDN.
1) 发送包含结果代码12的CDN消息，该结果代码指示SDS AVP值（48）作为发送CDN的原因。
2) Send an Incoming-Call-Reply (ICRP) or Outgoing-Call-Reply (OCRP) message containing an SDS AVP indicating the PHB code the terminator is willing to use for the session.
2) 发送传入呼叫应答（ICRP）或传出呼叫应答（OCRP）消息，其中包含SDS AVP，指示终止者愿意用于会话的PHB代码。
If the session terminator supports the PHB code in the SDS AVP session establishment MUST continue as defined in [RFC 2661].
如果会话终止符支持SDS AVP中的PHB代码，则必须按照[RFC 2661]中的定义继续建立会话。
If the session initiator receives an ICRP or OCRP that contains an SDS AVP with a value other than that requested in the ICRQ or OCRQ, and the session initiator is unwilling to use the value, the session initiator MUST send a CDN message containing the Result Code 12 that
如果会话发起人接收到一个ICRP或OCRP，其中包含一个SDS AVP，该SDS AVP的值不是ICRQ或OCRQ中请求的值，并且会话发起人不愿意使用该值，则会话发起人必须发送一条CDN消息，该消息包含以下结果代码12：
indicates SDS AVP value (48) as the reason for sending the CDN. If the session initiator receives an ICRP or OCRP that contains an SDS AVP with a value other than that requested in the ICRQ or OCRQ, and the session initiator is willing to use the value, the session initiator MUST proceed as indicated in [RFC 2661].
指示SDS AVP值（48）作为发送CDN的原因。如果会话发起人收到ICRP或OCRP，其中包含SDS AVP，其值不是ICRQ或OCRQ中要求的值，并且会话发起人愿意使用该值，则会话发起人必须按照[RFC 2661]中的说明进行。
The SDS AVP is encoded as Vendor ID 0, and the Attribute Value is 48.
SDS AVP编码为供应商ID 0，属性值为48。
Each SDS AVP is encoded as follows:
每个SDS AVP编码如下：
Vendor ID = 0 Attribute = 48
供应商ID=0属性=48
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 48 | PHB Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 48 | PHB Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP MAY be present in the following message types: ICRQ, ICRP, OCRQ and OCRP. This AVP MAY be hidden (the H-bit set to 0 or 1) and is optional (M-bit is not set 0). The length (before hiding) of this AVP MUST be 8 octets. The encoding of the PHB code is described in Section 6.
此AVP可能存在于以下消息类型中：ICRQ、ICRP、OCRQ和OCRP。此AVP可以隐藏（H位设置为0或1）并且是可选的（M位未设置为0）。此AVP的长度（隐藏前）必须为8个八位字节。第6节描述了PHB代码的编码。
CCDS AVP and SDS AVP are independent of each other. CCDS AVP is used to signal diffserv for the control connection between two L2TP peers, while SDS AVP is used for data connection. The PHB code signaled in one AVP SHOULD NOT have any implication on the PHB code signaled in the other AVP. Implementations MAY choose to implement either or both DS AVPs, and operations MAY choose to enable diffserv on either or both types of connections.
CCD AVP和SDS AVP相互独立。CCDS AVP用于为两个L2TP对等点之间的控制连接发送diffserv信号，而SDS AVP用于数据连接。一个AVP中发信号的PHB代码不应对另一个AVP中发信号的PHB代码有任何影响。实现可以选择实现DS AVP中的一种或两种，操作可以选择在其中一种或两种类型的连接上启用diffserv。
The PHB code is a left-justified 16-bit field using Per Hop Behavior (PHB) encoding defined in [RFC 3140]. Note that [RFC 3140] and its successor are the ultimate authority defining PHB encoding.
PHB代码是使用[RFC 3140]中定义的每跳行为（PHB）编码的左对齐16位字段。请注意，[RFC3140]及其后续版本是定义PHB编码的最终权威。
Upon successful establishment of an L2TP tunnel control connection or individual L2TP session employing the appropriate DS AVP defined in this document, both LAC and LNS MUST use their own PHB-to-DSCP mappings of their present DS domains to map the PHB to a DSCP and place it in the DS field of the outer IP header of packets transmitted on the connection.
成功建立L2TP隧道控制连接或使用本文件中定义的适当DS AVP的单独L2TP会话后，LAC和LN必须使用其当前DS域的PHB到DSCP映射将PHB映射到DSCP，并将其放置在连接上传输的数据包的外部IP报头的DS字段中。
The requirements or rules of each service and DSCP mapping are set through administrative policy mechanisms which are outside the scope of this document.
每个服务和DSCP映射的要求或规则通过本文档范围之外的管理策略机制设置。
[RFC 2474] RECOMMENDS that PHB implementations not cause reordering of packets within an individual connection. [RFC 3140] requires that a set of PHBs signaled using a single PHB ID MUST NOT cause additional packet reordering within an individual connection vs. using a single PHB. Since the CCDS and SDS AVPs contain one PHB ID, use of diffserv PHBs in accordance with this specification should not cause additional packet reordering within an L2TP control or data connection.
[RFC 2474]建议PHB实现不会导致单个连接内的数据包重新排序。[RFC 3140]要求，与使用单个PHB相比，使用单个PHB ID发出信号的一组PHB不得在单个连接内引起额外的数据包重新排序。由于ccd和SDS avp包含一个PHB ID，因此根据本规范使用diffserv PHB不应导致L2TP控制或数据连接内的额外分组重新排序。
Sequence numbers are required to be present in all control messages and are used to provide reliable delivery on the control connection, as defined in [RFC 2661]. While packet reordering is inevitably as much a function of the network as it is local traffic conditioning, the probability of it occurring when employing the CCDS AVP is same as when not employing the AVP. Data messages MAY use sequence numbers to reorder packets and detect lost packets.
按照[RFC 2661]中的定义，序列号必须出现在所有控制消息中，并用于在控制连接上提供可靠的传递。虽然分组重新排序不可避免地是网络的一个功能，就像它是本地业务调节一样，但是当采用CCDS AVP时发生它的概率与不采用AVP时相同。数据消息可以使用序列号来重新排列数据包并检测丢失的数据包。
With the potential that an L2TP connection traverses an arbitrary number of DS domains, signaling PHBs via L2TP is more appropriate than signaling DSCPs, because it maintains a consistent end-to-end differentiated service for the L2TP connection. As per [RFC 2983], the negotiated PHBs are mapped to locally defined DSCPs of the current DS domain at the tunnel ingress node. At the DS domain boundary nodes, the DSCPs can be rewritten in the DS field of the outer IP header, so that the DSCPs are always with respect to whatever DS domain the packet happens to be in.
由于L2TP连接可能穿越任意数量的DS域，因此通过L2TP向PHB发送信号比向DSCP发送信号更合适，因为它为L2TP连接保持一致的端到端区分服务。根据[RFC 2983]，协商的PHB映射到隧道入口节点处当前DS域的本地定义的DSCP。在DS域边界节点，可以在外部IP报头的DS字段中重写DSCP，以便DSCP始终与数据包所在的DS域相关。
As a result, it is perfectly acceptable that the outermost DS field of packets arriving on a given control connection or session are not marked with the same DSCP value that was used by the tunnel ingress node.
因此，到达给定控制连接或会话的数据包的最外层DS字段没有标记为隧道入口节点使用的相同DSCP值是完全可以接受的。
This document defines 2 L2TP Differentiated Services Extension AVPs. The IANA has assigned the value of 47 for the "CCDS AVP" defined in section 5.1 and the value of 48 for SDS AVP defined in section 6.1.
本文档定义了2个L2TP区分服务扩展AVP。IANA为第5.1节中定义的“CCDS AVP”分配了47，为第6.1节中定义的SDS AVP分配了48。
IANA has also assigned L2TP Result Code values of 8 for disconnecting control connection due to mismatching CCDS value (StopCCN), and 12 for disconnecting call due to mismatching SDS value (CDN).
IANA还为因CCDS值不匹配（StopCCN）而断开控制连接分配了L2TP结果代码值8，为因SDS值不匹配（CDN）而断开呼叫分配了12。
This encoding in itself raises no security issues. However, users of this encoding should consider that modifying a DSCP MAY constitute theft or denial of service, so protocols using this encoding MUST be adequately protected. No new security issues beyond those discussed in [RFC 2474] and [RFC 2475] are introduced here.
这种编码本身不会引起安全问题。然而，这种编码的用户应该考虑修改DSCP可能构成盗窃或拒绝服务，因此必须充分保护使用该编码的协议。除[RFC 2474]和[RFC 2475]中讨论的安全问题外，此处未介绍其他新的安全问题。
Many thanks to David Black, W. Mark Townsley, Nishit Vasavada, Andy Koscinski and John Shriver for their review and insightful feedback.
非常感谢David Black、W.Mark Townsley、Nishit Vasavada、Andy Koscinski和John Shriver的评论和富有洞察力的反馈。
[RFC 1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC 1661]辛普森，W.“点对点协议（PPP）”，STD 51，RFC 1661，1994年7月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC 2474] Nichols, K., Blake, S., Baker, F. and D. Black "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC 2474]Nichols，K.，Blake，S.，Baker，F.和D.Black，“IPv4和IPv6标头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC 2475] Blake, S., Black, D., Carlson, Z., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC 2475]Blake，S.，Black，D.，Carlson，Z.，Davies，E.，Wang，Z.和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[RFC 2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer 2 Tunnel Protocol (L2TP)", RFC 2661, August 1999.
[RFC 2661]汤斯利，W.，瓦伦西亚，A.，鲁本斯，A.，帕尔，G.，佐恩，G.和B.帕尔特，“第二层隧道协议（L2TP）”，RFC 2661，1999年8月。
[RFC 2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC 2983]Black，D.，“差异化服务和隧道”，RFC 2983，2000年10月。
[RFC 3140] Black, D., Brim, S., Carpenter, B. and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 3140, June 2001.
[RFC 3140]Black，D.，Brim，S.，Carpenter，B.和F.Le Faucheur，“每跳行为识别码”，RFC 31402001年6月。
Pat R. Calhoun 110 Nortech Parkway San Jose, CA 95134-2307
帕特·R·卡尔霍恩加利福尼亚州圣何塞诺特公园路110号，邮编95134-2307
Phone: +1 408.941.0500
EMail: pcalhoun@bstormnetworks.com
Phone: +1 408.941.0500
EMail: pcalhoun@bstormnetworks.com
Wei Luo Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
韦洛思科系统有限公司，加利福尼亚州圣何塞市西塔斯曼大道170号，邮编95134
Phone: +1 408.525.6906
EMail: luo@cisco.com
Phone: +1 408.525.6906
EMail: luo@cisco.com
Danny McPherson TCB
丹尼·麦克弗森TCB
Phone: +1 303.470.9257
EMail: danny@tcb.net
Phone: +1 303.470.9257
EMail: danny@tcb.net
Ken Peirce Malibu Networks, Inc. 1107 Investment Blvd, Suite 250 El Dorado Hills, CA 95762
Ken Peirce Malibu Networks，Inc.加利福尼亚州埃尔多拉多山投资大道1107号250室，邮编95762
Phone: +1 916.941.8814
EMail: Ken@malibunetworks.com
Phone: +1 916.941.8814
EMail: Ken@malibunetworks.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。