As per Relevance of the word addressing, we have this rfc below:
Network Working Group A.
Request for Comments: 3194 SUN
Updates: 1715 C.
Category: Informational
November 2001
The Host-Density Ratio for Address Assignment Efficiency
An update on the H
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document provides an update on the "H ratio" defined in
1715. It defines a new ratio which the authors claim is easier
understand
1. Evaluating the efficiency of address
A naive observer might assume that the number of addressable
in an addressing plan is a linear function of the size of
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
(using the American English definition of a billion, i.e.
thousand millions.) We all know that this is not correct: the 10
digit plan is stressed today, and it handles only a few
million telephones in North America; the Internet registries
started to implement increasingly restrictive allocation
when there were only a few tens of million computers on the Internet
Addressing plans are typically organized as a hierarchy:
telephony, the first digits will designate a region, the next
will designate an exchange, and the last digits will designate
subscriber within this exchange; in computer networks, the
significant bits will designate an address range allocated to
network provider, the next bits will designate the network of
organization served by that provider, and then the subnet to
the individual computers are connected. At each level of
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
digits to the region code than the current number of regions
necessitate, and more bits in a subnet than strictly required by
number of computers. The number of elements in any given level
the hierarchy will change over time, due to growth and mobility
If the current allocation is exceeded, one has to engage
renumbering, which is painful and expensive. In short, trying
squeeze too many objects into a hierarchical address space
the level of pain endured by operators and subscribers
Back in 1993, when we were debating the revision of the
Protocol, we wondered what the acceptable ratio of utilization was
a given addressing plan. Coming out with such a ratio was useful
assess how many computers could be connected to the Internet with
current 32-bit addresses, as well as to decide the size of the
generation addresses. The second point is now decided, with 128-
addresses for IPv6, but the first question is still relevant
knowing the capacity of the current address plan will help us
the date at which this capacity will be exceeded
Participants in the IPNG debates initially measured the efficiency
address allocation by simply dividing the number of
addresses by the size of the address space. This is a
measure, but it is largely dependent on the size of the
space. Loss of efficiency at each level of a hierarchical plan has
multiplicative effect; for example, 50% efficiency at each stage of
three level hierarchy results in a overall efficiency of 12.5%.
we want a "pain level indicator", we have to use a ratio that
into account these multiplicative effects
The "H-Ratio" defined in RFC 1715 proposed to measure the
of address allocation as the ratio of the base 10 logarithm of
number of allocated addresses to the size of the address in bits
This provides an address size independent ratio, but the
of the H ratio results in values in the range of 0.0 to 0.30103,
typical values ranging from 0.20 to 0.28. Experience has shown
these numbers are difficult to explain to others; it would be
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
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
replacement for the H-Ratio defined in RFC 1715. The HD values
from 0 to 1, and are generally expressed as percentage points;
authors believe that this new formulation is easier to understand
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-
When considering an addressing plan to allocate objects, the
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
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
between 0 (0%), when there is just one allocation, and 1 (100%),
there is one object allocated to each available address. Note
for the calculation of the HD-ratio, one can use any base for
logarithm as long as it is the same for both the numerator and
denominator
The HD-ratio can, in most cases, be derived from the H ratio by
formula
HD = --------
log10(2)
3. Using the HD-ratio as an indicator of the pain
In order to assess whether the H-Ratio was a good predictor of
"pain level" caused by a specific efficiency, RFC1715 used
examples of networks that had reached their capacity limit.
could be for example telephone networks at the point when
decided to add digits to their numbering plans, or computer
at the point when their addressing capabilities were perceived
stretched beyond practical limits. The idea behind these examples
that network managers would delay renumbering or changing the
protocol until it became just too painful; the ratio just before
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,
the phone number effectively 10 digits long instead of "9.2" (
second digit of area codes used to be limited to 0 or 1) for
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
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
reached their limits for very close values of the HD-ratio. We
use the same examples to confirm that the definition of the HD-
as a quotient of logarithms results in better prediction than
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
generalization. The examples suggest an HD-ratio value on the
of 85% and above correspond to a high pain level, at which
are ready to make drastic decisions
We can also examine our examples and hypothesize that the
who renumbered their networks tried to reach, after the renumbering
a pain level that was easily supported. The HD-ratio of the
or US network immediately after renumbering was 78% and 80%,
respectively. This suggests that values of 80% or less
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
Directly using the HD-ratio makes it easy to evaluate the density
allocated objects. Evaluating how well an addressing plan will
requires the reverse calculation. We have seen in section 3.1
an HD-ratio lower than 80% is manageable, and that HD-ratios
than 87% are hard to sustain. This should enable us to compute
acceptable and "practical maximum" number of objects that can
allocated given a specific address size, using the formula
number allocatable of
= exp( HD x log(maximum number allocatable of objects))
= (maximum number allocatable of objects)^
The following table provides example values for a 9-digit
plan, a 10-digit telephone plan, and the 32-bit IPv4 Internet
Very
Reasonable Painful Painful
HD=80% HD=85% HD=86% HD=87%
---------------------------------------------------------
9-digits plan 16 M 45 M 55 M 68
10-digits plan 100 M 316 M 400 M 500
32-bits addresses 51 M 154 M 192 M 240
Note: 1M = 1,000,000
Indeed, the practical maximum depends on the level of pain that
users and providers are willing to accept. We may very well end
with more than 154M allocated IPv4 addresses in the next years, if
are willing to accept the pain
5. Security
This document has no security implications
6. IANA
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
Alain
SUN Microsystems,
901 San Antonio Road MPK17-202
Palo Alto, CA 94303-4900
EMail: Alain.Durand@sun.
Christian
Microsoft
One Microsoft Way Redmond, WA 98052-6399
EMail: huitema@microsoft.
8.
The authors would like to thank Jean Daniau for his kind
during the elaboration of the HD formula
9.
[RFC1715] Huitema, C., "The H Ratio for Address
Efficiency", RFC 1715, November 1994.
[IANAV4] INTERNET PROTOCOL V4 ADDRESS SPACE, maintained by the IANA
http://www.iana.org/assignments/ipv4-address-
[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
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Durand & Huitema Informational [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
