One document matched: draft-dickson-v6ops-aggregation-00.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "D:/Program%20Files/XML%20Copy%20Editor/dtd/rfc2629.dtd" [
  <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
  <!ENTITY rfc791 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0791.xml'>
  <!ENTITY rfc1519 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1519.xml'>
  <!ENTITY rfc4291 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml'>
]>
<rfc ipr="full3978" docName="draft-dickson-v6ops-aggregation-00">
<?rfc toc='yes'?>
  <front>
    <Creation month="February" year="2008" day="5" />
    <creation month="February" year="2008" day="5" />
    <created month="February" year="2008" day="5" />
    <title abbrev="Aggregation Methods and Benefits">
Aggregation: Methods and Benefits, for IPv4, IPv6 or other binary addresses
</title>
    <author initials="B.P." surname="Dickson" fullname="Brian Dickson">
      <organization>
Afilias Canada, Inc
</organization>
      <address>
        <postal>
          <street>
4141 Yonge St,
</street>
          <street>
Suite 204
</street>
          <city>
North York
</city>
          <region>
ON
</region>
          <code>
M2P 2A8
</code>
          <country>
Canada
</country>
        </postal>
        <email>
briand@ca.afilias.info
</email>
        <uri>
www.afilias.info
</uri>
      </address>
    </author>
    <date month="February" year="2008"/>
    <area>Internet</area>
    <workgroup>v6ops</workgroup>
    <keyword>
IPv6
</keyword>
    <abstract>
      <t>
This Internet Draft discusses general benefits of aggregation, with quantitative examples of different aggregation strategies for the same set of allocations.
Recommended "best practices" for service providers and enterprises are listed, as well as "how-to" information.
</t>
    </abstract>
    <note title="Author's Note">
      <t>This Internet Draft is intended for Informational status, for v6ops or other suitable WG.
            <vspace blankLines="1" />
      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      <xref target="RFC2119" />
      </t>
    </note>
  </front>
  <middle>
<section title="Background">
<t>
IPv4 and IPv6 are both protocols with address schemes that involve binary addresses, and longest-match routing.

This allows for routing tables with overlapping network entries who differ in length of the entry.

The real benefit of longest-match routing, is that summary routing information, i.e. aggregate routes, can be used without needing the more-specific prefixes.

Distribution of more-specific prefixes can be limited to locations where they are needed to disambiguate next-hop choices. This tends to be topologically restricted, and thus only the aggregate routes are needed in the wider distribution of prefixes.

In order to achieve maximum benefit from this set-up, however, allocation of prefixes needs to be done in such a way as to support aggregation. Prefixes need to be assigned from topologically-appropriate aggregate blocks.

We do not discuss the assignment techniques within these block in this document; that is a subject for another document.
</t>
</section>
<section title="Description of the Problem: Route Table Scaling">
<t>
The problem being addressed is the practical operational issue on the (hybrid IPv4+IPv6) Internet: routing table size.

Table size is impacted by address aggregation and address allocation - two activities that goe hand-in-hand.

This is true both in the context of the global routing table, as well as the internal routing table requirements of individual ISPs and enterprises.

Routing convergence time, while less obvious, is another function which is scale-sensitive.

And hardware forwarding tables (where they exist) are very scale-limited, expensive, and generally only upgradeable by upgrading the routers containing them. These grow approximately 1:1 with the routing table for any given router.

Aggregation itself cannot be controlled directly or mandated alone, it should be noted. The ability to aggregate is driven directly by the allocation schemes used.
</t>


</section>
<section title="Allocation vs Aggregation">
<t>
Aggregation is the act of combining a number of smaller things into a bigger thing.

In the context of prefixes in an internet, aggregation can only occur on bit boundaries, and only when objects being combined are contiguous, with sufficiently similar properties (such as as-path).

Most important is the contiguous property. Consequently, one way to view aggregation is as the reverse of de-aggregation, i.e. announcing more-specific prefixes from a CIDR block.

Unless an initial allocation and any reservation for further allocation are contiguous, no aggregation between the two is possible.

So, initial and subsequent allocations from the same larger block,  in fact look like a de-aggregation followed by aggregation.

