Draft Policy ARIN-2013-2: 3GPP Network IP Resource Policy [Archived]
OUT OF DATE?
Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.
Status: Abandoned
Tracking Information
Discussion Tracking
Mailing List:
Formal introduction on PPML on 27 March 2013
Origin - ARIN-prop-184
Draft Policy - 27 March 2013
Remains on AC’s docket - 29 April 2013
Abandoned by the Advisory Council - 25 June 2013
ARIN Public Policy Meeting:
ARIN Advisory Council:
AC Shepherds:
Scott Leibrand and Robert Seastrom
ARIN Board of Trustees:
Revisions:
Implementation:
Draft Policy ARIN-2013-2
3GPP Network IP Resource Policy
Date: 27 March 2013
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.
Timetable for implementation: ASAP
OUT OF DATE?
Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.