summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3194.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3194.txt')
-rw-r--r--doc/rfc/rfc3194.txt395
1 files changed, 395 insertions, 0 deletions
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]
+