Internal use and assignment can similarly be viewed as de-aggregation, with the summarization happening at the border of the entity doing the aggregation (e.g. ASN border router.)
</t>
</section>
<section title="Block Allocation vs Assignments">
<t>
In order to avoid confusion, we will refer to allocations of prefixes to third parties (e.g. end-users), or of internal prefixes to groups or departments (for an enterprise) as "Assignments".

When we use the term "Allocation" we are referring to the creation of an aggregate block out of which subsequent assignments will be made.

The main issues we are concerned with are:
<list style="symbols">
<t>Size of allocations</t>
<t>Structure of allocations</t>
<t>Size-specific allocation pools</t>
</list>
</t>
</section>
<section title="Locations for allocations">
<t>
Bottom-tier allocations should be made as close to customers as possible - ideally on aggregation routers.
Subsequent tier allocations should be made wherever topology permits, such as by Point-of-Presence (POP), city, region, and continent, as appropriate.
</t>
</section>
<section title="Allocation Pools">
<t>
It is not strictly necessary to create pools from which only one size of assignment is made. While it may be simpler to administer, it leads to inefficiency, especially when too many pool sizes are needed, or where per-size pools do not map well to the aggregation topology.
The main considerations should be whether there is uncertainty over the distribution of larger assignments among the allocation blocks, and whether the sizes of assignments might be so large as to dominate blocks.

It should be reasonable to include assignments (in terms of predicted use by allocation) up to 1/4 the size of the allocation block itself.
The presence of predicted/reserved space in the allocation which is unused is not likely to dramatically affect the HD ratio for a few instances.
And with optimum assignment techniques, assignment ability is not order-sensitive. This means that if sufficient space remains, assignments should be possible. Exhausting an allocation is not overly significant. The only impact is that a new allocation is needed when this occurs.
</t>
</section>
<section title="Sizes of allocations">
<t>The way to ensure proper sizing of allocations is to guage the per-location requirements, in terms of number of assignments and assignment sizes, and to work bottom-up.

At each layer of aggregation, the total of assignments needed (in binary) gets rounded up to the next power of 2. This becomes the appropriate allocation size.

Note well: the sizes of "sibling" allocations within a higher-tier allocation block, do not need to be the same. Variable-size blocks should in fact be expected. Efficient assignment techniques are sufficient to ensure optimum packing of the subordinate allocations.

Depending on the address assignment regime, it may be appropriate to "pad" the assignments themselves universally, e.g. by adding some number of bits to the size, such as 4 bits.

This is iterated at each layer of the hierarchy of aggregation.
The presumption is that assignments can and will be made with near-optimal efficiency.

