From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3194.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc3194.txt (limited to 'doc/rfc/rfc3194.txt') diff --git a/doc/rfc/rfc3194.txt b/doc/rfc/rfc3194.txt new file mode 100644 index 0000000..6a24dd5 --- /dev/null +++ b/doc/rfc/rfc3194.txt @@ -0,0 +1,395 @@ + + + + + + +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 + +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. + +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. + +1. Evaluating the efficiency of address allocation + + 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. + + 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 + + + +Durand & Huitema Informational [Page 1] + +RFC 3194 An update on the H ratio November 2001 + + + 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. + + 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. + + 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. + + 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. + + + + + +Durand & Huitema Informational [Page 2] + +RFC 3194 An update on the H ratio November 2001 + + +2. Definition of the HD-ratio + + When considering an addressing plan to allocate objects, the host + density ratio HD is defined as follow: + + 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. + + The HD-ratio can, in most cases, be derived from the H ratio by the + formula: + + H + HD = -------- + log10(2) + +3. Using the HD-ratio as an indicator of the pain level + + 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: + + * 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. + + + + + + + + +Durand & Huitema Informational [Page 3] + +RFC 3194 An update on the H ratio November 2001 + + + 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. + + 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. + + 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. + + 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. + + + +Durand & Huitema Informational [Page 4] + +RFC 3194 An update on the H ratio November 2001 + + +4. Using the HD-ratio to evaluate the capacity of addressing plans + + 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: + + 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: + + 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 + + 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. + +5. Security considerations + + This document has no security implications. + +6. IANA Considerations + + This memo does not request any IANA action. + + + + + + + + + + + + +Durand & Huitema Informational [Page 5] + +RFC 3194 An update on the H ratio November 2001 + + +7. Author addresses + + 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 + + EMail: huitema@microsoft.com + +8. Acknowledgment + + The authors would like to thank Jean Daniau for his kind support + during the elaboration of the HD formula. + +9. References + + [RFC1715] Huitema, C., "The H Ratio for Address Assignment + Efficiency", RFC 1715, November 1994. + + [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/ + + [NETSZR] Netsizer, Telcordia Technologies, http://www.netsizer.com/ + + + + + + + + + + + + + + + + +Durand & Huitema Informational [Page 6] + +RFC 3194 An update on the H ratio November 2001 + + +10. Full Copyright Statement + + Copyright (C) The Internet Society (2001). All Rights Reserved. + + 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. + + + + + + + + + + + + + + + + + + + +Durand & Huitema Informational [Page 7] + -- cgit v1.2.3