Network Working Group A. Durand
Request for Comments: 3194 SUN Microsystems
Updates: 1715 C. Huitema
Category: Informational Microsoft
November 2001
Network Working Group A. Durand
Request for Comments: 3194 SUN Microsystems
Updates: 1715 C. Huitema
Category: Informational Microsoft
November 2001
The Host-Density Ratio for Address Assignment Efficiency: An update on the H ratio
地址分配效率的主机密度比：H比率的更新
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This document provides an update on the "H ratio" defined in RFC 1715. It defines a new ratio which the authors claim is easier to understand.
本文件提供了RFC 1715中定义的“H比率”的更新。它定义了一个新的比率，作者声称这个比率更容易理解。
A naive observer might assume that the number of addressable objects in an addressing plan is a linear function of the size of the address. If this were true, a telephone numbering plan based on 10 digits would be able to number 10 billion telephones, and the IPv4 32 bit addresses would be adequate for numbering 4 billion computers (using the American English definition of a billion, i.e. one thousand millions.) We all know that this is not correct: the 10 digit plan is stressed today, and it handles only a few hundred million telephones in North America; the Internet registries have started to implement increasingly restrictive allocation policies when there were only a few tens of million computers on the Internet.
天真的观察者可能会认为寻址计划中可寻址对象的数量是地址大小的线性函数。如果这是真的，基于10位数的电话编号计划将能够为100亿部电话编号，而IPv4 32位地址将足以为40亿部计算机编号（使用美式英语中10亿的定义，即10亿）。我们都知道这是不正确的：今天强调的是10位数计划，在北美，它只处理数亿部电话；当互联网上只有几千万台计算机时，互联网登记处开始实施越来越严格的分配政策。
Addressing plans are typically organized as a hierarchy: in telephony, the first digits will designate a region, the next digits will designate an exchange, and the last digits will designate a subscriber within this exchange; in computer networks, the most significant bits will designate an address range allocated to a network provider, the next bits will designate the network of an organization served by that provider, and then the subnet to which the individual computers are connected. At each level of the
寻址计划通常被组织为一个层次结构：在电话中，第一位数字将指定一个区域，下一位数字将指定一个交换机，最后一位数字将指定该交换机内的一个用户；在计算机网络中，最高有效位将指定分配给网络提供商的地址范围，下一位将指定由该提供商服务的组织的网络，然后指定各个计算机连接到的子网。在每一级
hierarchy, one has to provide some margins: one has to allocate more digits to the region code than the current number of regions would necessitate, and more bits in a subnet than strictly required by the number of computers. The number of elements in any given level of the hierarchy will change over time, due to growth and mobility. If the current allocation is exceeded, one has to engage in renumbering, which is painful and expensive. In short, trying to squeeze too many objects into a hierarchical address space increases the level of pain endured by operators and subscribers.
在层次结构中，必须提供一些余量：必须为区域代码分配比当前区域数所需的位数更多的位数，子网中的位数必须比计算机数严格要求的位数更多。由于增长和流动性，任何给定层次结构中的元素数量都将随时间而变化。如果超过目前的分配，就必须重新编号，这既痛苦又昂贵。简言之，试图将太多对象压缩到分层地址空间会增加运营商和订户所承受的痛苦。
Back in 1993, when we were debating the revision of the Internet Protocol, we wondered what the acceptable ratio of utilization was of a given addressing plan. Coming out with such a ratio was useful to assess how many computers could be connected to the Internet with the current 32-bit addresses, as well as to decide the size of the next generation addresses. The second point is now decided, with 128-bits addresses for IPv6, but the first question is still relevant: knowing the capacity of the current address plan will help us predict the date at which this capacity will be exceeded.
早在1993年，当我们讨论修改互联网协议时，我们就想知道给定寻址计划的可接受利用率是多少。得出这样一个比率对于评估有多少台计算机可以用当前的32位地址连接到互联网，以及决定下一代地址的大小都很有用。第二点现在已经确定，IPv6有128位地址，但第一个问题仍然相关：了解当前地址计划的容量将有助于我们预测超过此容量的日期。
Participants in the IPNG debates initially measured the efficiency of address allocation by simply dividing the number of allocated addresses by the size of the address space. This is a simple measure, but it is largely dependent on the size of the address space. Loss of efficiency at each level of a hierarchical plan has a multiplicative effect; for example, 50% efficiency at each stage of a three level hierarchy results in a overall efficiency of 12.5%. If we want a "pain level indicator", we have to use a ratio that takes into account these multiplicative effects.
IPNG辩论的参与者最初只是通过将分配的地址数除以地址空间的大小来衡量地址分配的效率。这是一个简单的度量，但它在很大程度上取决于地址空间的大小。分层计划中每一级的效率损失都会产生乘数效应；例如，在三级层次结构的每个阶段，50%的效率导致12.5%的总体效率。如果我们想要一个“疼痛程度指标”，我们必须使用一个考虑到这些倍增效应的比率。
The "H-Ratio" defined in RFC 1715 proposed to measure the efficiency of address allocation as the ratio of the base 10 logarithm of the number of allocated addresses to the size of the address in bits. This provides an address size independent ratio, but the definition of the H ratio results in values in the range of 0.0 to 0.30103, with typical values ranging from 0.20 to 0.28. Experience has shown that these numbers are difficult to explain to others; it would be easier to say that "your address bits are used to 83% of their H-Density", and then explain what the H-Density is, than to say "you are hitting a H ratio of 0.25" and then explain what exactly the range is.
RFC 1715中定义的“H比率”用于测量地址分配的效率，即分配地址数的10进制对数与地址大小（以位为单位）的比率。这提供了一个与地址大小无关的比率，但H比率的定义导致值在0.0到0.30103之间，典型值在0.20到0.28之间。经验表明，这些数字很难向其他人解释；说“您的地址位使用了其H密度的83%”，然后解释H密度是什么，要比说“您的H比率达到了0.25”然后解释确切的范围更容易。
This memo introduces the Host Density ratio or "HD-Ratio", a proposed replacement for the H-Ratio defined in RFC 1715. The HD values range from 0 to 1, and are generally expressed as percentage points; the authors believe that this new formulation is easier to understand and more expressive than the H-Ratio.
本备忘录介绍了主机密度比或“HD比”，建议替代RFC 1715中定义的H比。HD值的范围为0到1，通常以百分比表示；作者认为，这种新的公式比H比率更容易理解和表达。
When considering an addressing plan to allocate objects, the host density ratio HD is defined as follow:
当考虑分配对象的寻址计划时，主机密度比HD定义如下：
log(number of allocated objects)
HD = ------------------------------------------
log(maximum number of allocatable objects)
log(number of allocated objects)
HD = ------------------------------------------
log(maximum number of allocatable objects)
This ratio is defined for any number of allocatable objects greater than 1 and any number of allocated objects greater or equal than 1 and less than or equal the maximum number of allocatable objects. The ratio is usually presented as a percentage, e.g. 70%. It varies between 0 (0%), when there is just one allocation, and 1 (100%), when there is one object allocated to each available address. Note that for the calculation of the HD-ratio, one can use any base for the logarithm as long as it is the same for both the numerator and the denominator.
此比率是为大于1的任意数量的可分配对象和大于或等于1且小于或等于最大可分配对象数量的任意数量的已分配对象定义的。该比率通常以百分比表示，例如70%。当只有一个分配时，其变化范围为0（0%），当每个可用地址分配一个对象时，其变化范围为1（100%）。请注意，对于HD比率的计算，可以使用对数的任何基数，只要分子和分母的基数相同。
The HD-ratio can, in most cases, be derived from the H ratio by the formula:
在大多数情况下，HD比率可以通过以下公式从H比率得出：
H
HD = --------
log10(2)
H
HD = --------
log10(2)
In order to assess whether the H-Ratio was a good predictor of the "pain level" caused by a specific efficiency, RFC1715 used several examples of networks that had reached their capacity limit. These could be for example telephone networks at the point when they decided to add digits to their numbering plans, or computer networks at the point when their addressing capabilities were perceived as stretched beyond practical limits. The idea behind these examples is that network managers would delay renumbering or changing the network protocol until it became just too painful; the ratio just before the change is thus a good predictor of what can be achieved in practice. The examples were the following:
为了评估H比率是否是由特定效率引起的“疼痛水平”的良好预测因子，RFC1715使用了几个已达到其容量限制的网络示例。例如，当他们决定在其编号计划中添加数字时，可能是电话网络，或者当他们的寻址能力被认为超出了实际限制时，可能是计算机网络。这些例子背后的想法是，网络管理员会延迟重新编号或更改网络协议，直到它变得太痛苦；因此，变化前的比率可以很好地预测在实践中可以实现什么。例如：
* Adding one digit to all French telephone numbers, moving from 8 digits to 9, when the number of phones reached a threshold of 1.0 E+7.
* 当电话数量达到1.0 E+7的阈值时，将所有法语电话号码增加一位，从8位增加到9位。
log(1.0E+7)
HD(FrenchTelephone8digit) = ----------- = 0.8750 = 87.5%
log(1.0E+8)
log(1.0E+7)
HD(FrenchTelephone8digit) = ----------- = 0.8750 = 87.5%
log(1.0E+8)
log(1.0E+7)
HD(FrenchTelephone9digit) = ----------- = 0.7778 = 77.8%
log(1.0E+9)
log(1.0E+7)
HD(FrenchTelephone9digit) = ----------- = 0.7778 = 77.8%
log(1.0E+9)
* Expanding the number of areas in the US telephone system, making the phone number effectively 10 digits long instead of "9.2" (the second digit of area codes used to be limited to 0 or 1) for about 1.0 E+8 subscribers.
* 扩大美国电话系统的区域数量，使电话号码有效地达到10位数，而不是1.0E+8用户的“9.2”（区号的第二位数过去被限制为0或1）。
log(1.0E+8)
HD(USTelephone9.2digit) = ------------ = 0.8696 = 87.0 %
log(9.5E+9)
log(1.0E+8)
HD(USTelephone9.2digit) = ------------ = 0.8696 = 87.0 %
log(9.5E+9)
log(1.0E+8)
HD(USTelephone10digit) = ------------ = 0.8000 = 80.0 %
log(1E+10)
log(1.0E+8)
HD(USTelephone10digit) = ------------ = 0.8000 = 80.0 %
log(1E+10)
* The globally-connected physics/space science DECnet (Phase IV) stopped growing at about 15K nodes (i.e. new nodes were hidden) in a 16 bit address space.
* 全球连接的物理/空间科学DECnet（第四阶段）在16位地址空间中约15K个节点（即新节点被隐藏）停止增长。
log(15000)
HD(DecNET IV) = ---------- = 0.8670 = 86.7 %
log(2^16)
log(15000)
HD(DecNET IV) = ---------- = 0.8670 = 86.7 %
log(2^16)
From those examples, we can note that these addressing systems reached their limits for very close values of the HD-ratio. We can use the same examples to confirm that the definition of the HD-ratio as a quotient of logarithms results in better prediction than the direct quotient of allocated objects over size of the address space. In our three examples, the direct quotients were 10%, 3.2% and 22.8%, three very different numbers that don't lead to any obvious generalization. The examples suggest an HD-ratio value on the order of 85% and above correspond to a high pain level, at which operators are ready to make drastic decisions.
从这些例子中，我们可以注意到，这些寻址系统在非常接近HD比率的值时达到了极限。我们可以用同样的例子来证实，将HD比率定义为对数商比将分配对象的商直接定义为地址空间的商更容易预测。在我们的三个例子中，直接商分别为10%、3.2%和22.8%，三个非常不同的数字不会导致任何明显的泛化。示例表明，85%及以上的HD比率值对应于高疼痛水平，此时操作员准备做出激烈的决定。
We can also examine our examples and hypothesize that the operators who renumbered their networks tried to reach, after the renumbering, a pain level that was easily supported. The HD-ratio of the French or US network immediately after renumbering was 78% and 80%, respectively. This suggests that values of 80% or less corresponds to comfortable trade-offs between pain and efficiency.
我们还可以检查我们的例子，并假设重新编号网络的运营商试图在重新编号后达到一个容易支持的痛苦水平。重新编号后，法国或美国网络的高清率分别为78%和80%。这表明80%或更低的值对应于痛苦和效率之间的舒适权衡。
Directly using the HD-ratio makes it easy to evaluate the density of allocated objects. Evaluating how well an addressing plan will scale requires the reverse calculation. We have seen in section 3.1 that an HD-ratio lower than 80% is manageable, and that HD-ratios higher than 87% are hard to sustain. This should enable us to compute the acceptable and "practical maximum" number of objects that can be allocated given a specific address size, using the formula:
直接使用HD比率可以轻松评估分配对象的密度。评估寻址计划的扩展程度需要反向计算。我们在第3.1节中看到，HD比率低于80%是可控的，而HD比率高于87%则难以维持。这将使我们能够使用以下公式计算给定特定地址大小可分配的对象的可接受和“实际最大”数量：
number allocatable of objects
= exp( HD x log(maximum number allocatable of objects))
= (maximum number allocatable of objects)^HD
number allocatable of objects
= exp( HD x log(maximum number allocatable of objects))
= (maximum number allocatable of objects)^HD
The following table provides example values for a 9-digit telephone plan, a 10-digit telephone plan, and the 32-bit IPv4 Internet:
下表提供了9位电话计划、10位电话计划和32位IPv4 Internet的示例值：
Very Practical
Reasonable Painful Painful Maximum
HD=80% HD=85% HD=86% HD=87%
---------------------------------------------------------
9-digits plan 16 M 45 M 55 M 68 M
10-digits plan 100 M 316 M 400 M 500 M
32-bits addresses 51 M 154 M 192 M 240 M
Very Practical
Reasonable Painful Painful Maximum
HD=80% HD=85% HD=86% HD=87%
---------------------------------------------------------
9-digits plan 16 M 45 M 55 M 68 M
10-digits plan 100 M 316 M 400 M 500 M
32-bits addresses 51 M 154 M 192 M 240 M
Note: 1M = 1,000,000
注：1M=1000000
Indeed, the practical maximum depends on the level of pain that the users and providers are willing to accept. We may very well end up with more than 154M allocated IPv4 addresses in the next years, if we are willing to accept the pain.
实际上，实际最大限度取决于用户和提供商愿意接受的痛苦程度。如果我们愿意接受这一痛苦，我们很可能在未来几年拥有超过1.54亿个IPv4地址。
This document has no security implications.
本文件不涉及安全问题。
This memo does not request any IANA action.
本备忘录不要求IANA采取任何行动。
Alain Durand SUN Microsystems, Inc 901 San Antonio Road MPK17-202 Palo Alto, CA 94303-4900 USA
美国加利福尼亚州帕洛阿尔托市圣安东尼奥路901号Alain Durand SUN Microsystems，Inc.MPK17-202，邮编94303-4900
EMail: Alain.Durand@sun.com
EMail: Alain.Durand@sun.com
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 USA
Christian Huitema微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052-6399
EMail: huitema@microsoft.com
EMail: huitema@microsoft.com
The authors would like to thank Jean Daniau for his kind support during the elaboration of the HD formula.
作者要感谢Jean Daniau在HD公式制定过程中给予的善意支持。
[RFC1715] Huitema, C., "The H Ratio for Address Assignment Efficiency", RFC 1715, November 1994.
[RFC1715]Huitema，C.，“地址分配效率的H比率”，RFC17151994年11月。
[IANAV4] INTERNET PROTOCOL V4 ADDRESS SPACE, maintained by the IANA,
http://www.iana.org/assignments/ipv4-address-space
[IANAV4] INTERNET PROTOCOL V4 ADDRESS SPACE, maintained by the IANA,
http://www.iana.org/assignments/ipv4-address-space
[DMNSRV] Internet Domain Survey, Internet Software Consortium,
http://www.isc.org/ds/
[DMNSRV] Internet Domain Survey, Internet Software Consortium,
http://www.isc.org/ds/
[NETSZR] Netsizer, Telcordia Technologies, http://www.netsizer.com/
[NETSZR] Netsizer, Telcordia Technologies, http://www.netsizer.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编辑功能的资金目前由互联网协会提供。