[要約] 要約： RFC 3194は、アドレス割り当ての効率を向上させるためのH-Density比率に関する最新情報を提供しています。目的： このRFCの目的は、H-Density比率の更新情報を提供し、アドレス割り当ての効率を向上させるためのガイドラインを提供することです。
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.
Copyright（c）The Internet Society（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億コンピューターを番号付けするのに適しています（アメリカの英語の定義を使用して、つまり1億1億人。）私たちは皆、これが正しくないことを知っています。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.
対処計画は通常階層として編成されます。テレフォニーでは、最初の数字は領域を指定し、次の数字は交換を指定し、最後の数字はこの交換内のサブスクライバーを指定します。コンピューターネットワークでは、最も重要なビットがネットワークプロバイダーに割り当てられたアドレス範囲を指定し、次のビットはそのプロバイダーが提供する組織のネットワークを指定し、その後、個々のコンピューターが接続されるサブネットを指定します。階層の各レベルで、マージンを提供する必要があります。1つの地域の数よりも多くの数字を地域コードに割り当てる必要があります。階層の任意のレベルの要素の数は、成長とモビリティのために、時間とともに変化します。現在の割り当てを超えている場合、非変更に従事する必要があります。これは痛みを伴い、高価です。要するに、あまりにも多くのオブジェクトを階層的なアドレス空間に絞り込もうとすると、オペレーターと加入者が耐える痛みのレベルが増加します。
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ビットアドレスでインターネットに接続できるコンピューターの数を評価し、次世代アドレスのサイズを決定するのに役立ちました。2番目のポイントが決定され、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討論の参加者は、最初に、割り当てられたアドレスの数をアドレススペースのサイズで割るだけで、アドレス割り当ての効率を測定しました。これは簡単な尺度ですが、アドレス空間のサイズに大きく依存しています。階層計画の各レベルでの効率の喪失には、乗法効果があります。たとえば、3レベルの階層の各段階での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-ratio」は、アドレスの割り当ての効率を測定することを提案します。これはアドレスサイズの独立した比率を提供しますが、H比の定義は0.0〜0.30103の範囲の値をもたらし、典型的な値は0.20〜0.28の範囲です。経験は、これらの数字を他の人に説明するのが難しいことを示しています。「あなたのアドレスビットはH密度の83％に使用されている」と言うのは簡単です。そして、「あなたは0.25のH比を打っている」と言うよりも、H密度を説明し、それから何を説明しますかまさに範囲はです。
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.
このメモは、RFC 1715で定義されているH ratioの提案された代替品であるホスト密度比または「HD-ratio」を導入します。HD値は0〜1の範囲で、一般にパーセンテージポイントとして表されます。著者は、この新しい定式化はH-Ratioよりも理解しやすく、表現力があると考えています。
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)
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％。使用可能な各アドレスに割り当てられたオブジェクトが1つある場合、1つの割り当てが1つだけ、1（100％）がある場合、0（0％）の間で変化します。HD-ratioの計算では、分子と分母の両方で同じである限り、対数に任意のベースを使用できることに注意してください。
The HD-ratio can, in most cases, be derived from the H ratio by the formula:
HD-ratioは、ほとんどの場合、式によってH比に由来することができます。
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-ratioが特定の効率によって引き起こされる「痛みレベル」の適切な予測因子であるかどうかを評価するために、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桁を追加し、8桁から9に移動します。電話の数が1.0 E 7のしきい値に達しました。
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)
* 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.
* 米国の電話システムの領域の数を拡大し、約1.0 E 8のサブスクライバーに対して、「9.2」（9.2」（以前は0または1に制限されていたエリアコードの2桁目）ではなく、長さ10桁の長さを効果的に拡大します。
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)
* 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.
* グローバルに接続された物理学/宇宙科学デコネット（フェーズIV）は、16ビットアドレススペースで約15Kノード（つまり、新しいノードが隠された）で成長を停止しました。
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-ratioの非常に密接な値のために制限に達したことに注意することができます。同じ例を使用して、対数の商としてHD-ratioの定義が、アドレス空間のサイズにわたって割り当てられたオブジェクトの直接的な商よりも良い予測をもたらすことを確認できます。私たちの3つの例では、直接的な商は10％、3.2％、22.8％であり、明らかな一般化につながらない3つの非常に異なる数値でした。例は、85％以上の順序でHD-ratio値を示唆しており、オペレーターが劇的な決定を下す準備ができている高い痛みレベルに対応しています。
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.
また、例を調べて、ネットワークの名前を変更したオペレーターが、変更後、簡単にサポートされる痛みレベルに到達しようとしたという仮説を立てることができます。変更後すぐにフランスまたは米国のネットワークのHD-ratioは、それぞれ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-ratioを直接使用すると、割り当てられたオブジェクトの密度を簡単に評価できます。アドレス指定計画がどれだけうまく拡張されるかを評価するには、逆の計算が必要です。セクション3.1では、HD-Ratioが80％未満で管理可能であり、87％を超えるHD-Ratiosが維持が困難であることがわかりました。これにより、式を使用して、特定のアドレスサイズを考慮して割り当てることができるオブジェクトの許容可能かつ「実用的な」数を計算できるようになります。
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インターネットの例の例が示されています。
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 = 1,000,000
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.
実際、実際の最大値は、ユーザーとプロバイダーが受け入れようとする痛みのレベルに依存します。痛みを受け入れようとするなら、来年には154mを超える割り当てられた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
Alain Durand Sun Microsystems、Inc 901 San Antonio Road MPK17-202 Palo Alto、CA 94303-4900 USA
EMail: Alain.Durand@sun.com
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 USA
Christian Huitema Microsoft Corporation One Microsoft Way Redmond、WA 98052-6399 USA
EMail: huitema@microsoft.com
The authors would like to thank Jean Daniau for his kind support during the elaboration of the HD formula.
著者は、HDフォーミュラの精緻化中の彼の親切なサポートについてJean Daniauに感謝したいと思います。
[RFC1715] Huitema, C., "The H Ratio for Address Assignment Efficiency", RFC 1715, November 1994.
[RFC1715] Huitema、C。、「アドレス割り当て効率のH比」、RFC 1715、1994年11月。
[IANAV4] INTERNET PROTOCOL V4 ADDRESS SPACE, maintained by the IANA, http://www.iana.org/assignments/ipv4-address-space
[IANAV4] Internet Protocol V4アドレス空間、IANA、http：//www.iana.org/assignments/ipv4-address-pace
[DMNSRV] Internet Domain Survey, Internet Software Consortium, http://www.isc.org/ds/
[DMNSRV]インターネットドメイン調査、インターネットソフトウェアコンソーシアム、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.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。