It is necessary to work from some basic understanding of the ability to populate customer assignments on the bottom-tier aggregation locations:
<list style="symbols">
<t>Slightly conservative is better than either extreme.</t>
<t>Too small an allocation results in poor aggregation and little-to-no benefit.</t>
<t>Too large an allocation can result in space exhaustion, renumbering, or hole-punching, all of which are bad results.</t>
<t>Slightly small means some allocations might be outgrown, with little waste.</t>
<t>Slightly large means room for growth by customers is available.</t>
<t>At the bottom level, the very-long-term view should be taken, e.g. max out the access equipment allocations</t>
</list>
</t>
<section title="Example">
<t>
Let's consider a medium-sized ISP, with a mix of business and residential DSL customers.
The ISP has several POPs in a few cities.
The ISP decides that residential customers will get /56 prefix assignments (e.g. via DHCP with prefix delegation), small businesses also get /56's, and large businesses get /48's.
Here is how the bottom-up worksheet would be done, and what the allocation block sizes would be.
Note the differences in sizes of siblings.
<list style="hanging">
<t hangText="City A">
<list style="hanging">
<t hangText="POP A1">
<list style="empty">
<t>Residental DSLAM 1: 200 x /56 -- aggregate of /48</t>
<t>Residental DSLAM 2: 600 x /56 -- aggregate of /46</t>
<t>Residental DSLAM 3: 2000 x /56 -- aggregate of /45</t>
<t>Residental DSLAM 4: 200 x /56 -- aggregate of /48</t>
<t>Total aggregate for POP A1 -- aggregate of /44</t>
</list>
</t>
<t hangText="POP A2">
<list style="empty">
<t>Business DSLAM 1: 200 x /56 + 10 x /48 -- aggregate of /44</t>
<t>Business DSLAM 2: 20 x /48 -- aggregate of /43</t>
<t>Residental DSLAM 3: 1000 x /56 -- aggregate of /46</t>
<t>Residental DSLAM 4: 500 x /56 -- aggregate of /47</t>
<t>Total aggregate for POP A2 -- aggregate of /42</t>
</list>
</t>
</list>
Total aggregate for City A -- aggregate of /41
</t>
<t hangText="City B">
<list style="hanging">
<t hangText="POP B1">
<list style="empty">
<t>Residental DSLAM 1: 200 x /56 -- aggregate of /48</t>
<t>Residental DSLAM 2: 500 x /56 -- aggregate of /47</t>
<t>Residental DSLAM 3: 200 x /56 -- aggregate of /48</t>
<t>Total aggregate for POP B1 -- aggregate of /46</t>
</list>
</t>
<t hangText="POP B2">
<list style="empty">
<t>Business DSLAM 1: 30 x /56 + 4 x /48 -- aggregate of /45</t>
<t>Business DSLAM 2: 10 x /48 -- aggregate of /44</t>
<t>Residental DSLAM 3: 200 x /56 -- aggregate of /48</t>
<t>Residental DSLAM 4: 500 x /56 -- aggregate of /47</t>
<t>Total aggregate for POP B2 -- aggregate of /43</t>
</list>
</t>
</list>
Total aggregate for City B -- aggregate of /42
</t>
<t hangText="City C">
<list style="hanging">
<t hangText="POP C1">
<list style="empty">
<t>Residental DSLAM 1: 200 x /56 -- aggregate of /48</t>
<t>Residental DSLAM 2: 600 x /56 -- aggregate of /46</t>
<t>Residental DSLAM 3: 2000 x /56 -- aggregate of /45</t>
<t>Residental DSLAM 4: 200 x /56 -- aggregate of /48</t>
<t>Business DSLAM 5: 4 x /48 + 20 x /56 -- aggregate of /45</t>
<t>Total aggregate for POP C1 -- aggregate of /43</t>
</list>
</t>
</list>
Total aggregate for City C -- aggregate of /43
</t>
</list>
Total aggregate for ISP -- aggregate of /40
</t>
</section>
</section>
<section title="Benefits and Consequences of Hierarchical Aggregation">
<section title="Caveats">
<t>
Aggregation, allocations, and assignments are not one-time events. They are necessarily a process, which must be maintained with great dilligence, if the benefits are to be maintained.

The effort required in keeping this ordered structure, is substantially less than that of having to clean up the results of badly managed address allocations.

The main caveat, however, is that all address assignments *and* allocations, must be viewed, at all levels, as "non-portable".

Assignments and allocations are fundamentally tied to their topological locations.

And this means: If an entity gets moved topologically, all assignments or allocations must be renumbered.
The new assignments or allocations, must come from the new topological parent.
The old assignments/allocations must be returned to the old parent.

As a general rule, those who move more often, should have less dependence on the permanence of their addresses. This means that the impact to the recipient of addresses, should not be dire.

It also means, that operators should ensure that they have tools which are as good at supporting renumbering, as they are at numbering new recipients.
</t>
</section>
<t>
The following IPv6 example is used to demonstrate the number of prefixes needed, for reaching destinations in an Ingerior Gateway Protocol (IGP) area, of a given size.

The laws governing scalability are identified, and examples used to illustrate how important scaling is to IGPs regardless of specific IGP technology.

The presumption being made is, that allocation is made according to the topology, and that aggregation is done to the maximum degree possible, everywhere it is possible.

<list style="symbols">
<t>IPv6 address block (allocated out to LIR networks): /32</t>
<t>Customer end assignments: /56</t>
<t>Number of bits of allocation ability: 24</t>
<t>Maximum number of prefixes to assign: 2^24 (approximately 16M)</t>
</list>


<figure anchor="v6fmt">
<artwork>
                                                                      1
 0                             3 3                5 5         6 6     2
 1                             2 3                6 7         4 5     8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Network Block (PA from RIR)  | Subnet Hierarchy | Cust_Bits | IfId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>

Each value in the Subnet Hierarchy, is a different discrete assignment (/56) to an end site.
Cust_Bits are the subnets within the end-site prefix.

