RE: [sig-policy]Discussion document: Application of the HD-Ratio to IPv4
Ray
> -----Original Message-----
> From: sig-policy-admin at lists dot apnic dot net
> [mailto:sig-policy-admin at lists dot apnic dot net] On Behalf Of Paul Wilson
> Sent: Thursday, August 07, 2003 3:52 AM
> To: sig-policy at lists dot apnic dot net
> Subject: [sig-policy]Discussion document: Application of the
> HD-Ratio to IPv4
>
>
> Dear all,
>
> Following is a discussion paper for the Address Policy SIG at
> APNIC 16.
> Note that this is not a proposal for approval at this meeting.
>
> I hope to have a lively discussion about this topic, so
> please feel free to
> send comments or questions to this list, or to me directly by email.
>
> Hope to see you in Seoul,
>
> ______________________________________________________________
> __________
> Paul Wilson, Director-General, APNIC
> <dg at apnic dot net>
> http://www.apnic.net ph/fx +61 7
> 3858 3100/99
> --------------------------------------------------------------
> ----------
> See you at APNIC 16
> Seoul, Korea, 19-22 August 2003
> http://www.apnic.net/meetings
> --------------------------------------------------------------
> ----------
>
>
>
> Discussion Document
>
> Application of the HD-Ratio to IPv4
>
> Prepared by: Paul Wilson, APNIC Secretariat
> Version: 1.0
> Date: 7 August 2003
>
> 1 Summary
>
> Internet address space is managed hierarchically, by
> allocation from IANA to RIRs and from RIRs to LIRs (ISPs),
> and by assignment from LIRs to infrastructure components and
> customer networks. Within each level of allocation or
> assignment some address space is generally reserved for
> future expansion and/or efficient aggregation. As more
> hierarchical levels are introduced into any address space,
> the overall efficiency of utilisation of that space (in
> terms of the total number of individual addresses actually
> used) will inevitably decrease.
>
> The HD Ratio (Host-Density Ratio) has been proposed as a
> practical mechanism for measuring the utilisation of
> addresses within hierarchically-managed Internet address
> blocks [RFC 3194]. A given HD Ratio value corresponds to a
> percentage utilisation which decreases as the size of the
> address space grows, thus allowing for the decreasing
> overall address management efficiency which is described
> above.
>
> The HD Ratio is currently used as the utilisation metric for
> IPv6 address space, under the current IPv6 management policy
> [ipv6-address-policy]. According to this policy, a block of
> IPv6 address space is considered to be effectively utilised
> when its HD-Ratio reaches 0.80. This value is said to
> represent a conservative but manageable figure ("values of
> 80% or less correspond to comfortable trade-offs between
> pain and efficiency" [RFC 3194]).
>
> This document explores the possible use of the HD Ratio for
> measurement of IPv4 utilisation, for the same purpose of
> determining when a given block of address space should be
> considered as fully utilised.
>
>
> 2 Background and problem
>
> The current management framework for IPv4 address space
> relies on policies developed within each RIR community [ipv4-
> address-policy]. These policies dictate, effectively, that
> a given block of IPv4 addresses should be considered
> "utilised" when at least 80% of the addresses within the
> block have been allocated or assigned. This measure is
> applied equally for address blocks held by small or large
> LIRs, regardless of their size. In any case, it is deemed
> that once 80% of the space held by an LIR has been allocated
> or assigned, that LIR may request more address space from
> its appropriate RIR.
>
> Current policies assume a hierarchical system of address
> space delegation (from IANA to RIRs to LIRs to customers, as
> described above), but they make no allowance for
> hierarchical address management within an organisation's own
> address space. For LIRs in particular, a hierarchical
> approach is often required for assignment of address space
> to service elements such as customer networks, individual
> POPs, regionalised topologies, and even distinct ISP
> products. Small network infrastructures may require simple
> hierarchies, but large infrastructures can require several
> levels of address space subdivision. These levels of
> hierarchy are "hidden" in terms of recognition by the
> current RIR policy framework, and highly constrained by the
> 80% utilisation requirement. As a result, management of
> large blocks is often extremely difficult, requiring large
> internal routing tables and/or frequent renumbering of
> internal address blocks.
>
> One of the goals of the RIR system is to avoid unnecessary
> depletion of IPv4 address space, and the 80% utilisation
> requirement may be justifiable on that basis. However
> address management policies must also be practical in terms
> of management overhead imposed. It may be argued that when
> large address spaces are involved, the "80% rule" imposes
> unreasonable management overheads on an LIR.
>
> A more reasonable approach should attempt to impose a
> uniform degree of management overhead, rather than
> penalising the holders of large address blocks. This may be
> achievable to some degree by basing utilisation requirements
> on the HD ratio rather than the fixed percentage-based
> measure which is in use today.
>
>
> 3 A Proposal
>
> In recognition of the problems outlined above, it is now
> proposed to consider replacing the current fixed percentage
> based utilisation requirement for IPv4 address space with an
> "HD Ratio" based requirement, referred to as the AD Ratio.
>
> 3.1 The HD Ratio
>
> According to RFC3194, The HD-Ratio is calculated as follows:
>
> HD = log(U)/log(S)
>
> Where:
> S is the size of the address block concerned, and
> U is the number of site addresses (/48s) which are
> utilised.
>
> In order to calculate the HD-Ratio for a given IPv6 block,
> it is necessary to know the size of that block, and number
> of host addresses which are in use. The current IPv6
> policies allow for this by requiring registration of address
> assignments to the /48 level, however this degree of
> registration is not appropriate under IPv4 management
> policies.
>
> 3.2 Definition - the AD Ratio
>
> IPv4 address space utilisation is measured in terms of the
> number of allocations or assignments which have been made
> from a given address block, rather than the number of host
> addresses which are in use within the block. We therefore
> use the term "Allocation Density" for the measure of address
> space utilisation within an IPv4 block, rather than the term
> "Host Density" which represents host-address utilisation in
> IPv6.
>
> Consequently, we refer propose a new utilisation metric for
> IPv4, to be known as the "AD Ratio" (for Allocation or
> Assignment Density Ratio). The AD Ratio measures the number
> of addresses allocated or assigned from a given block of
> address space, as follows:
>
> AD = log(A)/log(S)
>
> Where:
> S is the size of the of the address block, and
> A is the number of addresses allocated or assigned
> from that block.
>
> 3.3 Selection of AD Ratio value
>
> The appropriate AD Ratio value for the purposes of this
> proposal should be decided on a rational basis. In order to
> do this, we make certain assumptions about the depth of
> "hidden" hierarchy involved in managing address blocks of
> various sizes. We then assume that at each level of this
> assumed hierarchy, the currently accepted 80% utilisation
> requirement is achieved, in order for the entire address
> space to be considered as fully utilised.
>
> The following table proposes a set of assumed hierarchical
> depths which may be reasonably expected within
> hierarchically-managed address spaces of certain sizes. At
> each delegation level an allocation density of 80% is
> assumed, so that within a hierarchy of "n" levels, the
> overall address space utilisation is calculated as 0.80 to
> the power of "n".
>
> Size range Depth Util AD Ratio
> (prefix) (n) (0.80**n) (calculated)
>
> /24 to /20 1 80% .960 to .973
> /20 to /16 1.5 72% .961 to .970
> /16 to /12 2 64% .960 to .968
> /12 to /8 2.5 57.2% .960 to .966
> /8 to /4 3 51.20% .960 to .966
>
> Note: the above AD Ratio values are derived directly
> from the formula above. For instance, a /20 block
> contains 4096 addresses, and 80% utilisation
> corresponds to 3276.8 addresses; therefore the
> corresponding AD Ratio is calculated as
> log(3276.8)/log(4096) = 0.973
>
> The depths of address hierarchy listed above are notional
> approximations only, based on general assumptions about the
> likely size and structure of LIRs holding address blocks in
> the respective size ranges. From the table, a rational
> common AD ratio value may be determined as 0.966 (chosen as
> the most conservative value which is common to all of the
> listed ranges). For this value, the following table gives
> the percentage utilisation requirement for the full range of
> IPv4 address blocks (this is also derived directly from the
> AD ratio formula shown above).
>
> IPv4 Addresses Addresses Util%
> Prefix Total Utilised
>
> 32 1 1 100.00%
> 31 2 2 97.67%
> 30 4 4 95.40%
> 29 8 7 93.17%
> 28 16 15 91.00%
> 27 32 28 88.88%
> 26 64 56 86.81%
> 25 128 109 84.79%
> 24 256 212 82.82%
> 23 512 414 80.89%
> 22 1024 809 79.00%
> 21 2048 1580 77.16%
> 20 4096 3087 75.37%
> 19 8192 6030 73.61%
> 18 16384 11780 71.90%
> 17 32768 23010 70.22%
> 16 65536 44949 68.59%
> 15 131072 87804 66.99%
> 14 262144 171518 65.43%
> 13 524288 335046 63.90%
> 12 1048576 654485 62.42%
> 11 2097152 1278482 60.96%
> 10 4194304 2497408 59.54%
> 9 8388608 4878479 58.16%
> 8 16777216 9529704 56.80%
> 7 33554432 18615487 55.48%
> 6 67108864 36363809 54.19%
> 5 134217728 71033685 52.92%
> 4 268435456 138758413 51.69%
> 3 536870912 271053050 50.49%
> 2 1073741824 529479652 49.31%
> 1 2147483648 1034294583 48.16%
> 0 4294967296 2020408681 47.04%
>
> Note: This table provides values for CIDR blocks only,
> however for non-CIDR blocks the same calculations can be
> applied to produce equally meaningful results.
>
>
> 4 Implementation
>
> If implemented at any particular level in the IP address
> delegation chain, this proposal would have a number of
> impacts on administrative processes at that level. It is
> not currently proposed to apply this proposal to the
> relationship between RIRs and IANA, therefore the
> implementation of the proposal at the RIR-LIR level is
> discussed there.
>
> 4.1 RIR-LIR Procedures
>
> The impact of the proposal on the RIR-LIR administrative
> procedures would be to replace the current 80% utilisation
> requirement, with a 0.966 AD Ratio requirement.
>
> By way of examples, an LIR holding a total address space
> equal to a /16 would be able to receive more address space
> when they had allocated or assigned 68.59% of that space;
> while an LIR holding a /9 would be able to receive more
> space when they had allocated or assigned 58.16% of their
> address space. For blocks smaller than /22, it is proposed
> that the current 80% requirement be used, in order that this
> new policy does not impose tighter utilisation requirements
> than were previously imposed.
>
> The AD-Ratio calculation is trivial, but certainly more
> complex and less intuitive than the existing 80%
> calculation. Some APNIC members may in some circumstances
> require extra assistance, however for those using the
> MyAPNIC service, the calculation would be automatic and
> therefore no additional effort would be involved.
>
> 4.2 Assignment procedures
>
> In order to support consistent calculation of an LIR's AD
> Ratio, it would be preferable for each LIR to register
> infrastructure assignments in the same way as customer
> assignments. This could be done by whois update via email,
> or via the MyAPNIC service. It would not be necessary to
> register individual hardware components or subnets, but
> rather only the independent infrastructure blocks which are
> designated by the LIR, and which can be justified on the
> same basis as customer assignments. Such registrations would
> be publicly visible as normal whois records, unless database
> changes were implemented to specifically hide them.
>
> 4.3 Implementation timeline
>
> If implemented, this policy could be effective within 3
> months of the implementation date.
>
>
> 5 Impacts
>
> 5.1 Administrative Impact
>
> The primary administrative impact of this proposal is to
> ease the administrative address management burden
> experienced by LIRs, especially those with large address
> space holdings. The proposal recognises the need to manage
> address space hierarchically within an LIR service
> infrastructure, and makes allowance for it through the use
> of the AD ratio for assessment of address utilisation.
>
> This proposal would impose a small administrative cost on
> LIRs. In the first place, an LIR's internal systems (manual
> or automated) would need to incorporate a new method of
> calculating address space utilisation (and especially when
> determining the point at which the LIR may request more
> space from APNIC). In the second place, an LIR would need
> to register infrastructure assignments in the same way as
> customer assignments, which would impose additional
> administrative cost. In both cases, LIRs using the MyAPNIC
> service would experience a small extra cost because these
> changes can be automated within that system.
>
> The administrative impact on internal systems of the APNIC
> Secretariat is also relatively small. APNIC hostmaster
> processes can be tailored easily to accommodate a changed
> method of calculating address space utilisation; and the
> whois database can certainly accommodate an increased number
> of registrations.
>
> 5.2 Address Space Consumption
>
> Because this proposal lowers the utilisation requirement for
> IPv4 address blocks, it would certainly increase the rate of
> deployment of IP addresses. In analysing this impact, we
> can identify two separate factors contributing to increased
> consumption: firstly, an initial impact resulting from
> increased "wastage" of deployed address space; and secondly,
> on ongoing impact as utilisation requirements continue to
> fall for individual LIRs' growing address holdings.
>
> 5.2.1 Initial impact
>
> The initial impact on address consumption can be estimated
> by calculating for each APNIC LIR the difference between the
> current 80% utilisation, and the AD-ratio-determined
> utilisation requirement. This calculation will indicate the
> amount of extra "wasted" address space which would result
> from the proposed policy change.
>
> Total LIRs in sample 788
>
> Total address space held 4.17 (/8 blocks)
> Utilised addresses (80%) 3.32
> Utilised addresses (AD 0.966) 2.53*
> Extra "wasted" space 0.81
> Extra "wastage" as % of total 19%
>
> * This figure is calculated from the sample of 788
> LIRs, according to actual address space holdings
>
> These figures show that by reducing the address space
> utilisation requirement from 80% to AD 0.966, an additional
> 0.81 blocks are consumed out of a total 4.17 blocks
> allocated. This corresponds to an additional of 19% of the
> total allocated address space.
>
> It should be noted that this assessment indicates a
> theoretical impact in terms of increased address
> consumption, assuming all deployed address space is actually
> utilised. The actual impact will be less than this due to
> underutilisation of address space; and furthermore the
> impact will not take place at one time, but progressively as
> part of ongoing address space allocations.
>
> 5.2.2 Ongoing impact
>
> The ongoing impact on address consumption can be estimated
> by distributing additional address space to the same set of
> LIRs, in proportion to their existing address space
> holdings. For the purposes of this analysis, an additional
> /8 block is distributed to the same set of 788 LIRs, in
> proportion to their existing address holdings.
>
> Initial address space held 4.17 (/8 blocks)
> Additional space allocated 1.00
> Total address space now held 5.17
> Utilised addresses (AD 0.966) 3.11*
> Additional addresses utilised 0.58*
> Utilised addresses (80%) 0.80
> Extra "wasted" space 0.22
> Extra "wastage" as % of allocation 22%
>
> * These figures are calculated from the same sample of
> 788 LIRs, assuming a proportional distribution of an
> additional /8 block
>
> These figures show that after an additional /8 block is
> distributed and utilised, 58% of that block would actually
> be utilised, rather than 80%. Therefore up to 22% of that
> block would be "wasted" by the use of AD 0.966 in place of
> 80% as the utilisation measure, resulting potentially in an
> increased consumption rate of up to 22%.
>
> Again, this calculation is theoretical only, and assumes
> that all address space which has been distributed will be
> utilised.
>
> 5.2.3 Conclusions on address consumption
>
> The above analysis indicates that the adoption of this
> proposal would cause an initial additional consumption of up
> to 19% of address space allocated. In APNIC's case, a total
> of 8.07 /8 blocks have been allocated (as of 1 July 2003),
> so up to an additional 1.53 blocks would eventually be
> consumed as a result of the change.
>
> The analysis also indicates that this proposal would cause
> an overall 22% increase in the rate of address consumption.
> In APNIC's case, a total of 1.90 /8 blocks per year are
> currently being allocated (in the 12 months to 1 July 2003),
> and this rate would therefore rise to 2.32 blocks per year.
>
> The assumptions on which the above analysis is made include:
> firstly, that the 788 LIRs in the sample are representative
> of all LIRs in the region; and secondly, that a consistent
> rate of growth will be experienced by all LIRs in the
> region.
>
>
> 6 References
>
> [RFC 3194] "The Host-Density Ratio for Address Assignment
> Efficiency: An update on the H ratio", A. Durand, C.Huitema,
> November 2001.
>
> [ipv6-address-policy] APNIC document: "IPv6 Address
> Allocation and Assignment Policy"
> (http://www.apnic.net/docs/policy/ipv6-address-policy.html)
>
> [ipv4-address-policy] APNIC document: "Policies for IPv4
> address space management in the Asia Pacific region"
> (http://www.apnic.net/docs/policy/add-manage-policy.html)
>
> * sig-policy: APNIC SIG on resource management
> policy *
> _______________________________________________
> sig-policy mailing list
> sig-policy at lists dot apnic dot net
> http://mailman.apnic.net/mailman/listinfo/sig-policy
>