ARIN-prop-184 [Archived]

Policy Proposal Name: 3GPP Network IP Resource Policy
Proposal Originator: Cameron Byrne

Date: 3/1/13

Problem Statement:

Current 3GPP architectures consist of hierarchical aggregation, from
cell site up to anchor nodes, approximately one per NFL city. Anchor
nodes are the point where IP addresses are assigned and topologically
positioned in the network. Generally an anchor node must be
provisioned with enough addresses to handle all simultaneously
attached users, plus enough headroom to handle failover from an
adjacent anchor node in the event of an outage. Capacity planning
generally ensures that all anchor nodes have approximately the same
number of attached users at steady state. Moving addresses between
anchor nodes would require significant renumbering effort and
substantial increases in operational complexity, so cannot be
performed during an outage. Generally addresses are not renumbered
between anchor nodes: instead, aggregation nodes can be rehomed as
needed to balance steady state capacity levels. Because of the 3GPP
architecture’s failover and capacity planning requirements, all
cellular networks target approximately 50% simultaneous usage of each
anchor node’s IP addresses. However, even at 50% usage, the total
number of subscribers generally exceeds the number of addresses
needed.

Currently, a number of mobile networks are using non-RIR-assigned
space internally to meet customer demand. However, there is
insufficient private space (RFC1918, etc.) available for internal use,
so other unassigned space is currently being used. As this unassigned
space is brought into service via reclamation, returns, and transfers,
it is no longer possible to use it internally, so globally unique
space must be used instead. As a result, most of the need for
additional RIR-assigned space is to serve existing customers, not to
accommodate future growth.

Policy statement:

I can see two possible approaches to address this need. One approach
would be to continue counting simultaneously attached users to measure
IP needs, and apply a 50% usage requirement to justify allocations.
Another approach would be to instead count total subscribers (rather
than simultaneously attached users), and apply a much higher
threshold, such as 80% or even 90%, to justify allocations.

Comments:
Timetable for implementation: ASAP