Introduction to eFIT
The Internet has been a great success as a commercial system. However, recent practices such as site multihoming and prefix splitting by customer networks has shown that the Internet routing architecture suffers from serious scalability issues. The following figure attempts to capture the scaling challenge facing the Internet.
The figure shows that all global ISPs, and some regional ISPs, have a presence in New York; a large number of customers connect to the Green ISP at New York; similarly (not shown in the figure) a large number of customers also connect to other ISPs in the same location. An entry in the global routing table is required to be able to reach each New York customer through any of the ISPs it connects. Ideally the global routing table size should be proportional to the number of ISPs, in addition it may also be a function of the number of major metro locations where ISPs interconnect. With multihoming and traffic engineering, however, the current routing table size is driven by the product of the number of ISPs, the number of metro locations, and the number of customers connected at each {ISP, metro}.
Furthermore, customer networks desire Provider Independent (PI) prefixes in order to avoid renumbering when changing providers. The use of these PI prefixes also naturally fits the multihoming practice, since a customer network can now simply ask each of its providers to announce its PI prefix, or a fragment of it. These customer desires, however, directly conflict with that of the providers who strive to keep global routing table size moderate and stable through the use of Provider Allocated (PA) prefixes that can be aggregated for routing scalability. Another major factor regarding routing scalability is the amount of update messages routers must process in real time. Because of the flat nature of the Internet routing, a routing flap to any destination can trigger routing updates to be propagated through the entire Internet, even when no one communicates with the unstable destination before its connectivity recovers.
In addition to scalability challenges, the routing infrastructure itself suffers from security threats originating from edge sites. For example, since router addresses are globally visible and accessible, low security end-hosts could be compromised to form bot-nets which could DDoS these routers and bring down portions of the Internet.
To solve the scalability problems and to help alleviate the security threats to the routing infrastructure, eFIT proposes two important architectural changes, namely,
- Separating transit networks from edge networks , and
- A new address structure that embeds organization and location information.
Separating Transit Networks from Edge Networks
eFIT distinguishes between Edge Networks (ENs), which act as sources or sinks for data packets, and Transit Networks (TNs), whose primary role is to provide data transit service at the inter-domain level. eFIT puts all the TNs in one address space, and all the ENs in a separate address space. A TN address identifies a connection point to the Internet backbone. A EN address identifies an interface of a customer host. In other words, one may call TN address space the locator space, and EN address space the identifier space.
In the locator space, provider networks interconnect to form the Global Transit Network (GTN). A provider routing protocol (e.g., such as today's BGP) runs between GTN routers to maintain reachability among all the TNs. Individual customer networks, on the other hand, operate in the identifier space and use a customer routing protocol (e.g., such as today's OSPF) that maintains routes to reach internal subnets and its immediate neighbors (its providers or other directly connected customer networks). The two different address and routing spaces are interconnected by those links that connect customer networks to their providers. No routing protocol runs across the links between TN and EN routers.
In eFIT, end-to-end data delivery across GTN is achieved by encapsulating customer packets in a GTN packet header, with the source address as the GTN entry router and the destination address as the GTN exit router. A mapping service is needed to map a destination customer address to the corresponding exit router(s) address in the provider space.
The above figure illustrates a typical packet forwarding
example. When a source host Src (in customer network S) sends a packet to a destination host Dst (in customer network D), the packet will be forwarded to one of S's providers, say A. The mapping service maps the address Dst to GTN exit router (P2) that connects to D. The ingress GTN border router P1 then encapsulates the packet with its own address as the source and P2's address as the destination, and forwards it to P2. Upon receiving the packet, P2 will decapsulate it and send it to D. Viewed from customer networks, the GTN is a single logical hop connecting all customer networks.
New Address Structure
Currently, aggregation is risky at best. Addresses contain no information about whether a prefix shares a common provider or common location. We propose a new address structure with fixed boundaries between subfields, to enable aggregation at any desired level.
