Network Working Group G. Gross
Request for Comments: 2363 Lucent Technologies
Category: Standards Track M. Kaycee
Paradyne
A. Li
Shasta Networks
A. Malis
Ascend Communications
J. Stephens
Cayman Systems
July 1998
Network Working Group G. Gross
Request for Comments: 2363 Lucent Technologies
Category: Standards Track M. Kaycee
Paradyne
A. Li
Shasta Networks
A. Malis
Ascend Communications
J. Stephens
Cayman Systems
July 1998
PPP Over FUNI
购买力平价超过富尼
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 (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
点到点协议（PPP）[1]提供了通过点到点链路传输多协议数据报的标准方法。
This document describes the use of ATM Frame User Network Interface (FUNI) for framing PPP encapsulated packets.
本文档描述了ATM帧用户网络接口（FUNI）用于帧PPP封装数据包的使用。
Applicability
适用性
This specification is intended for those implementations which desire to use the facilities which are defined for PPP, such as the Link Control Protocol, Network-layer Control Protocols, authentication, and compression. These capabilities require a point-to-point relationship between the peers, and are not designed for the multi-point relationships which are available in ATM and other multi-access environments.
本规范适用于那些希望使用为PPP定义的设施的实现，例如链路控制协议、网络层控制协议、认证和压缩。这些功能需要对等点之间的点对点关系，而不是针对ATM和其他多址环境中可用的多点关系而设计的。
ATM FUNI protocol is designed to provide virtual connections between end stations attached to the same network. These connections offer a packet delivery service that includes error detection, but does not do error correction.
ATM FUNI协议旨在提供连接到同一网络的终端站之间的虚拟连接。这些连接提供包含错误检测但不进行错误纠正的数据包传递服务。
Most existing implementations of PPP use ISO 3309 HDLC as a basis for their framing [3].
大多数PPP的现有实现都使用ISO 3309 HDLC作为其框架的基础[3]。
When an ATM network is configured with point-to-point connections, PPP can use FUNI as a framing mechanism.
当ATM网络配置了点对点连接时，PPP可以使用FUNI作为帧机制。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [10].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、建议、可和可选时，应按照[10]中的说明进行解释。
The PPP layer treats the underlying ATM FUNI layer service as a bit-synchronous point-to-point link. In this context, the PPP link corresponds to an ATM FUNI virtual connection. The virtual connection MUST be full-duplex, point to point, and it MAY be either dedicated (i.e. permanent, set up by provisioning) or switched (set up on demand). In addition, the PPP/FUNI service interface boundary MUST meet the following requirements:
PPP层将底层ATM FUNI层服务视为位同步点到点链路。在此上下文中，PPP链路对应于ATM FUNI虚拟连接。虚拟连接必须是全双工的点对点连接，并且可以是专用连接（即永久连接，通过供应设置）或交换连接（按需设置）。此外，PPP/FUNI服务接口边界必须满足以下要求：
Interface Format - The PPP/FUNI layer boundary presents an octet service interface to the FUNI layer. There is no provision for sub-octets to be supplied or accepted.
接口格式-PPP/FUNI层边界向FUNI层提供八位字节服务接口。没有提供或接受子八位字节的规定。
Transmission Rate - The PPP layer does not impose any restrictions regarding transmission rate or the underlying ATM layer traffic descriptor parameters.
传输速率-PPP层不会对传输速率或底层ATM层流量描述符参数施加任何限制。
Control Signals - The FUNI layer MUST provide control signals to the PPP layer which indicate when the virtual connection link has become connected or disconnected. These provide the "Up" and
控制信号-FUNI层必须向PPP层提供控制信号，指示虚拟连接链路何时连接或断开。这些提供了“向上”和
"Down" events to the LCP state machine [1] within the PPP layer.
PPP层内LCP状态机[1]的“关闭”事件。
This specification uses the principles, terminology, and frame structure described in "Multiprotocol Encapsulation over ATM Adaptation Layer 5" [4].
本规范使用了“ATM适配层5上的多协议封装”[4]中描述的原理、术语和帧结构。
The purpose of this specification is not to document what is already standardized in [4], but to specify how the mechanisms described in [4] are to be used to map PPP onto a FUNI-based ATM network. Section 1 within [4] defines the two mechanisms for identifying the Protocol Data Unit (PDU) payload field's protocol type: virtual circuit based multiplexing, and Logical Link Control (LLC) encapsulation. In the former technique, the payload's protocol type is implicitly agreed to by the end points for each virtual circuit using provisioning or control plane procedures. When using the LLC encapsulation technique, the payload's protocol type is explicitly identified on a per PDU basis by an in-band LLC header, followed by the payload data.
本规范的目的不是记录[4]中已经标准化的内容，而是指定如何使用[4]中描述的机制将PPP映射到基于FUNI的ATM网络。[4]中的第1节定义了识别协议数据单元（PDU）有效负载字段的协议类型的两种机制：基于虚拟电路的多路复用和逻辑链路控制（LLC）封装。在前一种技术中，有效负载的协议类型由使用供应或控制平面过程的每个虚拟电路的端点隐式同意。使用LLC封装技术时，有效负载的协议类型在每个PDU的基础上由带内LLC报头显式标识，后跟有效负载数据。
When transporting a PPP payload over FUNI, an implementation:
当通过FUNI传输PPP有效负载时，实现：
1. MUST support virtual circuit multiplexed PPP payloads as described in section 5 below by mutual configuration or negotiation of both end points. This technique is referred to as "VC-multiplexed PPP".
1. 必须通过两个端点的相互配置或协商，支持下文第5节所述的虚拟电路多路复用PPP有效载荷。这种技术被称为“VC多路复用PPP”。
2. MUST support LLC encapsulated PPP payloads on PVCs as described in section 6 below by mutual configuration or negotiation of both end points. This technique is referred to as "LLC encapsulated PPP".
2. 必须通过相互配置或协商两个端点，在PVC上支持LLC封装的PPP有效载荷，如下文第6节所述。这种技术被称为“LLC封装PPP”。
3. For SVC set up, an implementation MUST negotiate using the Q.2931 [9] Annex C procedure, encoding the Broadband Lower Layer Interface (B-LLI) information element to signal either VC-multiplexed PPP or LLC encapsulated PPP. The details of this control plane procedure are described in section 7.
3. 对于SVC设置，实施必须使用Q.2931[9]附录C程序进行协商，对宽带低层接口（B-LLI）信息元素进行编码，以向VC多路复用PPP或LLC封装PPP发送信号。第7节描述了该控制平面程序的细节。
If an implementation is connecting through a Frame Relay/ATM FRF.8 [7] service inter-working unit to an RFC 1973 [6] end point, then it MUST use LLC encapsulated PPP payloads. Frame Relay/ATM FRF.8 inter-working units are exempted from the requirement to support VC-multiplexed PPP. This exemption allows the FR/ATM IWU to remain compliant with FRF.8 when the PPP over FUNI end point is inter-operating with an RFC 1973 end point.
如果实现通过帧中继/ATM FRF.8[7]服务交互工作单元连接到RFC 1973[6]端点，则必须使用LLC封装的PPP有效载荷。帧中继/ATM FRF.8互操作单元不需要支持VC多路复用PPP。当FUNI上的PPP端点与RFC 1973端点相互操作时，该豁免允许FR/ATM IWU保持符合FRF.8。
The FUNI protocol data unit (PDU) format [2] is as follows:
FUNI协议数据单元（PDU）格式[2]如下：
+-------------------------------+
| Flag |
+-------------------------------+---------
| FUNI Header | ^
+-------------------------------+ |
| | |
| | |
| User SDU | FUNI PDU
| | |
| | |
+-------------------------------+ |
| FUNI FCS (2 or 4 octets) | v
+-------------------------------+---------
| Flag |
+-------------------------------+
Figure 1
+-------------------------------+
| Flag |
+-------------------------------+---------
| FUNI Header | ^
+-------------------------------+ |
| | |
| | |
| User SDU | FUNI PDU
| | |
| | |
+-------------------------------+ |
| FUNI FCS (2 or 4 octets) | v
+-------------------------------+---------
| Flag |
+-------------------------------+
Figure 1
The FUNI Header includes a 10-bit or 24-bit Frame Address (a.k.a. VPI/VCI bits), a Congestion Notification bit, a Congestion Loss Priority bit, and four Reserved bits.
FUNI报头包括10位或24位帧地址（也称为VPI/VCI位）、拥塞通知位、拥塞丢失优先级位和四个保留位。
The User SDU field contains user information up to 4096 (optionally up to 64K) octets.
用户SDU字段包含最多4096（可选最多64K）个八位字节的用户信息。
The FCS field protects the entire FUNI PDU except for the FCS field itself.
FCS现场保护整个FUNI PDU，FCS现场除外。
A VC-multiplexed PPP frame SHALL constitute the User Service Data Unit (SDU) field and is defined as shown in figure 2:
VC多路复用PPP帧应构成用户服务数据单元（SDU）字段，其定义如图2所示：
+-------------+-------------+---------+
| Protocol ID | Information | Padding |
| 8/16 bits | | |
+-------------+-------------+---------+
Figure 2
+-------------+-------------+---------+
| Protocol ID | Information | Padding |
| 8/16 bits | | |
+-------------+-------------+---------+
Figure 2
Each of these fields are specifically defined in [1].
[1]中具体定义了这些字段。
LLC encapsulated PPP over FUNI is the alternative technique to VC-multiplexed PPP over FUNI.
LLC封装的FUNI PPP是VC复用的FUNI PPP的替代技术。
The FUNI SDU payload field is encoded as shown in figure 3. The pertinent fields in that diagram are:
FUNI SDU有效载荷字段编码如图3所示。该图中的相关字段为：
1. LLC header: 2 bytes encoded to specify a source SAP and destination SAP of routed OSI PDU (values 0xFE 0xFE), followed by an Un-numbered Information (UI) frame type (value 0x03).
1. LLC头：编码的2个字节，用于指定路由OSI PDU的源SAP和目标SAP（值0xFE 0xFE），后跟未编号信息（UI）帧类型（值0x03）。
2. Network Layer Protocol IDentifier (NLPID) representing PPP, (value 0xCF).
2. 表示PPP的网络层协议标识符（NLPID）（值0xCF）。
3. the PPP protocol identifier field, which can be either 1 or 2 octets long. See reference [1].
3. PPP协议标识符字段，长度可以为1或2个八位字节。见参考文献[1]。
4. followed by the PPP information field as per Figure 2.
4. 然后是PPP信息字段，如图2所示。
+-------------------------+ --------
| Destination SAP (0xFE) | ^
+-------------------------+ |
| Source SAP (0xFE) | LLC header
+-------------------------+ |
| Frame Type = UI (0x03) | V
+-------------------------+ --------
| NLPID = PPP (0xCF) |
+-------------------------+ --------
| Protocol Identifier | ^
| (8 or 16 bits) | |
+-------------------------+ PPP payload
| . | |
| . | |
| PPP information field | |
| . | |
| . | |
+-------------------------+ |
| padding | V
+-------------------------+ --------
| FUNI FCS (2 or 4 octets)| FUNI trailer
+-------------------------+---------
+-------------------------+ --------
| Destination SAP (0xFE) | ^
+-------------------------+ |
| Source SAP (0xFE) | LLC header
+-------------------------+ |
| Frame Type = UI (0x03) | V
+-------------------------+ --------
| NLPID = PPP (0xCF) |
+-------------------------+ --------
| Protocol Identifier | ^
| (8 or 16 bits) | |
+-------------------------+ PPP payload
| . | |
| . | |
| PPP information field | |
| . | |
| . | |
+-------------------------+ |
| padding | V
+-------------------------+ --------
| FUNI FCS (2 or 4 octets)| FUNI trailer
+-------------------------+---------
Figure 3
图3
The end points MAY be bi-laterally provisioned to send other LLC-encapsulated protocols besides PPP across the same virtual connection. However, they MUST NOT send packets belonging to any protocol that has an active NCP within the PPP session. Implementations SHOULD do packet scheduling that minimizes the performance impact on the quality of service commitments associated with both the LLC-encapsulated PPP and non-PPP protocol flows.
端点可以是双边配置的，以便在同一虚拟连接上发送除PPP之外的其他LLC封装协议。但是，它们不得发送属于PPP会话中具有活动NCP的任何协议的数据包。实现应该进行分组调度，以最大限度地减少对与LLC封装的PPP和非PPP协议流相关的服务质量承诺的性能影响。
When originating a switched virtual circuit FUNI connection, the caller MUST request in the SETUP message either VC-multiplexed PPP, LLC-encapsulated PPP, or else both VC-multiplexed and LLC-encapsulated PPP. When a caller is offering both techniques, the two B-LLI IEs are encoded within a Broadband Repeat Indicator IE in the order of their preference. The called implementation MUST be able to accept an incoming call that offers LLC-encapsulated PPP in the caller's request. The called implementation MUST reject a call set up request that only offers an encapsulation that it does not support. Implementations originating a call offering both protocol encapsulation techniques MUST be able to negotiate the use of LLC-encapsulated PPP.
发起交换虚拟电路FUNI连接时，调用者必须在设置消息中请求VC多路复用PPP、LLC封装PPP或VC多路复用PPP和LLC封装PPP。当呼叫者提供这两种技术时，两个B-LLI IE按照其偏好的顺序在宽带重复指示符IE中编码。被调用的实现必须能够接受在调用方的请求中提供LLC封装PPP的传入调用。被调用的实现必须拒绝只提供其不支持的封装的调用设置请求。发起同时提供协议封装技术的呼叫的实现必须能够协商LLC封装PPP的使用。
When originating a virtual circuit multiplexed call that is to carry a PPP payload, the ITU Q.2931 [9] B-LLI element user information layer 3 protocol field is encoded to select ISO/IEC TR 9577 [5] in octet 7. The extension octets specify an IPI value of PPP (0xCF). By definition, the first bytes of the FUNI frame's payload field will always contain a PPP header followed by a packet.
当发起承载PPP有效载荷的虚拟电路多路复用呼叫时，对ITU Q.2931[9]B-LLI元件用户信息层3协议字段进行编码，以选择八位字节7中的ISO/IEC TR 9577[5]。扩展八位字节指定PPP的IPI值（0xCF）。根据定义，FUNI帧的有效载荷字段的第一个字节将始终包含一个PPP头，后跟一个数据包。
When originating an LLC encapsulated call that is to carry a PPP payload, the ITU Q.2931 B-LLI element user information layer 2 protocol field is encoded to select LAN Logical Link Control (ISO/IEC8802-2) in octet 6. See RFC 1755 [8] appendix A for an example. By definition, the first bytes of the FUNI frame's payload field will contain an LLC header, followed by a NLPID and the PPP payload.
当发起LLC封装呼叫以承载PPP有效载荷时，对ITU Q.2931 B-LLI元素用户信息第2层协议字段进行编码，以选择八位字节6中的LAN逻辑链路控制（ISO/IEC8802-2）。有关示例，请参见RFC 1755[8]附录A。根据定义，FUNI帧的有效载荷字段的第一个字节将包含LLC头，后面是NLPID和PPP有效载荷。
When the virtual connection loses state, the PPP encapsulation technique may uni-laterally and unexpectedly change across such transitions. Detection and recovery procedures are defined for the following state transitions:
当虚拟连接失去状态时，PPP封装技术可能会在这种转换过程中发生单向和意外的变化。为以下状态转换定义了检测和恢复过程：
VC-multiplexed PPP changing to LLC encapsulated PPP
VC多路复用PPP转换为LLC封装PPP
LLC encapsulated PPP changing to VC-multiplexed PPP
LLC封装PPP改为VC复用PPP
When LLC-encapsulated PPP is being used, the inital 6 octets of the LCP packets contain the sequence: fe-fe-03-cf-c0-21. This sequence constitutes the first 6 octets of the FUNI frame. In the case of VC-multiplexed PPP, initial LCP packets contain the sequence c0-21.
当使用LLC封装的PPP时，LCP数据包的初始6个八位字节包含以下序列：fe-fe-03-cf-c0-21。该序列构成FUNI帧的前6个八位组。在VC多路复用PPP的情况下，初始LCP分组包含序列c0-21。
In the case of FUNI, this sequence follows the FUNI Header. When a LCP Configure-Request packet is received and recognized, the PPP link enters Link Establishment phase.
在FUNI的情况下，该序列跟随FUNI头。当接收并识别LCP配置请求包时，PPP链路进入链路建立阶段。
Once PPP has entered the Network-layer Protocol phase, and successfully negotiated a particular NCP for a PPP Protocol, if a frame arrives using an alternate but equivalent data encapsulation as defined in [4], then the PPP Link MUST:
一旦PPP进入网络层协议阶段，并成功协商PPP协议的特定NCP，如果帧使用[4]中定义的替代但等效的数据封装到达，则PPP链路必须：
For a SVC, immediately clear the call with the cause value 111, "protocol error, unspecified".
对于SVC，立即用原因值111“协议错误，未指定”清除调用。
For a PVC: tear down the active NCPs, SHOULD generate an error message, enter the Termination state, and silently drop all received packets.
对于PVC：拆除活动的NCP，应生成错误消息，进入终止状态，并静默删除所有接收到的数据包。
These policies prevent "black-holes" that occur when the peer loses state. An implementation which requires PPP link configuration, and other PPP negotiated features (such as authentication), MAY enter Termination state when configuration fails.
这些策略可防止对等方失去状态时出现“黑洞”。当配置失败时，需要PPP链路配置和其他PPP协商功能（如身份验证）的实现可能会进入终止状态。
The Magic Number LCP configuration option is RECOMMENDED, and the Protocol Field Compression (PFC) option is NOT RECOMMENDED. An implementation MUST NOT request any of the following options, and MUST reject a request for such an option:
建议使用幻数LCP配置选项，不建议使用协议字段压缩（PFC）选项。实施不得请求以下任何选项，且必须拒绝此类选项的请求：
Field Check Sequence (FCS) Alternatives,
现场检查顺序（FCS）备选方案，
Address-and-Control-Field-Compression (ACFC),
地址和控制字段压缩（ACFC），
Asynchronous-Control-Character-Map (ACCM)
异步控制字符映射（ACCM）
The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a larger size than the maximum CPCS-SDU size specified in the associated direction for the virtual connection's traffic contract.
最大接收单元（MRU）选项的协商大小不得大于虚拟连接流量协定的关联方向中指定的最大CPCS-SDU大小。
When viewed peer to peer, a PPP link may be bridged over multiple physical layer sections. For each such FUNI section, the LCP framing options MUST be actively negotiated by the bridging convertors independently of the LCP framing options in use by other physical layer sections.
当以对等方式查看时，PPP链路可以跨多个物理层部分桥接。对于每个这样的FUNI区段，桥接转换器必须主动协商LCP成帧选项，独立于其他物理层区段使用的LCP成帧选项。
Implementation Note: When an ATM FUNI PVC is in the "Stopped" state, it is RECOMMENDED that the implementation wait for Configure-Requests. See the implementation option in reference [1] section 4.2, the "Stopped State" sub-section.
实施说明：当ATM FUNI PVC处于“停止”状态时，建议实施等待配置请求。参见参考文献[1]第4.2节“停止状态”小节中的实施选项。
Generally, ATM networks are virtual circuit based, and security is implicit in the public data networking service provider's administration of Permanent Virtual Circuits (PVCs) between the network boundaries. The probability of a security breach caused by mis-routed ATM cells is considered to be negligible.
通常，ATM网络是基于虚拟电路的，公共数据网络服务提供商对网络边界之间的永久虚拟电路（PVC）的管理隐含着安全性。错误路由的ATM信元导致安全漏洞的概率被认为是可以忽略的。
When a public ATM network supports Switched Virtual Circuits, the protocol model becomes analogous to traditional voice band modem dial up over the Public Telephone Switched Network (PTSN). The same PAP/CHAP authentication protocols that are already widely in use for Internet dial up access are leveraged. As a consequence, PPP over FUNI security is at parity with those practices already established by the existing Internet infrastructure.
当公共ATM网络支持交换虚拟电路时，协议模型类似于通过公共电话交换网络（PTSN）的传统声带调制解调器拨号。已广泛用于Internet拨号访问的PAP/CHAP身份验证协议也得到了利用。因此，基于FUNI安全的PPP与现有互联网基础设施已经建立的实践不相上下。
Those applications that require stronger security are encouraged to use authentication headers, or encrypted payloads, and/or ATM-layer security services.
鼓励那些需要更强安全性的应用程序使用身份验证头、加密有效负载和/或ATM层安全服务。
When using LLC-encapsulated PPP over a virtual connection, an end point can not assume that the PPP session authentication and related security mechanisms also secure the other LLC encapsulated flows on that same virtual connection.
在虚拟连接上使用LLC封装的PPP时，端点不能假设PPP会话身份验证和相关安全机制也会保护同一虚拟连接上的其他LLC封装流。
This design is based on work performed in ADSL Forum's Packet Mode Working Group. It is inspired by "PPP in Frame Relay", RFC 1973, by William Simpson. Special thanks to Phil Rakity of Flowpoint, Tim Kwok of Microsoft, and David Allan of Nortel for their constructive review and commentary.
本设计基于ADSL论坛分组模式工作组的工作。它的灵感来源于威廉·辛普森的“PPP帧内中继”，RFC 1973。特别感谢Flowpoint的Phil Rakity、微软的Tim Kwok和北电的David Allan所作的建设性评论和评论。
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[1] 辛普森，W.，编辑，“点对点协议（PPP）”，STD 51，RFC 1661994年7月。
[2] The ATM Forum, "Frame based User-to-Network Interface (FUNI) Specification v2", af-saa-0088.000, May 1997.
[2] ATM论坛，“基于帧的用户到网络接口（FUNI）规范v2”，af-saa-0088.000，1997年5月。
[3] Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[3] 辛普森，W.，编辑，“HDLC类框架中的PPP”，STD 51，RFC 16621994年7月。
[4] Heinanen, J., "Multiprotocol Interconnect over AAL5", RFC 1483, July 1993.
[4] Heinanen，J.，“AAL5上的多协议互连”，RFC 1483，1993年7月。
[5] ISO/IEC DTR 9577.2, "Information technology - Telecommunications and Information exchange between systems - Protocol Identification in the network layer", 1995-08-16.
[5] ISO/IEC DTR 9577.2，“信息技术-系统间电信和信息交换-网络层协议识别”，1995-08-16。
[6] Simpson, W., "PPP in Frame Relay", RFC 1973, June 1996.
[6] 辛普森，W.，“PPP帧内中继”，RFC 1973，1996年6月。
[7] The Frame Relay Forum, "Frame Relay/ATM PVC Service Inter-working Implementation Agreement", FRF.8, April 1995.
[7] 帧中继论坛，“帧中继/ATM PVC业务互通实施协议”，FRF.8，1995年4月。
[8] Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D., and A. Malis, "ATM Signaling Support for IP over ATM", RFC 1755, February 1995.
[8] Perez，M.，Liaw，F.，Mankin，A.，Hoffman，E.，Grossman，D.，和A.Malis，“ATM上IP的ATM信令支持”，RFC 17551995年2月。
[9] International Telecommunication Union, "Broadband Integrated Service Digital Network (B-ISDN) Digital Subscriber Signaling System No.2 (DSS2) User Network Interface Layer 3 Specification for Basic Call/Connection Control", ITU-T Recommendation Q.2931, (International Telecommunication Union: Geneva, 2/95)
[9] 国际电信联盟，“宽带综合业务数字网（B-ISDN）数字用户信令系统第2号（DSS2）用户网络接口层3基本呼叫/连接控制规范”，ITU-T建议Q.2931，（国际电信联盟：日内瓦，2/95）
[10] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[10] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
Chair's Address
主席致辞
The working group can be contacted via the current chair:
可通过现任主席联系工作组：
Karl Fox Ascend Communications 3518 Riverside Drive, Suite 101 Columbus, Ohio 43221
俄亥俄州哥伦布河畔大道3518号101室卡尔·福克斯Ascend通信公司，邮编43221
EMail: karl@ascend.com
EMail: karl@ascend.com
Authors' Addresses
作者地址
Questions about this memo can also be directed to:
有关本备忘录的问题，请联系：
George Gross Lucent Technologies, Inc 184 Liberty Corner Road Warren, NJ 07059
乔治格罗斯朗讯科技有限公司新泽西州沃伦自由角路184号07059
Phone: +1.908.580.4589
EMail: gmgross@lucent.com
Phone: +1.908.580.4589
EMail: gmgross@lucent.com
Manu Kaycee Paradyne Corporation 21 Bear Meadow Road Londonderry, NH 03053-2168
新罕布什尔州伦敦德里熊草地路21号Manu Kaycee Paradyne Corporation 03053-2168
Phone: +1.603.434.6088
EMail: mjk@nj.paradyne.com
Phone: +1.603.434.6088
EMail: mjk@nj.paradyne.com
Arthur Lin Shasta Networks Inc. 249 Humboldt Court Sunnyvale, CA 94089-1300
Arthur Lin Shasta Networks Inc.加利福尼亚州桑尼维尔洪堡法院249号，邮编94089-1300
Phone: +1.408.747.5051
EMail: alin@shastanets.com
Phone: +1.408.747.5051
EMail: alin@shastanets.com
Andrew Malis Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886
马萨诸塞州韦斯特福德罗宾斯路1号安德鲁·马利斯·阿森德通信公司，邮编01886
Phone: +1.978.952.7414
EMail: malis@ascend.com
Phone: +1.978.952.7414
EMail: malis@ascend.com
John Stephens Cayman Systems, Inc. 100 Maple Street Stoneham, MA 02180
John Stephens Cayman Systems，Inc.马萨诸塞州斯通汉姆枫树街100号，邮编：02180
Phone: +1.617.279.1101
EMail: john@cayman.com
Phone: +1.617.279.1101
EMail: john@cayman.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。