Network Working Group B. Volz
Request for Comments: 3074 Ericsson
Category: Standards Track S. Gonczi
Network Engines, Inc.
T. Lemon
Internet Engines, Inc.
R. Stevens
Join Systems, Inc.
February 2001
Network Working Group B. Volz
Request for Comments: 3074 Ericsson
Category: Standards Track S. Gonczi
Network Engines, Inc.
T. Lemon
Internet Engines, Inc.
R. Stevens
Join Systems, Inc.
February 2001
DHC Load Balancing Algorithm
DHC负载平衡算法
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 (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This document proposes a method of algorithmic load balancing. It enables multiple, cooperating servers to decide which one should service a client, without exchanging any information beyond initial configuration.
本文提出了一种算法负载平衡方法。它使多个协作的服务器能够决定哪个服务器应该为客户机提供服务，而无需交换初始配置以外的任何信息。
The server selection is based on the servers hashing client Media Access Control (MAC) addresses when multiple Dynamic Host Configuration Protocol (DHCP) servers are available to service DHCP clients. The proposed technique provides for efficient server selection when multiple DHCP servers offer services on a network without requiring any changes to existing DHCP clients. The same method is proposed to select the target server of a forwarding agent such as a Bootstrap Protocol (BOOTP) relay.
当多个动态主机配置协议（DHCP）服务器可用于服务DHCP客户端时，服务器选择基于服务器哈希客户端媒体访问控制（MAC）地址。当多个DHCP服务器在网络上提供服务而不需要对现有DHCP客户端进行任何更改时，所提出的技术提供了高效的服务器选择。建议使用相同的方法来选择转发代理（如引导协议（BOOTP）中继）的目标服务器。
This protocol was originally devised to support a specific load balancing optimization of the DHCP Failover Protocol [FAILOVR]. The authors later realized that it could be used to optimize the behavior of cooperating DHCP servers and the BOOTP relay agents that forward packets to them. The proposal makes it possible to set up each
该协议最初设计用于支持DHCP故障切换协议[FAILOVR]的特定负载平衡优化。作者后来意识到，它可以用来优化协作的DHCP服务器和向它们转发数据包的BOOTP中继代理的行为。该提案使建立每个
participating server to accept a preconfigured (approximate) percentage of the client load. This is done using a deterministic hashing algorithm, that could easily be applied to other protocols having similar characteristics.
参与服务器接受预配置（近似）的客户端负载百分比。这是使用确定性散列算法完成的，该算法可以很容易地应用于具有类似特性的其他协议。
This section discusses both the generic requirements terminology common to many IETF protocol specifications, and also terminology introduced by this document.
本节讨论许多IETF协议规范通用的通用需求术语，以及本文档介绍的术语。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC 2119]中的说明进行解释。
This document introduces the following terms:
本文件介绍了以下术语：
Service Delay, SD A load balancing parameter, allowing delayed service of a client by a server participating in the load-balancing scheme, instead of ignoring the client.
服务延迟，SD是一个负载平衡参数，允许参与负载平衡方案的服务器延迟客户端的服务，而不是忽略客户端。
Hash Bucket Assignments, HBA A configuration directive that assigns a set of hash bucket values to a server participating in the load-balancing scheme.
Hash Bucket Assignments，HBA一种配置指令，用于向参与负载平衡方案的服务器分配一组Hash Bucket值。
Server ID, SID An identifier that can be used to designate one of the participating Servers. In the context of DHCP, the SID is the IP address or DNS name of the server.
服务器ID，SID可用于指定一个参与服务器的标识符。在DHCP上下文中，SID是服务器的IP地址或DNS名称。
Service Transaction, ST A set of client-server exchanges that lead to a server providing or denying some service to a client. Example: the DISCOVER/OFFER/ REQUEST/ACK message exchange between a DHCP server and client is a service transaction.
服务事务，ST一组客户机-服务器交换，导致服务器向客户机提供或拒绝某些服务。示例：DHCP服务器和客户端之间的发现/提供/请求/确认消息交换是一个服务事务。
Service Transaction ID, STID An attribute of the individual client requests used for load-balancing.
服务事务ID，STID用于负载平衡的单个客户端请求的属性。
Because DHCP clients use UDP broadcasts to contact DHCP servers, a client DHCPDISCOVER message may be received by more than one server. All servers receiving such a broadcast may respond to the client, letting the client choose which server it will use.
由于DHCP客户端使用UDP广播与DHCP服务器联系，因此多个服务器可能会收到客户端DHCPDISCOVER消息。接收这种广播的所有服务器都可以响应客户机，让客户机选择要使用的服务器。
When a BOOTP relay agent is used, it typically forwards or rebroadcasts client broadcasts to all configured servers, so a similar inefficiency is present.
当使用BOOTP中继代理时，它通常将客户端广播转发或重播到所有配置的服务器，因此存在类似的低效率。
The optimization described allows a server to be chosen for each such
transaction by performing a "serve" / "do not serve" computation. A
forwarding agent can perform the same computation to choose a
forwarding destination.
The optimization described allows a server to be chosen for each such
transaction by performing a "serve" / "do not serve" computation. A
forwarding agent can perform the same computation to choose a
forwarding destination.
In either case, the choice of server can be computed, without the participants having to negotiate who is to respond.
在这两种情况下，都可以计算服务器的选择，而无需参与者协商谁来响应。
The approach is probabilistic in nature, because it is nearly impossible to foresee which client will request service next. For short periods of time, the actual percentage of clients served by a given server will likely deviate from the desired percentage. As the number of requests grows, the actual percentage of the load being handled by each server will approximate the configured percentage.
这种方法本质上是概率的，因为几乎不可能预测下一个请求服务的客户机。在短时间内，由给定服务器提供服务的客户端的实际百分比可能会偏离期望的百分比。随着请求数量的增加，每个服务器处理的负载的实际百分比将接近配置的百分比。
DHCP servers MUST use the Client Identifier option as the STID if it is present. If no Client Identifier option is present, the hlen field of the DHCP packet MUST be used as the length of the data to be hashed, and the contents of the chaddr MUST be the data to be hashed. At most the first sixteen bytes of the Client Identifier or chaddr are used.
DHCP服务器必须使用客户端标识符选项作为STID（如果存在）。如果不存在客户机标识符选项，则必须使用DHCP数据包的hlen字段作为要散列的数据长度，并且chaddr的内容必须是要散列的数据。最多使用客户端标识符或chaddr的前16个字节。
The proposal maps the STID into a hash value using the function in section 6. The resulting hash value can then be used to decide who should respond to the request, or who the forwarding target should be.
该方案使用第6节中的函数将STID映射为哈希值。然后，可以使用得到的散列值来决定谁应该响应请求，或者谁应该是转发目标。
The provided hash function generates hash values 0 to 255, and yields a fairly even hash bucket distribution for random STID-s, and also for STID sequences that have some pattern. Resource allocation is accomplished by assigning a set of specific hash values to each participating server.
提供的散列函数生成散列值0到255，并为随机STID-s以及具有某种模式的STID序列生成相当均匀的散列桶分布。资源分配是通过向每个参与服务器分配一组特定的哈希值来完成的。
A server will only service a request if the STID hash of the request matches one of its assigned hash values.
只有当请求的STID哈希值与其分配的哈希值之一匹配时，服务器才会为请求提供服务。
Any hash buckets not assigned to servers will result in some client ST-s being entirely ignored. (In some scenarios, this may be a desirable outcome.) STID-s need not be unique, but should have sufficient variety to distribute load to each server.
任何未分配给服务器的哈希桶都将导致某些客户端ST-s被完全忽略。（在某些情况下，这可能是一个理想的结果。）STID-s不需要是唯一的，但应该有足够的多样性来将负载分配给每个服务器。
HBA-s MAY be transmitted as messages, encapsulated in messages of some other protocol, e.g., e-mail, or DHCP Failover Protocol option.
HBA-s可以作为消息传输，封装在一些其他协议的消息中，例如电子邮件或DHCP故障切换协议选项。
DHCP server implementations may optionally be configurable to handle a case where load balancing is being done but the server that is supposed to respond is not available, or is out of suitable addresses.
DHCP服务器实现可以选择性地进行配置，以处理正在进行负载平衡但应该响应的服务器不可用或没有合适的地址的情况。
DHCP server implementations that provide this capability SHOULD set the DS (Delayed Service) configuration parameter to the number of seconds to wait after the client's first request has been sent before responding to a client, where the hash would not normally permit the client to be served.
提供此功能的DHCP服务器实现应将DS（延迟服务）配置参数设置为在发送客户端的第一个请求后，在响应客户端之前等待的秒数，而哈希通常不允许为客户端提供服务。
A DHCP server providing this capability SHOULD use the value in the secs field of the client request if its value is not zero. Because some clients may not correctly implement the secs field, a DHCP server MAY keep track of the first instance of a client transaction to which it would not normally respond. If the server receives a request from a client that has the same transaction ID as a previously recorded request, and if the secs field in the second packet is zero, the DHCP server MAY use the elapsed time (seconds) between the first and subsequent client request, instead of the secs field.
如果提供此功能的DHCP服务器的值不为零，则应使用客户端请求的secs字段中的值。由于某些客户端可能无法正确实现secs字段，DHCP服务器可能会跟踪其通常不会响应的客户端事务的第一个实例。如果服务器从与先前记录的请求具有相同事务ID的客户机接收到请求，并且如果第二个数据包中的secs字段为零，则DHCP服务器可以使用第一个和后续客户机请求之间经过的时间（秒），而不是secs字段。
The configuration step consists of assigning hash values to available servers. This is accomplished by providing one or more Hash Bucket Assignments (HBA-s). These may come from a configuration file, the Windows NT registry, EEPROM, etc. Alternatively, the hash bucket values could be assigned using some agreed upon algorithm. E.g., "Every odd value is serviced by server A and every even value is serviced by server B".
配置步骤包括为可用服务器分配哈希值。这是通过提供一个或多个哈希桶分配（HBA-s）来实现的。这些可能来自配置文件、Windows NT注册表、EEPROM等。或者，可以使用某种商定的算法分配哈希桶值。例如，“每个奇数值由服务器A提供服务，每个偶数值由服务器B提供服务”。
When configuring one specific server, an HBA in the form of a simple bit map of 32 octet values SHOULD be used.
配置一台特定服务器时，应使用32个八位字节值的简单位图形式的HBA。
The first octet in the HBA bitmap represents HBA values 0-7, the next byte values 8-15, and so on, with the thirty-second octet representing values 248-255. In each octet, the least significant bit in that octet represents the smallest HBA value in that octet.
HBA位图中的第一个八位字节表示HBA值0-7，下一个字节值8-15，依此类推，第三十二个八位字节表示值248-255。在每个八位字节中，该八位字节中的最低有效位表示该八位字节中的最小HBA值。
Each bit of the HBA is associated with one possible hash value. If a bit is set in the map, it means the recipient server MUST service each client request, where the STID yields the corresponding hash value.
HBA的每一位都与一个可能的哈希值相关联。如果在映射中设置了位，则意味着接收方服务器必须为每个客户端请求提供服务，其中STID生成相应的哈希值。
For example, if a server is configured with an HBA of the following 32 octets:
例如，如果服务器配置了具有以下32个八位字节的HBA：
FF FF FF FF FF FF 00 00 ( 0 - 63 ) FF FF FF FF FF FF FF FF ( 64 - 127 ) 00 00 00 00 00 00 00 00 (128 - 191 ) 00 00 00 00 00 00 00 00 (192 - 255 )
FF FF FF FF FF 00 00（0-63）FF FF FF FF FF FF FF FF FF FF FF（64-127）00 00 00 00 00（128-191）00 00 00 00（192-255）
then it MUST service any client requests where the STID hashes into the bucket values of 0 through 47 and 64 through 127.
然后，它必须为STID散列到0到47和64到127的bucket值的任何客户端请求提供服务。
The Delayed Service parameter is optional.
延迟服务参数是可选的。
If the parameter is not configured, the HBA sets up a strict Serve/Do not serve policy.
如果未配置该参数，HBA将设置严格的服务/不服务策略。
If the parameter is configured, the server that is not supposed to serve a specific request (based on the HBA and the STID hash), is allowed to respond, after S seconds have elapsed since the client first attempted to get service. A server MAY use the secs field in the BOOTP header for determining the time since the client has been trying to get service, or it MAY track repeated requests some other way.
如果配置了该参数，则允许不应为特定请求提供服务的服务器（基于HBA和STID哈希）在客户端首次尝试获取服务后经过S秒后作出响应。服务器可以使用BOOTP头中的secs字段来确定自客户端尝试获取服务以来的时间，也可以通过其他方式跟踪重复请求。
When configuring a forwarding agent, (e.g., BOOTP relay) HBA-s consisting of pairs of Server-ID / Hash Bucket values MAY be used.
配置转发代理时，可以使用由成对的服务器ID/哈希桶值组成的HBA-s（例如BOOTP中继）。
Here, the Server ID (SID) designates the server responsible for the specified Hash Bucket. The forwarding agent forwards each client request, where the STID yields the specified hash value, to the server designated by the SID.
这里，服务器ID（SID）指定负责指定哈希桶的服务器。转发代理将每个客户端请求（其中STID产生指定的哈希值）转发到SID指定的服务器。
The Server ID may be any unique server attribute, (e.g., IP address, DNS name, etc.) that is meaningful in the context of the relay agent operation.
服务器ID可以是在中继代理操作的上下文中有意义的任何唯一服务器属性（例如，IP地址、DNS名称等）。
A forwarder may be configured to forward a given packet to more than one server. For example, a BOOTP relay could be set up to split the load between 2 primary-backup server pairs, each pair running the DHCP Failover Protocol [FAILOVR]. In this case, a packet that is intended for a server pair Will have to be forwarded to both the primary, and the secondary server of the pair.
转发器可被配置为将给定分组转发到多个服务器。例如，可以设置一个BOOTP中继来在2个主备份服务器对之间分配负载，每对都运行DHCP故障转移协议[FAILOVR]。在这种情况下，用于服务器对的数据包必须转发到该对的主服务器和辅助服务器。
A possible configuration file for a forwarding agent (e.g., BOOTP relay) may look like this:
转发代理（例如BOOTP中继）的可能配置文件可能如下所示：
192.33.43.11 192.33.43.12: 0..24;
192.33.43.13: 25..55;
192.33.43.15: 56..128;
192.33.43.16: 129 130 131 200..202;
192.33.43.11 192.33.43.12: 0..24;
192.33.43.13: 25..55;
192.33.43.15: 56..128;
192.33.43.16: 129 130 131 200..202;
The above configuration consists of 4 HBA-s. The first HBA example reads: "Any Client request, where the STID yields a hash value 0 to 24, will be forwarded to both server 192.33.43.11 and 192.33.43.12".
上述配置由4个HBA-s组成。第一个HBA示例显示：“任何客户端请求（其中STID产生的哈希值为0到24）都将转发到服务器192.33.43.11和192.33.43.12”。
The 4th HBA example states: "Any Client request, where the STID yields a hash value 129,139,131,200,201 or 202, will be forwarded to server 192.33.43.16.
第四个HBA示例说明：“任何客户端请求，其中STID产生的哈希值为129139131200201或202，都将转发到服务器192.33.43.16。
The following hash function is a C language implementation of the algorithm known as "Pearson's hash". The Pearson's hash algorithm was originally published in [PEARSON].
下面的散列函数是一个C语言实现的称为“皮尔逊散列”的算法。Pearson的哈希算法最初发表在[Pearson]上。
The hash function is computationally inexpensive, requires an array lookup and xor operation for each key byte. To make this proposal work, all interoperable implementations MUST use this hash function, with the set of mixing table values given below:
哈希函数的计算成本很低，需要对每个密钥字节进行数组查找和异或操作。要使此方案有效，所有可互操作的实现必须使用此哈希函数，混合表值集如下所示：
/* A "mixing table" of 256 distinct values, in pseudo-random order. */
/* A "mixing table" of 256 distinct values, in pseudo-random order. */
unsigned char loadb_mx_tbl[256] ={ 251, 175, 119, 215, 81, 14, 79, 191, 103, 49, 181, 143, 186, 157, 0, 232, 31, 32, 55, 60, 152, 58, 17, 237, 174, 70, 160, 144, 220, 90, 57, 223, 59, 3, 18, 140, 111, 166, 203, 196, 134, 243, 124, 95, 222, 179, 197, 65, 180, 48, 36, 15, 107, 46, 233, 130, 165, 30, 123, 161, 209, 23, 97, 16, 40, 91, 219, 61, 100, 10, 210, 109, 250, 127, 22, 138, 29, 108, 244, 67, 207, 9, 178, 204, 74, 98, 126, 249, 167, 116, 34, 77, 193, 200, 121, 5, 20, 113, 71, 35, 128, 13, 182, 94, 25, 226, 227, 199, 75,
无符号字符加载b_mx_tbl[256]={ 251, 175, 119, 215, 81, 14, 79, 191, 103, 49, 181, 143, 186, 157, 0, 232, 31, 32, 55, 60, 152, 58, 17, 237, 174, 70, 160, 144, 220, 90, 57, 223, 59, 3, 18, 140, 111, 166, 203, 196, 134, 243, 124, 95, 222, 179, 197, 65, 180, 48, 36, 15, 107, 46, 233, 130, 165, 30, 123, 161, 209, 23, 97, 16, 40, 91, 219, 61, 100, 10, 210, 109, 250, 127, 22, 138, 29, 108, 244, 67, 207, 9, 178, 204, 74, 98, 126, 249, 167, 116, 34, 77, 193, 200, 121, 5, 20, 113, 71, 35, 128, 13, 182, 94, 25, 226, 227, 199, 75,
27, 41, 245, 230, 224, 43, 225, 177, 26, 155, 150, 212, 142, 218, 115, 241, 73, 88, 105, 39, 114, 62, 255, 192, 201, 145, 214, 168, 158, 221, 148, 154, 122, 12, 84, 82, 163, 44, 139, 228, 236, 205, 242, 217, 11, 187, 146, 159, 64, 86, 239, 195, 42, 106, 198, 118, 112, 184, 172, 87, 2, 173, 117, 176, 229, 247, 253, 137, 185, 99, 164, 102, 147, 45, 66, 231, 52, 141, 211, 194, 206, 246, 238, 56, 110, 78, 248, 63, 240, 189, 93, 92, 51, 53, 183, 19, 171, 72, 50, 33, 104, 101, 69, 8, 252, 83, 120, 76, 135, 85, 54, 202, 125, 188, 213, 96, 235, 136, 208, 162, 129, 190, 132, 156, 38, 47, 1, 7, 254, 24, 4, 216, 131, 89, 21, 28, 133, 37, 153, 149, 80, 170, 68, 6, 169, 234, 151 };
27, 41, 245, 230, 224, 43, 225, 177, 26, 155, 150, 212, 142, 218, 115, 241, 73, 88, 105, 39, 114, 62, 255, 192, 201, 145, 214, 168, 158, 221, 148, 154, 122, 12, 84, 82, 163, 44, 139, 228, 236, 205, 242, 217, 11, 187, 146, 159, 64, 86, 239, 195, 42, 106, 198, 118, 112, 184, 172, 87, 2, 173, 117, 176, 229, 247, 253, 137, 185, 99, 164, 102, 147, 45, 66, 231, 52, 141, 211, 194, 206, 246, 238, 56, 110, 78, 248, 63, 240, 189, 93, 92, 51, 53, 183, 19, 171, 72, 50, 33, 104, 101, 69, 8, 252, 83, 120, 76, 135, 85, 54, 202, 125, 188, 213, 96, 235, 136, 208, 162, 129, 190, 132, 156, 38, 47, 1, 7, 254, 24, 4, 216, 131, 89, 21, 28, 133, 37, 153, 149, 80, 170, 68, 6, 169, 234, 151 };
unsigned char loadb_p_hash(
const unsigned char *key, /* The key to be hashed */
const int len ) /* Key length in bytes */
{
unsigned char hash = len;
int i;
unsigned char loadb_p_hash(
const unsigned char *key, /* The key to be hashed */
const int len ) /* Key length in bytes */
{
unsigned char hash = len;
int i;
for (i=len ; i > 0 ; )
hash = loadb_mx_tbl [ hash ^ key[ --i ] ];
for (i=len ; i > 0 ; )
hash = loadb_mx_tbl [ hash ^ key[ --i ] ];
return( hash );
}
return( hash );
}
int accept_service_request(
const unsigned char HBA[32], /* The hash bucket bitmap */
const unsigned char *key, /* The service transaction id
*/
const int len ) /* length of the above */
{
unsigned char hash = loadb_p_hash(key,len);
int index = (hash >> 3) & 31;
int bitmask = 1 << (hash & 7);
int accept_service_request(
const unsigned char HBA[32], /* The hash bucket bitmap */
const unsigned char *key, /* The service transaction id
*/
const int len ) /* length of the above */
{
unsigned char hash = loadb_p_hash(key,len);
int index = (hash >> 3) & 31;
int bitmask = 1 << (hash & 7);
/* return 1 if we should service this transaction */
return((HBA[index] & bitmask) != 0);
}
/* return 1 if we should service this transaction */
return((HBA[index] & bitmask) != 0);
}
This proposal in and by itself provides no security, nor does it impact existing security. Servers using this algorithm are responsible for ensuring that if the contents of the HBA are transmitted over the network as part of the process of configuring any server, that message be secured against tampering, since tampering with the HBA could result in denial of service for some or all clients.
这项建议本身并没有提供任何安全保障，也不影响现有的安全保障。使用此算法的服务器负责确保，如果在配置任何服务器的过程中通过网络传输HBA的内容，则该消息不会被篡改，因为篡改HBA可能会导致部分或所有客户端拒绝服务。
[FAILOVR] Kinnear, K,, Droms, R., Rabil, G., Dooley, M., Kapur, A., Gonczi, S. and B. Volz, "DHCP Failover Protocol", Work in Progress.
[FAILOVR]Kinnear，K，，Droms，R.，Rabil，G.，Dooley，M.，Kapur，A.，Gonczi，S.和B.Volz，“DHCP故障转移协议”，工作正在进行中。
[PEARSON] The Communications of the ACM Vol.33, No. 6 (June 1990), pp. 677-680.
[PEARSON]ACM通讯第33卷，第6期（1990年6月），第677-680页。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[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月。
Special thanks to Peter K. Pearson, the author of Pearson's hash who has kindly granted his permission to use his algorithm, free of any encumbrances.
特别感谢Pearson's hash的作者Peter K.Pearson，他友好地同意使用他的算法，没有任何障碍。
This proposal stems from the original idea of hashing MAC addresses to a single bit by Ted Lemon, during a Failover Protocol discussion held at CISCO Systems in February, 1999. Rob Stevens suggested the potential use of this algorithm for purposes beyond those of the Failover Protocol.
这项建议源于Ted Lemon在1999年2月CISCO Systems举行的故障切换协议讨论中提出的将MAC地址散列为一个位的原始想法。Rob Stevens建议将此算法用于故障转移协议之外的用途。
Many thanks to Ralph Droms, Kim Kinnear, Mark Stapp, Glenn Waters, Greg Rabil and Jack Wong for their comments during the ongoing discussions.
非常感谢拉尔夫·德罗姆斯、金·金尼尔、马克·斯塔普、格伦·沃特斯、格雷格·拉比尔和杰克·王在正在进行的讨论中所作的评论。
Bernie Volz Ericsson 959 Concord Street Framingham, MA 01701
伯尼·沃兹·爱立信马萨诸塞州弗雷明翰康科德街959号01701
Phone: +1-617-513-9060
EMail: bernie.volz@ericsson.com
Phone: +1-617-513-9060
EMail: bernie.volz@ericsson.com
Steve Gonczi Network Engines, Inc. 25 Dan Road Canton, MA 02021-2817
Steve Gonczi网络引擎公司，地址：马萨诸塞州广州丹路25号02021-2817
Phone: 781-332-1165 EMail: steve.gonczi@networkengines.com
电话：781-332-1165电子邮件：史蒂夫。gonczi@networkengines.com
Ted Lemon 950 Charter Street Redwood City, CA 94043
Ted Lemon加利福尼亚州红木市Charter Street 950号，邮编94043
EMail: ted.lemon@nominum.com
EMail: ted.lemon@nominum.com
Rob Stevens Join Systems, Inc. 1032 Elwell Ct Ste 243 Palo Alto CA 94203
Rob Stevens Join Systems，Inc.加利福尼亚州帕洛阿尔托市爱尔维尔Ct街1032号243号94203
Phone: (650)-968-4470 EMail: robs@join.com
电话：（650）-968-4470电子邮件：robs@join.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
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编辑功能的资金目前由互联网协会提供。