<figure anchor="hier">
<preamble>
The following table compares different structures of Subnet Hierarchy.
</preamble>
<artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        | No. Bits per level | Total prefixes on ABR per level |
+        -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Levels |   1  |   2  |   3  |     1    |     2    |     3     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   1    |  24  |      |      |    16M   |          |           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   2    |   8  |  16  |      |   66k    |   65k    |           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   2    |  12  |  12  |      |    8k    |    4k    |           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   3    |   8  |   8  |   8  |   512    |   513    |   257     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>

We'll use the examples from <xref target="v6fmt"></xref> and <xref target="hier"></xref>, and extrapolate the rules on prefix counts in a multi-level aggregation regime.

First case: all of the assignments are made without any aggregation. The IGP needs to carry all 16M prefixes. It would likely have some difficulty coping with storing those, let alone achieving routing convergence, with today's technology.

Second case: a two-level hierarchy, with the delineation point is at the /40 boundary. This gives a top-level IGP carrying 8 bits of aggregated prefixes, or 2^8 = 256 prefixes.Similarly, the second level has 2^16 prefixes, or 65k prefixes. That is still a substantial number.

Third case: a two-level hierachy, with both the top level and the second level having about of 2^12 of each kind of prefix. The routers in the IGP doing aggregation would have 2 * 2^12, about 8k prefixes.

Fourth case: a three-level hierarchy. The router bordering level 2 and level3 would also need the third level prefixes, but for the first-level prefixes, would need only the single super-aggregate for the whole block.

If each of the boundaries is an 8-bit boundary, the second-from-the-bottom tier routers in the IGP would need 1 + 2^8 + 2^8 prefixes, or 513 prefixes. Hierarchical assignments result in drastic reductions in number of prefixes needed.

</t>
<section title="Law of Scaling"><t>
The general rule on hierarchical maximum prefix count is, the maximum of values (1 + 2^Bi+2^B(i+1)), where Bi is the number of bits used for level "i" of the heirarchy.

Thus, the greatest benefit is achieved by putting an upper bound on max(Bi), i.e. minimize size of each layer of the hierarchy. This can be done by aggregating at every reasonable place topologically suitable for aggregation.
</t>
</section>
<section title="Routing Table Size">
<t>
Hierarchical aggregation results in routers typically seeing only prefix information at the same level of the hierarchy as itself, plus summarization prefixes for one higher level of the hierarchy seen by aggregators themselves. This drastically reduces the requirements for the size of routing tables within an organization.

This benefit continues to be seen, even when aggregation routers grow beyond their initial aggregation pool, and need subsequent pools assigned, so long as those additional aggregates are also assigned from the hierarchy.
</t>
</section>
<section title="Routing Stability">
<t>
Aggregation also limits the impact of routing updates. In a hierarchy of aggregations of prefixes, aggregation typically suppresses reachability information for more-specific prefixes.
This limits the scope of routing flaps, and improves network-wide routing stability. Routing flaps propogate only to the aggregator, and not higher in the hierarchy.
</t>
</section>
<section title="Routing Convergence">
<t>
Thus, we can see that not only external aggregation at the top level, but hierarchical aggregation within a block of addresses, has benefit and is highly recommended for any organization with sufficient resources (address space) allocated to it.
Routing convergence scales by an order of N*log(N) where N is the number of prefixes. Reducing N by ORDERS of magnitude have profound benefits on speed of convergence, i.e. also orders of magnitude.

The fewer prefixes there are in a routing table, the faster routing can converge. This is especially true for SPF protocols, such as OSPF or ISIS. Convergence time is on the order of Log(N) for N prefixes.
The smallest number N is achieved with routing topologies that implement hierarchical aggregation which mirrors topology.
(This is classic OSPF summarization methodology.)
</t>
</section>
</section>
<section title="Security Considerations">
<t>
Owing to the abstract nature of this document, there are no security considerations.
</t>
</section>
<section title="IANA Considerations">
<t>
This document has no actions for IANA.
</t>
</section>
    <section title="Acknowledgements">
<t>
The author wishes to acknowledge the helpful guidance of Joe Abley, Brian Haberman, and Jari Arrko.

The author also thanks to Marla Azinger, Scott Leibrand, Bob Hinden, and Iljitsch van Beijnum.
</t>    
    </section>
  </middle>
  <back>
    <references title="Informative References">
    &rfc791;
    &rfc2119;
    &rfc1519;
    &rfc4291;
    </references>
  </back>
</rfc>