Network Working Group A. Doria
Request for Comments: 3293 Lulea University of Technology
Category: Standards Track J. Buerkle
Nortel Networks
T. Worster
June 2002
Network Working Group A. Doria
Request for Comments: 3293 Lulea University of Technology
Category: Standards Track J. Buerkle
Nortel Networks
T. Worster
June 2002
General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP)
通用交换机管理协议（GSMP）异步传输模式（ATM）、以太网和传输控制协议（TCP）的数据包封装
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 memo specifies the encapsulation of GSMP (General Switch Management Protocol) packets in ATM (Asynchronous Transfer Mode), Ethernet and TCP (Transmission Control Protocol).
本备忘录规定了在ATM（异步传输模式）、以太网和TCP（传输控制协议）中封装GSMP（通用交换机管理协议）数据包。
Specification of Requirements
需求说明
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 [7].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[7]中所述进行解释。
GSMP messages are defined in [1] and MAY be encapsulated in several different protocols for transport. This memo specifies their encapsulation in ATM AAL-5, in Ethernet or in TCP. Other encapsulations may be defined in future specifications.
GSMP消息在[1]中定义，可以封装在几种不同的传输协议中。此备忘录指定了它们在ATM AAL-5、以太网或TCP中的封装。其他封装可能在将来的规范中定义。
GSMP packets are variable length and for an ATM data link layer they are encapsulated directly in an AAL-5 CPCS-PDU [3][4] with an LLC/SNAP header as illustrated:
GSMP数据包长度可变，对于ATM数据链路层，它们直接封装在AAL-5 CPCS-PDU[3][4]中，带有LLC/SNAP报头，如图所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LLC (0xAA-AA-03) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| SNAP (0x00-00-00-88-0C) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ GSMP Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pad (0 - 47 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ AAL-5 CPCS-PDU Trailer (8 bytes) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LLC (0xAA-AA-03) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| SNAP (0x00-00-00-88-0C) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ GSMP Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pad (0 - 47 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ AAL-5 CPCS-PDU Trailer (8 bytes) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(The convention in the documentation of Internet Protocols [5] is to express numbers in decimal. Numbers in hexadecimal format are specified by prefacing them with the characters "0x". Numbers in binary format are specified by prefacing them with the characters "0b". Data is pictured in "big-endian" order. That is, fields are described left to right, with the most significant byte on the left and the least significant byte on the right. Whenever a diagram shows a group of bytes, the order of transmission of those bytes is the normal order in which they are read in English. Whenever a byte represents a numeric quantity the left most bit in the diagram is the high order or most significant bit. That is, the bit labelled 0 is the most significant bit. Similarly, whenever a multi-byte field represents a numeric quantity the left most bit of the whole field is the most significant bit. When a multi-byte quantity is transmitted, the most significant byte is transmitted first. This is the same coding convention as is used in the ATM layer [2] and AAL-5 [3][4].)
（互联网协议文献[5]中的惯例是用十进制表示数字。十六进制格式的数字是通过在前面加上字符“0x”来指定的。二进制格式的数字是通过在前面加上字符“0b”来指定的。数据以“big-endian”表示。）顺序。也就是说，字段是从左到右描述的，最高有效字节在左边，最低有效字节在右边。每当图表显示一组字节时，这些字节的传输顺序是用英语读取的正常顺序。每当一个字节代表一个数字量时，最左边的位在e图是高阶或最高有效位。也就是说，标记为0的位是最高有效位。类似地，每当一个多字节字段表示一个数字量时，整个字段最左边的位就是最高有效位。当传输一个多字节量时，最高有效字节首先被传输。这就是sATM层[2]和AAL-5[3][4]中使用的ame编码约定。）
The LLC/SNAP header contains the bytes: 0xAA 0xAA 0x03 0x00 0x00 0x00 0x88 0x0C. (0x880C is the assigned Ethertype for GSMP.)
LLC/SNAP标头包含以下字节：0xAA 0xAA 0x03 0x00 0x00 0x00 0x88 0x0C。（0x880C是为GSMP分配的以太网类型。）
The maximum transmission unit (MTU) of the GSMP Message field is 1492 bytes.
GSMP消息字段的最大传输单位（MTU）为1492字节。
The virtual channel over which a GSMP session is established between a controller and the switch it is controlling is called the GSMP control channel. The default VPI and VCI of the GSMP control channel for LLC/SNAP encapsulated GSMP messages on an ATM data link layer is:
在控制器与其控制的交换机之间建立GSMP会话的虚拟通道称为GSMP控制通道。ATM数据链路层上LLC/SNAP封装GSMP消息的GSMP控制通道的默认VPI和VCI为：
VPI = 0 VCI = 15.
VPI=0，VCI=15。
The GSMP control channel MAY be changed using the GSMP MIB.
可以使用GSMP MIB更改GSMP控制通道。
GSMP packets MAY be encapsulated on an Ethernet data link as illustrated:
GSMP数据包可以封装在以太网数据链路上，如图所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype (0x88-0C) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
~ GSMP Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Check Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype (0x88-0C) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
~ GSMP Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Check Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Destination Address For the SYN message of the adjacency protocol the Destination Address is the broadcast address 0xFFFFFFFFFFFF. (Alternatively, it is also valid to configure the node with the unicast 48-bit IEEE MAC address of the destination. In this case the configured unicast Destination Address is used in the SYN message.) For all other messages the Destination Address is the unicast 48-bit
邻接协议SYN消息的目标地址目标地址是广播地址0xFFFFFFFFFF。（或者，使用目标的单播48位IEEE MAC地址配置节点也是有效的。在这种情况下，配置的单播目标地址用于SYN消息。）对于所有其他消息，目标地址为单播48位
IEEE. MAC address of the destination. This address may be discovered from the Source Address field of messages received during synchronisation of the adjacency protocol.
IEEE。目标的MAC地址。可以从在邻接协议的同步期间接收的消息的源地址字段中发现该地址。
Source Address For all messages, the Source Address is the 48-bit IEEE MAC address of the sender.
源地址对于所有消息，源地址是发送方的48位IEEE MAC地址。
Ethertype The assigned Ethertype for GSMP is 0x880C.
Ethertype为GSMP分配的Ethertype为0x880C。
GSMP Message The maximum transmission unit (MTU) of the GSMP Message field is 1492 bytes.
GSMP消息GSMP消息字段的最大传输单位（MTU）为1492字节。
Sender Instance The Sender Instance number for the link obtained from the adjacency protocol. This field is already present in the adjacency protocol message. It is appended to all non-adjacency GSMP messages in the Ethernet encapsulation to offer additional protection against the introduction of corrupt state.
Sender Instance从邻接协议获得的链路的发送方实例号。此字段已存在于邻接协议消息中。它附加到以太网封装中的所有非邻接GSMP消息中，以提供额外的保护，防止引入损坏状态。
Receiver Instance The Receiver Instance number is what the sender believes is the current instance number for the link, allocated by the entity at the far end of the link. This field is already present in the adjacency protocol message. It is appended to all non-adjacency GSMP messages in the Ethernet encapsulation to offer additional protection against the introduction of corrupt state.
接收方实例接收方实例号发送方认为是链路的当前实例号，由链路远端的实体分配。此字段已存在于邻接协议消息中。它附加到以太网封装中的所有非邻接GSMP消息中，以提供额外的保护，防止引入损坏状态。
Pad After adjacency has been established the minimum length of the data field of an Ethernet packet is 46 bytes. If necessary, padding should be added such that it meets the minimum Ethernet frame size. This padding should be bytes of zero and is not to be considered part of the GSMP message.
Pad建立邻接后，以太网数据包数据字段的最小长度为46字节。如有必要，应添加填充，使其满足最小以太网帧大小。此填充应为零字节，不应被视为GSMP消息的一部分。
Frame Check Sequence The Frame Check Sequence (FCS) is defined in IEEE 802.3 [6] as follows:
帧检查序列帧检查序列（FCS）在IEEE 802.3[6]中定义如下：
Note: This section is included for informational and historical purposes only. The normative reference can be found in IEEE 802.3 Standard [6].
注：本节仅用于信息和历史目的。标准参考可在IEEE 802.3标准[6]中找到。
"A cyclic redundancy check (CRC) is used by the transmit and receive algorithms to generate a CRC value for the FCS field. The frame check sequence (FCS) field contains a 4-byte (32-bit)
“发送和接收算法使用循环冗余校验（CRC）为FCS字段生成一个CRC值。帧校验序列（FCS）字段包含一个4字节（32位）
cyclic redundancy check (CRC) value. This value is computed as a function of the contents of the source address, destination address, length, LLC data and pad (that is, all fields except the preamble, SFD, FCS and extension). The encoding is defined by the following generating polynomial.
循环冗余校验（CRC）值。该值根据源地址、目标地址、长度、LLC数据和pad（即，除前导码、SFD、FCS和扩展外的所有字段）的内容进行计算。编码由以下生成多项式定义。
G(x)=x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^
7+x^5+x^4+x^2+x^1."
G(x)=x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^
7+x^5+x^4+x^2+x^1."
The procedure for the CRC calculation can be found in [6].
CRC计算程序见[6]。
After the adjacency protocol has achieved synchronisation, for every GSMP message received with an Ethernet encapsulation, the receiver must check the Source Address from the Ethernet MAC header, the Sender Instance, and the Receiver Instance. The incoming GSMP message must be discarded if the Sender Instance and the Source Address do not match the values of the Sender Instance and the Sender Name stored by the "Update Peer Verifier" operation of the GSMP adjacency protocol. The incoming GSMP message must also be discarded if it arrives over any port other than the port over which the adjacency protocol has achieved synchronisation. In addition, the incoming message must also be discarded if the Receiver Instance field does not match the current value for the Sender Instance of the GSMP adjacency protocol.
在邻接协议实现同步后，对于通过以太网封装接收的每个GSMP消息，接收器必须检查来自以太网MAC报头、发送方实例和接收器实例的源地址。如果发送方实例和源地址与GSMP邻接协议的“更新对等验证程序”操作存储的发送方实例和发送方名称的值不匹配，则必须丢弃传入的GSMP消息。如果传入的GSMP消息通过邻近协议已实现同步的端口以外的任何端口到达，则也必须丢弃该消息。此外，如果接收方实例字段与GSMP邻接协议的发送方实例的当前值不匹配，则也必须丢弃传入消息。
When GSMP messages are transported over an IP network, they MUST be transported using the TCP encapsulation. TCP provides reliable transport, network flow control, and end-system flow control suitable for networks that may have high loss and variable or unpredictable delay.
当GSMP消息通过IP网络传输时，必须使用TCP封装进行传输。TCP提供可靠的传输、网络流控制和终端系统流控制，适用于可能具有高损耗和可变或不可预测延迟的网络。
For TCP encapsulations of GSMP messages, the controller runs the client code and the switch runs the server code. Upon initialisation, the server is listening on GSMP's TCP port number: 6068. The controller establishes a TCP connection with each switch it manages. The switch under control MUST be a multi-connection server (PORT 6068) to allow creation of multiple control sessions from N GSMP controller instances. Adjacency protocol messages, which are used to synchronise the controller and switch and maintain handshakes, are sent by the controller to the switch after the TCP connection is established. GSMP messages other than adjacency protocol messages MUST NOT be sent until after the adjacency protocol has achieved synchronisation. The actual GSMP message flow will occur on other ports.
对于GSMP消息的TCP封装，控制器运行客户机代码，交换机运行服务器代码。初始化时，服务器正在侦听GSMP的TCP端口号：6068。控制器与它管理的每个交换机建立TCP连接。受控交换机必须是多连接服务器（端口6068），以允许从N个GSMP控制器实例创建多个控制会话。用于同步控制器和交换机并保持握手的邻接协议消息在TCP连接建立后由控制器发送到交换机。在邻接协议实现同步之前，不得发送除邻接协议消息以外的GSMP消息。实际的GSMP消息流将发生在其他端口上。
GSMP messages are sent over a TCP connection. A GSMP message is processed only after it is entirely received. A four-byte TLV header field is prepended to the GSMP message to provide delineation of GSMP messages within the TCP stream.
GSMP消息通过TCP连接发送。只有在完全接收到GSMP消息后，才会对其进行处理。GSMP消息前面有一个四字节的TLV头字段，用于描述TCP流中的GSMP消息。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ GSMP Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ GSMP Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type This 2-byte field indicates the type code of the following message. The type code for GSMP messages is 0x88-0C (i.e., the same as GSMP's Ethertype).
键入此2字节字段指示以下消息的类型代码。GSMP消息的类型代码为0x88-0C（即与GSMP的Ethertype相同）。
Length This 2-byte unsigned integer indicates the total length of the GSMP message only. It does not include the 4-byte TLV header.
长度此2字节无符号整数仅表示GSMP消息的总长度。它不包括4字节TLV头。
When GSMPv3 is implemented for use in IP networks, provisions for security between the controller and client MUST be available and MUST be provided by IP Security [IPSEC]. In this case, the IPSEC Encapsulation Security Payload (ESP) MUST be used to provide both integrity and confidentiality.
当GSMPv3用于IP网络时，控制器和客户端之间的安全规定必须可用，并且必须由IP安全[IPSEC]提供。在这种情况下，必须使用IPSEC封装安全负载（ESP）来提供完整性和机密性。
The security of GSMP's TCP/IP control channel has been addressed in Section 4.2. For all uses of GSMP over an IP network it is REQUIRED that GSMP be run over TCP/IP using the security considerations discussed in Section 4.2. Security using ATM and Ethernet encapsulations MAY be provided at the link layer. Discussion of these methods is beyond the scope of this specification. For secure operation over any media, the IP encapsulation with IPsec SHOULD be used.
GSMP的TCP/IP控制通道的安全性已在第4.2节中说明。对于通过IP网络使用GSMP的所有情况，需要使用第4.2节中讨论的安全注意事项通过TCP/IP运行GSMP。可以在链路层提供使用ATM和以太网封装的安全性。对这些方法的讨论超出了本规范的范围。为了在任何介质上进行安全操作，应使用IPsec的IP封装。
References
工具书类
[1] Doria, A., Sundell, K., Hellstrand, F. and T. Worster, "General Switch Management Protocol (GSMP) V3", RFC 3292, June 2002.
[1] Doria，A.，Sundell，K.，Hellstrand，F.和T.Worster，“通用交换机管理协议（GSMP）V3”，RFC 3292，2002年6月。
[2] "B-ISDN ATM Layer Specification," International Telecommunication Union, ITU-T Recommendation I.361, Feb. 1999.
[2] “B-ISDN ATM层规范”，国际电信联盟，ITU-T建议I.3611999年2月。
[3] "B-ISDN ATM Adaptation Layer (AAL) Specification," International Telecommunication Union, ITU-T Recommendation I.363, Mar. 1993.
[3] “B-ISDN ATM适配层（AAL）规范”，国际电信联盟，ITU-T建议I.363，1993年3月。
[4] "B-ISDN ATM Adaptation Layer specification: Type 5 AAL", International Telecommunication Union, ITU-T Recommendation I.363.5, Aug. 1996.
[4] “B-ISDN ATM适配层规范：5型AAL”，国际电信联盟，ITU-T建议I.363.5，1996年8月。
[5] Reynolds, J., Editor, "Assigned Numbers", RFC 3232, January 2002.
[5] 雷诺兹，J.，编辑，“分配的数字”，RFC 3232，2002年1月。
[6] IEEE Std 802.3, 1998 Edition "Information technology-Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications"
[6] IEEE标准802.31998版“系统间信息技术电信和信息交换-局域网和城域网-特定要求-第3部分：带冲突检测的载波侦听多址（CSMA/CD）接入方法和物理层规范”
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[7] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
Authors' Addresses
作者地址
Tom Worster
汤姆沃斯特
Phone: +1 617 247 2624
EMail: fsb@thefsb.org
Phone: +1 617 247 2624
EMail: fsb@thefsb.org
Avri Doria Div. of Computer Communications Lulea University of Technology S-971 87 Lulea Sweden
Lulea科技大学计算机通信系Avri Doria Div. -瑞典87
Phone: +1 401 663 5024
EMail: avri@acm.com
Phone: +1 401 663 5024
EMail: avri@acm.com
Joachim Buerkle Nortel Networks Germany GmbH & Co. KG Hahnstr. 37-39 60528 Frankfurt am Main Germany
Joachim Buerkle Nortel Networks Germany GmbH&Co.KG Hahnstr。37-39德国缅因州法兰克福60528
EMail: Joachim.Buerkle@nortelnetworks.com
EMail: Joachim.Buerkle@nortelnetworks.com
Full Copyright Statement
完整版权声明
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编辑功能的资金目前由互联网协会提供。