Network Working Group Y. T'Joens
Request for Comments: 3301 B. Sales
Category: Standards Track Alcatel
P. Crivellari
Belgacom
June 2002
Network Working Group Y. T'Joens
Request for Comments: 3301 B. Sales
Category: Standards Track Alcatel
P. Crivellari
Belgacom
June 2002
Layer Two Tunnelling Protocol (L2TP): ATM access network extensions
第二层隧道协议（L2TP）：ATM接入网扩展
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 augments the procedures described in RFC 2661 to further support ATM SVC (Switched Virtual Circuits) or PVC (Permanent Virtual Circuits) based access networks. L2TP (Layer 2 Tunneling Protocol) specifies a protocol for tunnelling PPP packets over packet based networks and over IP networks in particular. L2TP supports remote access by ISDN and PSTN networks. The extensions defined within this document allow for asymmetric bi-directional call establishment and service selection in the ATM access network.
本文件扩充了RFC 2661中描述的程序，以进一步支持基于ATM SVC（交换虚拟电路）或PVC（永久虚拟电路）的接入网络。L2TP（第2层隧道协议）指定了一种协议，用于通过基于分组的网络（尤其是IP网络）隧道PPP数据包。L2TP支持ISDN和PSTN网络的远程访问。本文件中定义的扩展允许在ATM接入网络中建立非对称双向呼叫和选择服务。
Table Of Contents
目录
1. Introduction .................................................. 2
1.1 Conventions .................................................. 2
2. Assumptions ................................................... 3
2.1 Topology ..................................................... 3
2.2 Connection Establishment ..................................... 3
2.3 LCP Negotiation .............................................. 3
3. ATM access enhanced procedures ................................ 3
3.1 ATM connectivity ............................................. 4
3.2 Tunnel establishment ......................................... 4
3.3 Call establishment ........................................... 5
3.3.1 Incoming Call Establishment ................................ 5
3.3.2 Outgoing Call Establishment ................................ 6
1. Introduction .................................................. 2
1.1 Conventions .................................................. 2
2. Assumptions ................................................... 3
2.1 Topology ..................................................... 3
2.2 Connection Establishment ..................................... 3
2.3 LCP Negotiation .............................................. 3
3. ATM access enhanced procedures ................................ 3
3.1 ATM connectivity ............................................. 4
3.2 Tunnel establishment ......................................... 4
3.3 Call establishment ........................................... 5
3.3.1 Incoming Call Establishment ................................ 5
3.3.2 Outgoing Call Establishment ................................ 6
3.4 Framing ...................................................... 6
4. Service model issues .......................................... 7
4.1 Authentication ............................................... 7
4.2 Authorization ................................................ 7
5. New and extended AVPs ......................................... 7
5.1 New AVP Summary .............................................. 7
5.2 New AVP definition ........................................... 8
5.3 Changed AVP Definition ....................................... 12
6. IANA considerations ........................................... 16
7. Security considerations ....................................... 17
8. Acknowledgements .............................................. 17
9. References .................................................... 17
10. Authors Addresses ............................................ 18
11. Full Copyright Statement ..................................... 19
3.4 Framing ...................................................... 6
4. Service model issues .......................................... 7
4.1 Authentication ............................................... 7
4.2 Authorization ................................................ 7
5. New and extended AVPs ......................................... 7
5.1 New AVP Summary .............................................. 7
5.2 New AVP definition ........................................... 8
5.3 Changed AVP Definition ....................................... 12
6. IANA considerations ........................................... 16
7. Security considerations ....................................... 17
8. Acknowledgements .............................................. 17
9. References .................................................... 17
10. Authors Addresses ............................................ 18
11. Full Copyright Statement ..................................... 19
L2TP [RFC2661] defines the procedures for tunneling PPP sessions between a so called L2TP Access Concentrator (LAC) and an L2TP Network Server (LNS). The main focus of [RFC2661] is on supporting HDLC based ISDN/PSTN access networks.
L2TP[RFC2661]定义了在所谓的L2TP访问集中器（LAC）和L2TP网络服务器（LNS）之间通过隧道传输PPP会话的过程。[RFC2661]的主要重点是支持基于HDLC的ISDN/PSTN接入网络。
This document augments the procedures described in [RFC2661] to further support ATM SVC or PVC based access networks. Support for ATM access networks requires extensions to the present L2TP procedures so as to cope with :
本文件补充了[RFC2661]中描述的程序，以进一步支持基于ATM SVC或PVC的接入网络。对ATM接入网络的支持需要对现有L2TP程序进行扩展，以应对：
(a) the traffic management aspects of ATM connections (e.g. asymmetric bandwidth allocation and service category selection capabilities),
(a) ATM连接的流量管理方面（例如不对称带宽分配和服务类别选择能力），
(b) the addressing format to be used in switched ATM networks [AESA] and
(b) 交换式ATM网络[AESA]中使用的寻址格式，以及
(c) the limitations imposed on LCP negotiation by transporting PPP over AAL5 over the access network segment of the PPP connection [RFC2364].
(c) 通过PPP连接的接入网段通过AAL5传输PPP对LCP协商施加的限制[RFC2364]。
Within this document, the necessary extensions to [RFC2661] are defined to cope with issues (a) and (b), issue (c) which is not specific to ATM may be solved as described in [L2TP_link].
在本文件中，对[RFC2661]进行了必要的扩展，以解决问题（a）和（b），不特定于ATM的问题（c）可以按照[L2TP_链接]中的描述解决。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
In this section we describe some assumptions that have lead to the extensions described in this document.
在本节中，我们将介绍一些导致本文档中所述扩展的假设。
The procedures as defined in [RFC2661] apply mainly to access network technology such as PSTN and ISDN, which may be respectively asynchronous HDLC and synchronous HDLC based. The aim of this document is to extend L2TP support to allow for user / LAC communication based on ATM access network technology.
[RFC2661]中定义的程序主要适用于接入网络技术，如PSTN和ISDN，它们可以分别基于异步HDLC和同步HDLC。本文档的目的是扩展L2TP支持，以允许基于ATM接入网技术的用户/LAC通信。
Due to the wide variety of existing signalling protocols and ATM service categories, and their support or non-support within ATM based access networks, this document takes as approach to provide for a flexible identification of ATM connection characteristics while establishing outgoing and incoming L2TP calls. The procedures as defined within this document allow the allocation of asymmetric bandwidth and service category selection in terms of real or non-real time requirements on the ATM portion of the access network.
由于现有信令协议和ATM服务类别的多样性，以及它们在基于ATM的接入网络中的支持或不支持，本文件采用一种方法，在建立传出和传入L2TP呼叫时，灵活地识别ATM连接特征。本文件中定义的程序允许根据接入网络ATM部分的实时或非实时要求分配非对称带宽和选择服务类别。
As such, the detailed signalling protocol specific information elements that are necessary for switched VC service, are explicitly not negotiated during call establishment over the L2TP tunnel.
因此，交换VC服务所需的详细信令协议特定信息元素在L2TP隧道上的呼叫建立期间不被明确协商。
In order to identify the endpoint of the ATM connection within the ATM access network, SVCs can be established on the basis of the ATM end system addressing format [AESA]. For PVC based services, the PVC can either be referred to by using the ATM end system addressing procedure (Called/Calling Number), or by making use of a textual name (Service Name). The latter is inspired by the procedures defined within [Auto_PVC].
为了识别ATM接入网内ATM连接的端点，可以基于ATM终端系统寻址格式[AESA]建立SVC。对于基于PVC的服务，可以通过使用ATM终端系统寻址过程（被叫/呼叫号码）或通过使用文本名称（服务名称）来引用PVC。后者受[Auto_PVC]中定义的程序启发。
The procedures described within this document may be combined with the procedures described in [L2TP_link] to limit LCP negotiation between LNS and user, so as to enforce PPP over AAL5 specific LCP negotiation [RFC2364].
本文件中描述的程序可与[L2TP_link]中描述的程序相结合，以限制LN和用户之间的LCP协商，从而在AAL5特定LCP协商[RFC2364]上实施PPP。
In order to illustrate the procedures specified within this document, this section will provide an operational description of Virtual dial-up access through an ATM based access network (e.g., ADSL).
为了说明本文件中规定的程序，本节将提供通过基于ATM的接入网络（如ADSL）进行虚拟拨号接入的操作说明。
Note that the emphasis is on the changes proposed within this document relative to [RFC2661].
注意，重点是本文件中提出的与[RFC2661]相关的变更。
Prior to initiating the PPP protocol layer, a Virtual Connection (VC) MUST be established between the user and the Network Access Server (LAC). This virtual connection MAY either be a preconfigured Permanent VC(PVC), where the access network provider, NAS and user agree beforehand on the characteristics of the PVC, or MAY be an on-demand switched VC(SVC), where the negotiation between user, network and NAS takes place by means of an ATM signalling protocol. Note that for establishing PVCs, alternative use may be made of the procedures as described in [Auto_PVC].
在启动PPP协议层之前，必须在用户和网络访问服务器（LAC）之间建立虚拟连接（VC）。该虚拟连接可以是预配置的永久性VC（PVC），其中接入网络提供商、NAS和用户事先就PVC的特性达成一致，或者可以是按需交换的VC（SVC），其中用户、网络和NAS之间通过ATM信令协议进行协商。注意，对于建立PVC，可使用[Auto_PVC]中所述的程序进行替代。
In both cases, the user is referred to as the virtual dial-in user.
在这两种情况下，用户都被称为虚拟拨入用户。
Prior to accepting the switched connection from the virtual dial-in user, the LAC MAY check with the LNS whether the call should be accepted. In the latter situation, the LAC MAY determine based upon parameters available within the call establishment message that this concerns a virtual dial in user, or MAY undertake a partial authentication of the end system/user, in order to bind the end system/user with a specific LNS.
在接受来自虚拟拨入用户的交换连接之前，LAC可与LNS检查是否应接受呼叫。在后一种情况下，LAC可以基于呼叫建立消息中可用的参数来确定这涉及虚拟拨入用户，或者可以对终端系统/用户进行部分认证，以便将终端系统/用户与特定LNS绑定。
For PVC based users, the LAC MAY be triggered by the arrival of an LCP Configure Request, or PPP Authentication request message from the virtual dial-in user to initiate conversation with the LNS. Note that the exact timing of triggering communication between LAC and LNS is outside the scope of this document.
对于基于PVC的用户，LAC可由来自虚拟拨入用户的LCP配置请求或PPP认证请求消息的到达触发，以发起与LNS的对话。请注意，LAC和LNS之间触发通信的确切时间不在本文件范围内。
If no tunnel connection currently exists to the desired LNS, one is initiated. During the tunnel establishment, LNS and LAC indicate bearer and framing capabilities to each other, according to normal procedures.
如果当前不存在与所需LN的隧道连接，则启动一个。在隧道建立期间，LN和LAC根据正常程序相互指示承载能力和成帧能力。
The bearer capability is extended to allow the LAC to indicate its support of ATM bearer devices. Positive receipt of this indication, allows both LAC and LNS to use the extensions as defined within this document to support ATM based incoming and outgoing calls.
承载能力被扩展，以允许LAC指示其对ATM承载设备的支持。收到该指示后，LAC和LNS均可使用本文件中定义的分机来支持基于ATM的呼入和呼出呼叫。
If no compatibility between LNS and LAC exists according to the extensions defined within this document, no tunnel establishment can take place. This would be because the LAC does not support any bearer capability which is expected by the LNS (e.g., an ATM based LAC, that only signals the "Broadband" Bearer Capability), or vice
如果根据本文件中定义的扩展，LNS和LAC之间不存在兼容性，则无法建立隧道。这将是因为LAC不支持LN所期望的任何承载能力（例如，基于ATM的LAC，仅向“宽带”承载能力发送信号），反之亦然
versa. It is however encouraged that LAC or LNS implementations would allow for seamless interworking with peer devices which do not implement the extensions defined within this document. This could be implemented by allowing a graceful fallback to digital bearer capability.
反之亦然。但是，我们鼓励LAC或LNS实现允许与未实现本文档中定义的扩展的对等设备无缝互通。这可以通过允许对数字承载能力进行适当的回退来实现。
During incoming and outgoing broadband call establishment, the following extensions are defined to existing procedures.
在建立传入和传出宽带呼叫期间，对现有程序定义了以下扩展。
The ATM connection between the virtual Dial-in user and LAC MAY either be dynamically or statically established. When the VC connection is dynamically established (Switched VC), the LAC will receive a SETUP message over the interface that connects it to the ATM network. This specification does not assume any specific interface type (UNI or NNI). Permanent VC connections MAY either be manually configured, or configured by use of the extensions to the ILMI procedures as defined by [Auto_PVC].
虚拟拨入用户和LAC之间的ATM连接可以动态或静态建立。当动态建立VC连接（交换VC）时，LAC将通过将其连接到ATM网络的接口接收设置消息。本规范不采用任何特定接口类型（UNI或NNI）。永久VC连接可以手动配置，也可以使用[Auto_PVC]定义的ILMI程序扩展配置。
For switched VC connections, the LAC MAY select the peer LNS on the basis of connection establishment information, or by allowing partial PPP authentication of the virtual Dial-in user. The connection establishment information that can be used by the LAC include Called Party AESA, Called Party AESA Subaddress, Calling Party AESA or Calling Party AESA Subaddress.
对于交换VC连接，LAC可以基于连接建立信息或通过允许虚拟拨入用户的部分PPP认证来选择对等ln。LAC可以使用的连接建立信息包括被叫方AESA、被叫方AESA子地址、主叫方AESA或主叫方AESA子地址。
For Permanent VC connections, the LAC MAY be triggered by (a) the establishment of the PVC, (b) by an LCP configure request, (c) by partially authenticating the virtual Dial-in user, or (d) by means outside the scope of this specification.
对于永久性VC连接，LAC可通过以下方式触发：（a）建立PVC，（b）通过LCP配置请求，（c）通过部分验证虚拟拨入用户，或（d）通过本规范范围之外的方式。
Within the ICRQ, the LAC MUST indicate a broadband bearer in the Bearer Type AVP (B bit set to 1), MAY include the Service Category AVP, and MAY include the Service Name AVP. If the LNS would not support the B Bearer bit, it will return an error on the ICRQ message. In such a case, the implementation MAY decide to fall back to digital bearer capability, and SHOULD refrain from using the extensions defined within this document. Further, the ICRQ message MAY contain the VPI/VCI identifier AVP. This identifier can further be used at the LNS for management purposes next to or alternative to the Physical Channel ID AVP.
在ICRQ内，LAC必须以承载类型AVP（B比特设置为1）指示宽带承载，可以包括服务类别AVP，并且可以包括服务名称AVP。如果LNS不支持B承载位，它将在ICRQ消息上返回错误。在这种情况下，实现可能决定退回到数字承载能力，并且应该避免使用本文档中定义的扩展。此外，ICRQ消息可以包含VPI/VCI标识符AVP。该标识符还可在LNS处用于物理信道ID AVP旁边或替代物理信道ID AVP的管理目的。
Within the ICCN, both Tx Connect Speed AVP and Rx Connect Speed SHOULD be used if an asymetric connection has been established.
在ICCN内，如果已建立不对称连接，则应同时使用Tx连接速度AVP和Rx连接速度。
Within an OCRQ, the LNS MUST indicate to the LAC minimum and maximum speeds for receive and transmit traffic (from the LAC perspective). This is to allow for the bi-directional asymmetric nature of ATM traffic contracts. Note that in order to support UBR connections between LAC and user, the Minimum BPS MUST be set to zero.
在OCRQ中，LN必须向LAC指示接收和发送流量的最小和最大速度（从LAC的角度）。这是为了考虑ATM流量合约的双向不对称性质。请注意，为了支持LAC和用户之间的UBR连接，最小BPS必须设置为零。
Further during OCRQ, the LNS MAY include the required Service Category AVP, i.e., indicating real time (rt) or non-real time (nrt) transport services. The combination of minimum and maximum receive and transmit speed, and the indication of the required service category allows the LAC to establish an ATM connection according to its own capabilities, and the ATM access network capabilities, however within the service requirement for the PPP layer.
此外，在OCRQ期间，LNS可包括所需服务类别AVP，即，指示实时（rt）或非实时（nrt）传输服务。最小和最大接收和传输速度的组合以及所需服务类别的指示允许LAC根据其自身能力和ATM接入网络能力建立ATM连接，但在PPP层的服务要求范围内。
Real time connectivity can be provided by either CBR or rt-VBR ATM service categories, non-real time connectivity can be provided by UBR, nrt-VBR, ABR or GFR ATM service categories.
实时连接可通过CBR或rt VBR ATM服务类别提供，非实时连接可通过UBR、nrt VBR、ABR或GFR ATM服务类别提供。
Further the LNS MUST indicate to the LAC in OCRQ message the called number according to the format described in this document (NSAP format). When the called number carries an all zero payload, the LAC SHOULD look at the Service Name AVP to bind the tunnel call to an ATM VC connection.
此外，LN必须根据本文件中描述的格式（NSAP格式），在OCRQ消息中向LAC指示被叫号码。当被叫号码携带全零负载时，LAC应查看服务名称AVP，以将隧道呼叫绑定到ATM VC连接。
Next to the normal AVPs, the OCRP message MAY contain the VPI/VCI identifier AVP. This identifier can further be used at the LNS for management purposes next to or alternative to the Physical Channel ID AVP.
在普通AVP旁边，OCRP消息可以包含VPI/VCI标识符AVP。该标识符还可在LNS处用于物理信道ID AVP旁边或替代物理信道ID AVP的管理目的。
Within this document the PPP PDU refers to the concatenation of PPP protocol ID, PPP Information and PPP padding fields.
在本文档中，PPP PDU指PPP协议ID、PPP信息和PPP填充字段的串联。
In the direction of user to LNS, the PPP PDU will be carried on top of an AAL5 connection between user and LAC. The LAC MUST strip off the AAL5 specific fields based on the encapsulation mechanism in use on the ATM connection, i.e. VC multiplexed or LLC encapsulated [RFC2364], and MUST encapsulate the PPP PDU with address and control field, as per HDLC procedures, on the L2TP tunnel.
在用户到LNS的方向上，PPP PDU将在用户和LAC之间的AAL5连接上进行。LAC必须根据ATM连接上使用的封装机制剥离AAL5特定字段，即VC多路复用或LLC封装[RFC2364]，并且必须根据HDLC程序在L2TP隧道上用地址和控制字段封装PPP PDU。
In the direction of LNS to user, the PPP PDU will be carried on top of an AAL5 connection between LAC and user. The LAC MUST strip the PPP PDU from the address and control field on the L2TP tunnel, and
在LNS到用户的方向上，PPP PDU将在LAC和用户之间的AAL5连接上进行。LAC必须从L2TP隧道上的地址和控制字段中剥离PPP PDU，以及
insert the AAL5 specific fields based on the encapsulation mechanism in use on the ATM connection, i.e. VC multiplexed or LLC encapsulated.
根据ATM连接上使用的封装机制，即VC多路复用或LLC封装，插入AAL5特定字段。
In case of ATM switched VC establishment, calling party number information may be used for first level authentication much in the same way as for PSTN or ISDN access. In case of permanent VC establishment, authentication may not be an issue from the LAC side, because of the permanent character of the VC. Bilateral agreement between LAC and LNS providers may eliminate the authentication phase in the latter case.
在ATM交换VC建立的情况下，主叫方号码信息可用于一级认证，其方式与PSTN或ISDN接入的方式大致相同。如果是常设VC机构，由于VC的永久性，拉丁美洲和加勒比海地区方面可能不存在认证问题。LAC和LNS供应商之间的双边协议可能会取消后一种情况下的认证阶段。
Because of the flexibility of establishing ATM connections with varying parameters, some authorization may be required prior to accepting the establishment of a switched ATM connection from the user with certain ATM traffic parameters. This authorization may be performed against the ATM specific authentication information (e.g. calling line id), or may be performed after partial authentication of the user at the PPP level. Non authorized access requests result in connection release.
由于建立具有不同参数的ATM连接的灵活性，在接受具有特定ATM流量参数的用户建立交换ATM连接之前，可能需要一些授权。该授权可以针对ATM特定的认证信息（例如，呼叫线路id）执行，或者可以在PPP级别对用户进行部分认证之后执行。未经授权的访问请求会导致连接释放。
The following table lists the extra AVPs that are defined within this document. The "attr" column indicates the integer value assigned to this attribute. Note that the attribute value is relative compared to the vendor ID. The "M" column indicates the setting of the "Mandatory" bit of the AVP header for each attribute. The "LEN" column indicates the size of the AVP including the AVP header. A "+" in this column indicates that the length varies depending upon the length of the actual contents of the value field.
下表列出了本文件中定义的额外AVP。“attr”列表示分配给该属性的整数值。请注意，属性值与供应商ID相比是相对的。“M”列表示每个属性的AVP头的“强制”位的设置。“LEN”列表示AVP的大小，包括AVP标题。此列中的“+”表示长度根据值字段实际内容的长度而变化。
The usage list for each entry indicates the message types that utilize each AVP. An abbreviation shown in mixed or upper case letters indicates that the corresponding AVP MUST be present in this message type. All lower case indicates that the AVP MAY optionally appear in this message type. Some AVPs MAY be present only when a corresponding optional AVP or specific setting within the AVP is present, these AVPs are shown in lower case as well.
每个条目的使用列表指示使用每个AVP的消息类型。以混合字母或大写字母显示的缩写表示此消息类型中必须存在相应的AVP。所有小写字母表示AVP可选择性地出现在此消息类型中。一些AVP可能仅在AVP中存在相应的可选AVP或特定设置时出现，这些AVP也以小写形式显示。
Attr M Len Attribute Name (usage)
属性M Len属性名称（用法）
40 0 10 Rx Minimum BPS (ocrq) 32-bit integer indicating the lowest acceptable line speed for the call in the receive direction. Rx indicates the user to LAC direction. 41 0 10 Rx Maximum BPS (ocrq) 32-bit integer indicating the highest acceptable line speed for call in the receive direction. Rx indicates the user to LAC direction. 42 0 8 Service Category (ocrq, icrq) The Service Category indicates the service expected for the call, e.g., real time or non-real time. 43 0 6+ Service Name (ocrq, icrq) The Service Name indicates the service name linked to a preestablished PVC. 44 0 26 Calling Sub-Address(icrq) 20 octet binary encoded NSAP subaddress indicating the Calling Party Sub-Address. 45 0 10 VPI/VCI identifier (icrq, ocrp) 10 octet binary encoded identification of VPI/VCI values used for incoming calls.
40 0 10 Rx最小BPS（ocrq）32位整数，指示接收方向上呼叫的最低可接受线路速度。Rx指示用户到LAC的方向。41 0 10 Rx最大BPS（ocrq）32位整数，表示接收方向呼叫的最高可接受线路速度。Rx指示用户到LAC的方向。42 0 8服务类别（ocrq、icrq）服务类别表示呼叫预期的服务，例如实时或非实时。43 0 6+服务名称（ocrq、icrq）服务名称表示链接到预先建立的PVC的服务名称。44 0 26主叫子地址（icrq）20八位二进制编码的NSAP子地址，指示主叫方子地址。45 0 10 VPI/VCI标识符（icrq，ocrp）10个八位二进制编码的用于传入呼叫的VPI/VCI值标识。
The following lists the new AVPs defined within this document, and describes the expected behaviour when this AVP would be present within a message.
以下列出了本文档中定义的新AVP，并描述了该AVP出现在消息中时的预期行为。
Rx Minimum BPS (OCRQ)
接收最小BPS（OCRQ）
The Rx Minimum BPS, Attribute Type 40, encodes the lowest acceptable line speed for this call in the receive direction, for these cases where asymmetric transmission is required.
对于需要不对称传输的情况，Rx最小BPS属性类型40编码接收方向上该呼叫的最低可接受线路速度。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rx Minimum BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rx Minimum BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Rx Minimum BPS is a 32 bit value indicating the speed in bits per second.
Rx最小BPS是一个32位的值，表示以位/秒为单位的速度。
This AVP MAY be included within the OCRQ, and SHOULD only be included when the LAC indicated broadband bearer support in the bearer capabilities AVP during tunnel establishment.
该AVP可包括在OCRQ中，并且仅当LAC在隧道建立期间在承载能力AVP中指示宽带承载支持时，才应包括该AVP。
This AVP may be hidden (the H-bit may be set to 0 or 1). The M- bit for this AVP must be set to 0. The Length (before hiding) of this AVP is 10.
该AVP可以隐藏（H位可以设置为0或1）。此AVP的M位必须设置为0。此AVP的长度（隐藏前）为10。
Rx Maximum BPS
最大接收BPS
The Rx Maximum BPS, Attribute Type 41, encodes the highest acceptable line speed for this call in the receive direction, for these cases where asymmetric transmission is required.
对于需要不对称传输的情况，Rx最大BPS属性类型41编码接收方向上该呼叫的最高可接受线路速度。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rx Maximum BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rx Maximum BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Rx Maximum BPS is a 32 bit value indicating the speed in bits per second.
Rx最大BPS是一个32位的值，表示以位/秒为单位的速度。
This AVP MAY be included within the OCRQ, and SHOULD only be included when the LAC indicated broadband bearer support in the bearer capabilities AVP during tunnel establishment.
该AVP可包括在OCRQ中，并且仅当LAC在隧道建立期间在承载能力AVP中指示宽带承载支持时，才应包括该AVP。
This AVP may be hidden (the H-bit may be set to 0 or 1). The M- bit for this AVP must be set to 0. The Length (before hiding) of this AVP is 10.
该AVP可以隐藏（H位可以设置为0或1）。此AVP的M位必须设置为0。此AVP的长度（隐藏前）为10。
Service Category
服务类别
The Service Category AVP, Attribute type 42, indicates optional extra information on the Quality of Service expected for the call establishment on the broadband bearer medium.
属性类型42的服务类别AVP指示关于宽带承载介质上呼叫建立所期望的服务质量的可选额外信息。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resvd for future QoS ind. |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resvd for future QoS ind. |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Attribute Value field is a 16-bit mask, with one bit defined. The S bit indicates either non real time (S bit set to 0) or real time (S bit set to 1) service requirement. The other bit fields are reserved for future use.
属性值字段是一个16位掩码，定义了一位。S位表示非实时（S位设置为0）或实时（S位设置为1）服务要求。其他位字段保留供将来使用。
The Service Category AVP MAY be present in OCRQ and ICRQ messages, and SHOULD only be included when the LAC indicated broadband bearer support in the bearer capabilities AVP during tunnel establishment.
服务类别AVP可能存在于OCRQ和ICRQ消息中，并且仅当LAC在隧道建立期间在承载能力AVP中指示宽带承载支持时，才应包括该服务类别AVP。
This AVP may be hidden (the H-bit may be set to 0 or 1). The M- bit for this AVP must be set to 0. The Length (before hiding) of this AVP is 8.
该AVP可以隐藏（H位可以设置为0或1）。此AVP的M位必须设置为0。此AVP的长度（隐藏前）为8。
Service Name
服务名称
The Service Name AVP, Attribute Type 43, provides the peer with an textual name for referring to an ATM VC connection.
服务名称AVP属性类型43为对等方提供用于引用ATM-VC连接的文本名称。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Name (arbitrary number of octets) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Name (arbitrary number of octets) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Service Name is of arbitrary length, but must be at least 1 octet. The Service Name is UTF-8 encoded. [10646]
服务名称具有任意长度，但必须至少为1个八位字节。服务名称是UTF-8编码的。[10646]
The Service Name should be unique at least to the LNS/LAC combination.
服务名称应至少对LNS/LAC组合是唯一的。
The Service Name AVP MAY only be provided when the Called Number field is encoded as all zeros in OCRQ. The Service Name AVP MAY be present in OCRQ and ICRQ messages, and SHOULD only be included when the LAC indicated broadband bearer support in the bearer capabilities AVP during tunnel establishment.
只有当被叫号码字段在OCRQ中编码为全零时，才能提供服务名称AVP。服务名称AVP可能出现在OCRQ和ICRQ消息中，并且仅当LAC在隧道建立期间在承载能力AVP中指示宽带承载支持时，才应包括该服务名称AVP。
This AVP may be hidden (the H-bit may be set to 0 or 1). The M- bit for this AVP must be set to 0. The length of this attribute is arbitrary, however at least 7.
该AVP可以隐藏（H位可以设置为0或1）。此AVP的M位必须设置为0。此属性的长度是任意的，但至少为7。
Calling Sub-Address (ICRQ)
呼叫子地址（ICRQ）
The Calling Sub-Address AVP, Attribute Type 44, encodes additional Calling Party subaddress information.
主叫子地址AVP属性类型44编码附加主叫方子地址信息。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Calling Sub-Address AVP MUST be encoded as a 20 octet binary encoded NSAP address when the B bit is set in the Bearer Type AVP. The NSAP binary encoded address provides a broader range of address encapsulation methods than an ASCII field. The structure of the NSAP address (e.g., E.164, ICD, DCC) is defined in [AESA].
当在承载类型AVP中设置B位时，呼叫子地址AVP必须编码为20八位二进制编码NSAP地址。NSAP二进制编码地址提供了比ASCII字段更广泛的地址封装方法。NSAP地址的结构（例如，e.164、ICD、DCC）在[AESA]中定义。
The Calling Sub-Address number AVP MAY be present in ICRQ, and SHOULD only be available if the Calling Party number is also within the message.
呼叫子地址号码AVP可能存在于ICRQ中，并且仅当呼叫方号码也在消息中时才可用。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 26.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为0。此AVP的长度（隐藏前）为26。
VPI/VCI identifier(icrq, ocrp)
VPI/VCI标识符（icrq、ocrp）
The VPI/VCI identifier, Attribute Type 45, encodes the VPI/VCI value used at the ATM interface at the LAC.
属性类型为45的VPI/VCI标识符对LAC的ATM接口上使用的VPI/VCI值进行编码。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|resvd | VPI | VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|resvd | VPI | VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The VPI/VCI identifier is a 32 bit value encoding the VPI(12 bits) and VCI (16 bits) value.
VPI/VCI标识符是编码VPI（12位）和VCI（16位）值的32位值。
This AVP MAY be included within the ICRQ and OCRP, and SHOULD only be included when the LAC indicated broadband bearer support in the bearer capabilities AVP during tunnel establishment.
该AVP可包括在ICRQ和OCRP中，且仅当LAC在隧道建立期间在承载能力AVP中指示宽带承载支持时，才应包括该AVP。
This AVP may be hidden (the H-bit may be set to 0 or 1). The M- bit for this AVP must be set to 0. The Length (before hiding) of this AVP is 10.
该AVP可以隐藏（H位可以设置为0或1）。此AVP的M位必须设置为0。此AVP的长度（隐藏前）为10。
The following AVPs see their contents changed relative to [RFC2661] in order to support the procedures described in this document.
以下AVP的内容相对于[RFC2661]有所更改，以支持本文档中描述的程序。
Bearer Capabilities
承载能力
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resvd for future bearer capability definitions |B|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resvd for future bearer capability definitions |B|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The bearer Capabilities AVP within a SCCRQ or SCCRP indicates the bearer capabilities that the sender of this message can provide for outgoing calls. This document extends the existing AVP with the B bit. If bit B is set, broadband access is supported (ATM).
SCCRQ或SCCRP中的承载能力AVP表示此消息的发送方可以为传出呼叫提供的承载能力。本文档使用B位扩展了现有的AVP。如果设置了位B，则支持宽带接入（ATM）。
Attempts to establish an outgoing call with the bearer type set to B, while the bearer capability did not indicate this capability will result in the call being rejected with Result Code 5 'Call failed due to lack of appropriate facilities being available (permanent condition)'.
尝试建立承载类型设置为B的传出呼叫，而承载能力未表明此能力将导致呼叫被拒绝，结果代码为5“由于缺少可用的适当设施（永久条件），呼叫失败”。
In these cases where the LAC only supports the B bit, and the LNS would not recognize the B bit, no outgoing calls are possible. Note that when the LAC only has ATM based devices, it may still opt for seamless fall back to digital bearer types.
在这些情况下，LAC仅支持B位，而LNS无法识别B位，则不可能传出呼叫。注意，当LAC只有基于ATM的设备时，它仍然可以选择无缝退回到数字承载类型。
This specification assumes a non-compliant LNS to categorize a Bearer Capabilities AVP where the B bit is set as unrecognized AVP, upon which the tunnel establishment will fail. This is to be indicated by a Result Code '2-General error - Error Code indicates the problem', Error Code '3- Reserved field was non-zero'.
本规范假设不符合要求的LNS将承载能力AVP分类，其中B位设置为无法识别的AVP，在此情况下，隧道建立将失败。这将由结果代码“2-一般错误-错误代码表示问题”，错误代码“3-保留字段非零”表示。
(Tx) Minimum BPS
（Tx）最低BPS
The (Tx) Minimum BPS AVP encodes the lowest acceptable line speed for this call in the transmit direction. The (Tx) Minimum BPS AVP MAY be used in OCRQ. If the Rx Minimum BPS AVP, as defined within this document, is not available in the message, then symmetric transmission is implied, with both minimum receive and transmit bit-rates equal to Minimum BPS.
（Tx）最小BPS AVP编码传输方向上此呼叫的最低可接受线路速度。OCRQ中可以使用（Tx）最小BPS AVP。如果本文件中定义的Rx最小BPS AVP在消息中不可用，则暗示对称传输，最小接收和传输比特率均等于最小BPS。
(Tx) Maximum BPS
（Tx）最大BPS
(Tx) Maximum BPS AVP encodes the highest acceptable line speed for this call in the transmit direction. The (Tx) Maximum BPS AVP MAY be used in OCRQ. If the Rx Maximum BPS AVP, as defined within this document, is not available in the message, then symmetric transmission is implied, with both maximum receive and transmit bitrates equal to Maximum BPS.
（Tx）Maximum BPS AVP编码传输方向上该呼叫的最高可接受线路速度。OCRQ中可以使用（Tx）最大BPS AVP。如果本文件中定义的Rx最大BPS AVP在消息中不可用，则暗示对称传输，最大接收和传输比特率均等于最大BPS。
Bearer Type
承载类型
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resvd for future bearer types definitions |B|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resvd for future bearer types definitions |B|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The bearer type AVP encodes the bearer type for the requested call. This document extends the bearer types with an indication of ATM bearer support (B-bit). If bit B is set, broadband access is requested (ATM). If bit A is set, analogue access is requested. If bit D is set, Digital access is requested.
承载类型AVP对请求呼叫的承载类型进行编码。本文档通过ATM承载支持（B位）扩展了承载类型。如果设置了位B，则请求宽带接入（ATM）。如果设置了位A，则请求模拟访问。如果设置了位D，则请求数字访问。
Note that in the OCRQ all 3 bits (B,A,D) may be set indicating that the call may be of either type. The B bit SHOULD only be set if the Broadband capability was indicated during tunnel establishment.
注意，在OCRQ中，可以设置所有3位（B、A、D），指示呼叫可以是任一类型。只有在隧道建立期间指示宽带能力时，才应设置B位。
Q.931 Cause Code
Q.931原因代码
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code | Cause Msg | Advisory Msg...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code | Cause Msg | Advisory Msg...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Cause code is not changed from [RFC2661], except for the fact that it can also carry Cause Codes specific to ATM signalling messages, these cause codes can be found in ATM
原因代码未从[RFC2661]更改，除了它也可以携带特定于ATM信令消息的原因代码外，这些原因代码可以在ATM中找到
Forum UNI 4.0 [UNI] and the references thereof. The Cause code should be interpreted relative to the Bearer Type in use for the specific call.
论坛UNI 4.0[UNI]及其参考文献。原因码应该相对于特定呼叫使用的承载类型进行解释。
Called Number
被叫号码
The Called Number AVP, Attribute Type 21, encodes the AESA number to be called for an OCRQ, and the Called number at the LAC for an ICRQ.
被叫号码AVP属性类型21对OCRQ要呼叫的AESA号码和ICRQ在LAC的被叫号码进行编码。
The Attribute Value field for this AVP has a changed encoding from [RFC2661]:
此AVP的属性值字段的编码已从[RFC2661]更改为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Called Number AVP MUST be encoded as a 20 octet binary encoded NSAP address when the B bit is set in the Bearer Type AVP. The NSAP binary encoded address provides a broader range of address encapsulation methods than an ASCII field. The structure of the NSAP address (e.g., E.164, ICD, DCC) is defined in [AESA].
当在承载类型AVP中设置B位时，被叫号码AVP必须编码为20位二进制编码NSAP地址。NSAP二进制编码地址提供了比ASCII字段更广泛的地址封装方法。NSAP地址的结构（例如，e.164、ICD、DCC）在[AESA]中定义。
The Called number AVP MUST be present in OCRQ, and MAY be present in ICRQ.
被叫号码AVP必须存在于OCRQ中，并且可能存在于ICRQ中。
If the Called Number AVP in an OCRQ carries an all zero NSAP address, the Service Name AVP SHOULD provide further information to bind the L2TP call to a specific VC connection. See also [Auto_PVC].
如果OCRQ中的被叫号码AVP包含全零NSAP地址，则服务名称AVP应提供进一步的信息，以将L2TP调用绑定到特定的VC连接。另请参见[Auto_PVC]。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 26.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为0。此AVP的长度（隐藏前）为26。
Calling Number
主叫号码
The Calling Number AVP, Attribute Type 22, encodes the Calling Party AESA as received from the Virtual Dial-in User.
主叫号码AVP，属性类型22，将主叫方AESA编码为从虚拟拨入用户接收的。
The Attribute Value field for this AVP has a changed encoding from [RFC2661]:
此AVP的属性值字段的编码已从[RFC2661]更改为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Calling Number AVP MUST be encoded as a 20 octet binary encoded NSAP address when the B bit is set in the Bearer Type AVP. The NSAP binary encoded address provides a broader range of address encapsulation methods than an ASCII field. The structure of the NSAP address (e.g., E.164, ICD, DCC) is defined in [AESA].
当在承载类型AVP中设置B位时，呼叫号码AVP必须编码为20位二进制编码NSAP地址。NSAP二进制编码地址提供了比ASCII字段更广泛的地址封装方法。NSAP地址的结构（例如，e.164、ICD、DCC）在[AESA]中定义。
The Calling number AVP MAY be present in ICRQ.
呼叫号码AVP可能存在于ICRQ中。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 26.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为0。此AVP的长度（隐藏前）为26。
Sub-Address
子地址
The Sub-Address AVP, Attribute Type 23, encodes additional Called Party subaddress information.
子地址AVP，属性类型23，编码额外的被叫方子地址信息。
The Attribute Value field for this AVP has a changed encoding from [RFC2661]:
此AVP的属性值字段的编码已从[RFC2661]更改为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Sub-Address AVP MUST be encoded as a 20 octet binary encoded NSAP address when the B bit is set in the Bearer Type AVP. The NSAP binary encoded address provides a broader range of address encapsulation methods than an ASCII field. The structure of the NSAP address (e.g., E.164, ICD, DCC) is defined in [AESA].
当在承载类型AVP中设置B位时，子地址AVP必须编码为20八位二进制编码NSAP地址。NSAP二进制编码地址提供了比ASCII字段更广泛的地址封装方法。NSAP地址的结构（例如，e.164、ICD、DCC）在[AESA]中定义。
The Sub-Address number AVP MAY be present in ICRQ and OCRQ, and SHOULD only be available if the Called Party number is also within the message.
子地址号码AVP可能存在于ICRQ和OCRQ中，并且仅当被叫方号码也在消息中时才可用。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 26.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为0。此AVP的长度（隐藏前）为26。
This document requires IANA to allocate 6 new type values for the following AVPs (see section 5.2) :
本文件要求IANA为以下AVP分配6个新类型值（见第5.2节）：
- Rx Minimum BPS
- 最小接收BPS
- Rx Maximum BPS
- 最大接收BPS
- Service Category
- 服务类别
- Service Name
- 服务名称
- Calling Sub-Address
- 主叫子地址
- VPI/VCI Identifier
- VPI/VCI标识符
This document further defines a new bit (B) in the bearer capabilities and bearer type AVPs (section 5.3).
本文件进一步定义了承载能力和承载类型AVP中的新比特（B）（第5.3节）。
This document defines a flag field in the Service Category AVP, only one bit in this flag has been assigned within this document (S). Further assignments fall under the rule of "Specification Required", i.e. Values and their meaning must be documented in an RFC or other permanent and readily available reference, in sufficient detail so that interoperability between independent implementations is possible.
本文档在服务类别AVP中定义了一个标志字段，本文档中仅分配了该标志中的一位。进一步的分配属于“所需规范”的规则，即值及其含义必须记录在RFC或其他永久且随时可用的参考文件中，足够详细，以便独立实现之间的互操作性成为可能。
No extra security risk outside these specified by [RFC2661] are foreseen.
除[RFC2661]规定的安全风险外，不存在额外的安全风险。
The authors would like to thank Laurent Hermans for his work on earlier versions of this document, Juha Heinanen (Telia) and David Allen (Nortel Networks) for their constructive discussion on the document during the Minneapolis IETF meeting, Mark Townsley (cisco) for his hint on the use of the VPI/VCI identifier AVP.
作者要感谢Laurent Hermans在本文件早期版本上的工作，感谢Juha Heinanen（Telia）和David Allen（Nortel Networks）在明尼阿波利斯IETF会议期间对本文件进行的建设性讨论，感谢Mark Townsley（cisco）对VPI/VCI标识符AVP使用的提示。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Singh Pall, G., Zorn, G. and B. Palter, "Layer Two Tunnelling Protocol (L2TP)", RFC 2661, August 1999.
[RFC2661]汤斯利，W.，瓦伦西亚，A.，鲁本斯，A.，辛格·帕尔，G.，佐恩，G.和B.帕尔特，“第二层隧道协议（L2TP）”，RFC 26611999年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2364] Gross, G., Kaycee, M., Lin, A., Malis, A. and J. Stephens, "PPP over AAL5", RFC 2364, July 1998.
[RFC2364]Gross，G.，Kaycee，M.，Lin，A.，Malis，A.和J.Stephens，“AAL5上的购买力平价”，RFC 2364，1998年7月。
[UNI] User-Network Interface (UNI) Specification, Version 4.0, ATM Forum, July, 1996
[UNI]用户网络接口（UNI）规范，4.0版，ATM论坛，1996年7月
[AESA] ATM Forum Addressing : Reference Guide, version 1.0, ATM Forum, Final Ballot, January 1999
[AESA]ATM论坛地址：参考指南，1.0版，ATM论坛，最终投票，1999年1月
[L2TP_link] Townsley, M. and W. Palter, "L2TP Link Extensions", Work in Progress.
[L2TP链接]汤斯利，M.和W.帕尔特，“L2TP链接扩展”，正在进行中。
[Auto_PVC] ATM Forum, "Auto-configuration of PVCs", af-nm-0122.000, March 1999
[Auto_PVC]ATM论坛，“PVC的自动配置”，af-nm-0122.0001999年3月
[10646] ISO/IEC, Information Technology - Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane, May 1993, with amendments
[10646]ISO/IEC，信息技术-通用多八位编码字符集（UCS）-第1部分：体系结构和基本多语言平面，1993年5月，修订版
Yves T'joens Alcatel Network Strategy Group Francis Wellesplein 1, 2018 Antwerp, Belgium Phone : +32 3 240 7890 EMail : yves.tjoens@alcatel.be
Yves T'joens阿尔卡特网络战略集团Francis Welleslein 2018年1月1日比利时安特卫普电话：+32 3 240 7890电子邮件：Yves。tjoens@alcatel.be
Paolo Crivellari Belgacom bd du Roi Albert II 27 B-1030 Bruxelles Phone: +32 2 202 9698 EMail: paolo.crivellari@belgacom.be
保罗·克里维拉里·贝尔加科姆·杜罗·阿尔伯特二世27 B-1030布鲁塞尔电话：+322029698电子邮件：保罗。crivellari@belgacom.be
Bernard Sales Alcatel Network Strategy Group Francis Wellesplein 1, 2018 Antwerp, Belgium Phone : +32 3 240 9574 EMail : bernard.sales@alcatel.be
伯纳德销售阿尔卡特网络战略集团Francis Welleslein 2018年1月1日比利时安特卫普电话：+32 3 240 9574电子邮件：伯纳德。sales@alcatel.be
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编辑功能的资金目前由互联网协会提供。