Download Internet Architecture: Lessons Learned and Looking Forward and more Lecture notes Computer Networks in PDF only on Docsity!
Internet Architecture: Lessons Learned and Looking Forward
Geoffrey G. Xie Department of Computer Science Naval Postgraduate School April 2006 (Revised, December 2006)
Abstract
This chapter explores the architectural design of the Internet. The main objectives are: (i) highlight the design principles underlying the Internet architecture and explain their roles in the success of the network, and (ii) identify some of the limitations of the current Internet architecture and present a possible approach to addressing them.
- Introduction
In this chapter, we explore the architectural design of the Internet. We believe that a historic perspective is essential for this exploration. Many important lessons about network design can be learned from the evolution of the Internet architecture. The Internet had a very modest start, borne out of an experimental network with a handful of nodes in the late 1960s. There was no comprehensive theory about packet network design in place at the time. It was not until a dozen or so years later, when the Internet had already become a network with about 100,000 nodes that the broad research community started to realize that several early design choices made for the Internet architecture, with an emphasis on simplicity, had played a crucial role in its growth and robustness. [Clark88] In other words, it is not by accident that the basic elements of the Internet architecture have withstood the test of time for over three decades, creating the one and only global data networking infrastructure in the process; several architecturally profound design principles were at work. In the first half of the chapter, which includes Sections 2, 3, and 4, we will try to expose as many key points of these design principles as possible while describing nuts and bolts of the Internet architecture.
Examining the Internet architecture from a historic perspective would not be complete without pondering the future of the Internet architecture. In the second half of the chapter, we pose and try to answer the following question: Has the current Internet architecture reached the end of its historical role? To put the question another way: Is a clean-slate design of Internet architecture necessary in order to meet all emerging requirements? We first provide a holistic view of the current Internet architecture based on its division of core functionality into three planes: data, control, and management. We then discuss why the Internet control and management planes have fundamental limitations in coping with several emerging service requirements and why a completely new approach to network control and management may be required. Finally, we describe the 4D network architecture [Greenberg05a,b], which is an instance of a clean slate design of Internet architecture.
Report Documentation Page
Form Approved OMB No. 0704-
Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number.
- REPORT DATE DEC 2006
- REPORT TYPE N/A
- DATES COVERED -
- TITLE AND SUBTITLE Internet Architecture: Lessons Learned and Looking Forward
5a. CONTRACT NUMBER 5b. GRANT NUMBER 5c. PROGRAM ELEMENT NUMBER
- AUTHOR(S) 5d. PROJECT NUMBER
5e. TASK NUMBER 5f. WORK UNIT NUMBER
- PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) Naval Postgraduate School Department of Computer Science Monterey, CA 93943
- PERFORMING ORGANIZATION REPORT NUMBER
- SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S)
- SPONSOR/MONITOR’S REPORT NUMBER(S)
- DISTRIBUTION/AVAILABILITY STATEMENT Approved for public release, distribution unlimited
- SUPPLEMENTARY NOTES Handbook of Computer Networks, ed. Hossein Bidgoli, John Wiley & Sons. ISBN-10: 0471784613. November 2007, The original document contains color images.
- ABSTRACT This chapter explores the architectural design of the Internet. The main objectives are: (i) highlight the design principles underlying the Internet architecture and explain their roles in the success of the network, and (ii) identify some of the limitations of the current Internet architecture and present a possible approach to addressing them.
- SUBJECT TERMS
- SECURITY CLASSIFICATION OF: 17. LIMITATION OF ABSTRACT SAR 18. NUMBER OF PAGES 25
19a. NAME OF RESPONSIBLE PERSON a. REPORT unclassified
b. ABSTRACT unclassified
c. THIS PAGE unclassified
Standard Form 298 (Rev. 8-98) Prescribed by ANSI Std Z39-
as practical solutions to specific network design problems [Clark88], we first look back at history and ground our discussion by laying out the key enabling technologies and the key requirements faced by the architects of the early Internet. The purpose of introducing the design principles before describing the detail of the Internet architecture is twofold. First, we believe that one may appreciate many subtleties of the Internet architecture better after having a solid grasp of the big-picture design philosophy of the Internet architecture. Second, as mentioned in the Introduction, the focus of this chapter is on the fundamental design trade-offs and thus we would like to start the discussion at a 30,000 foot level.
2.1. Enabling Technologies
In the pre-Internet era, the communications technology was dominated by a circuit-based approach used by telephone networks. In circuit-switching the bandwidth of each communication link in the network is segmented into multiple smaller transmission channels called circuits, by utilizing either a frequency division multiplexing (FDM) or a time division multiplexing (TDM) technique. [Kurose05] Each circuit can only be allocated to one conversation at a time. Since the number of circuits in the network is finite, a call setup process is required before a conversation can start in order to ensure that there are adequate free circuits to form an end-to-end path between the calling parties.
The static allocation of circuits works well for telephony where the network traffic loads are well understood. However, circuit-switching would cause a significant waste of bandwidth when used to transport computer data traffic such as from a telnet session, which typically is very bursty with long periods of inactivity. This problem motivated people to seek an alternative approach to building networks for linking computer resources, which led to the invention of the packet-switching technique in the early sixties. [WebSite1]
In the packet-switching approach, computer data (i.e., bit streams) are transported in small chunks called packets. The capacity of a communication link is not segmented; packets of different users take turns to be transmitted at the full link rate. This form of dynamic sharing of the whole link capacity among different connections, termed statistical multiplexing, ensures no waste of link bandwidth as long as there are packets to be transmitted.
Statistical multiplexing requires the use of buffers to hold packets waiting for their turn to be transmitted. This type of buffering naturally led to the birth of a “store and forward” communication paradigm in which packets may be forwarded on a hop by hop basis toward their destinations. Under this paradigm, it is also very easy for intermediate nodes to independently adjust routes that packets take based on current network conditions. Such a dynamic routing capability was quickly recognized as a desirable function of a computer network for resisting link or node failures in the network even before the first packet network was ever built. [WebSite 1]
2.2. Driving Requirements
The Internet began as an experimental network called ARPAnet, which was sponsored by the U.S. Department of Defense (DoD) initially for testing the viability of packet switched computer networks and later for demonstrating ways of combining packet networks that use different link technologies (leased phone lines, satellite, radio, etc.) into one integrated data communications infrastructure for the military. [WebSite1] High on the requirement list for the Internet project were:
- Robustness – Because of the military sponsorship, an emphasis is put on the ability of the network to continue to operate in the presence of link or node failures.
- Link heterogeneity – Also important to the military is the network’s ability to rapidly assimilate different link technologies so the network can be quickly deployed and extended.
Other requirements for the Internet architecture included the support for multiple types of communications service and distributed management of network resources. [Clark88] Surprisingly, both network security and quality of services (i.e., performance guarantees) are not in the original list of requirements for the Internet. The reason is simple: ARPAnet was originally envisioned as a private data network for the U.S. military and, as such, security was considered more of a physical layer concern and quality of services deemed a non-issue with the assumption that traffic entering the network would be carefully planned resulting in a lightly-loaded network at all times.
2.3. Design Principles
To meet the overriding requirements of robustness and link heterogeneity, the original architects of the Internet made two important design decisions regarding how to organize the core computer networking functionalities. First they recognized that a monolithic network architecture where each switching node can cope with all link technologies will not scale. [Clark88] The concept of adding specialized packet switching nodes, called Internet Message Processors (IMPs), to the network architecture was developed to address that problem and to take advantage of the then new store-and-forward communication paradigm. Each IMP, which we call a gateway or router today, would be an intermediary linking two or more different packet networks. A three-part address format was defined: one for identifying a communicating process, another for identifying the process’s host computer, and the last one for identifying the host network. A packet would carry both source and destination addresses in its header. A gateway would only need to inspect the network portion of the destination address when making packet forwarding decisions. Once a packet arrived at the destination network, that network would use the other parts of the destination address to deliver the packet to the receiving process. [Cerf74,WebSite2]
computer system. [Saltzer84] The argument can be as stated succinctly as below [Saltzer84]:
End-to-end argument: Functions placed at low levels of a system may be redundant or of little value when the cost of providing them at the low level is factored in.
The Internet is a distributed system with two levels of functionality: the network subsystem at the lower level providing communication services to application clients at the upper level. Under the end-to-end argument or design principle, networking functions that deal with network anomalies such as bit errors, node crashes, packet duplications, buffer overflow, would be best implemented at the end hosts where application client processes reside, particularly when the occurrences of anomalies are too infrequent to make it cost effective to place corrective functions inside the network. [Saltzer84]
- Current Internet Architecture
Today, the Internet has evolved from a U.S. military system prototype into an open, world-wide infrastructure over which a rich set of applications, including Web, E- business, voice over IP (VoIP), video broadcast, and on-line gaming, is deployed. These applications have imposed additional performance and security challenges on the network. New elements have been incorporated into the Internet architecture in an attempt to address these challenges. In this section, we delve into the major building blocks of the Internet architecture: describe their current functionality and trace their evolution path.
3.1. Data Formatting
In the Internet, all types of digital information are encapsulated in packets with a standard format defined by the IP protocol. [RFC 791] At a minimum, a host needs to be able to send and receive packets in that format in order to be connected to the Internet. As discussed in Section 2.3, two types of end-to-end communications service (or transport protocol), TCP and UDP, have been defined on top of IP. Moreover, each application has its own set of agreements on the message format and the method of exchanging these messages. For example, a Web browser uses the HyperText Transfer Protocol (HTTP) protocol [RFC 1945, RFC 2616] to communicate with a Web server. Therefore, the packaging of application data into IP packets at an end host involves several layers of encapsulation, as described below.
3.1.1. Packet encapsulation
Figure 1 illustrates the typical packet encapsulation process at an end host. The “Application data” box represents the sequence of bits for an application-specific message (e.g., an HTTP message requesting a Web page) that is to be sent from the host. In the first encapsulation step, the message is encapsulated in one or more transport-layer
segments with the same TCP or UDP header. (See RFC 793 and RFC 768, or a networking textbook such as [Kurose05], for details about TCP and UDP.) In the next step, each transport-layer segment is encapsulated in an IP packet by prepending an IP header. In the final step, a link-layer frame is created by prepending an additional header and possibly a trailer. The link-layer frame format may vary from network to network, specific to the link layer technology used in each network. For example, the Ethernet format would be used here if the host were part of a local area Ethernet network. It should be noted that the link-layer header and trailer will be removed before the packet is passed to router modules that make routing and forwarding decisions.
Also, each link-layer technology defines its own Maximum Transfer Unit (MTU) parameter: the maximum number of bytes that can be encapsulated in one frame. For example, the MTU size for the Ethernet protocol is 1500 bytes; therefore, the size of an IP packet cannot exceed 1500 bytes in an Ethernet environment. That’s why the application message may have to be encapsulated in multiple transport layer segments. Since there is not a standard MTU size across all link-layer technologies, it may also happen that an IP packet is forwarded to a network with an MTU smaller than the packet’s size. Should the packet be discarded or fragmented into multiple packets of an appropriate size? We defer this topic to Section 3.3 after we have a chance to inspect the IP header format.
3.1.2. IP header format
The IP header format is shown in Figure 2. The individual fields are defined as follows [RFC 791]:
- Version: a 4-bit value indicating the version of the IP protocol used. Currently, we are at version 4, abbreviated as IPv4. Some experimental networks are running IP version 6 (IPv6). We will briefly discuss the features of IPv6 in Section 3.2.3.
Figure 1: Packet encapsulation. From a router’s perspective, all types of application data are encapsulated in IP packets. These packets are delivered using different link-layer technologies hop by hop.
Application data Transport header Network header Link frame Header/trailer
One IP packet, subject to link-specific MTU size
Application data Transport header Network header Link frame Header/trailer
One IP packet, subject to link-specific MTU size
In summary, the IP header format is quite simple, reflecting the desire for imposing minimal requirements for connecting new hosts into the Internet. In accordance with the datagram service, no header fields are provided for recording session-specific state and each packet is required to carry destination address information.
3.1.3. Packet fragmentation and reassembly
The “Identification” field in the IP header is designed to give a unique identifier to each packet upon its generation at a host. Different host operating systems (Windows, Linux, etc.) may use different algorithms for setting this field. Most commonly, the value is derived from reading the host’s system clock. When the packet encounters a network with an insufficient MTU size and thereby needs to be fragmented, i.e., broken down into several smaller packets, the same identifier is inherited by all the fragments. Additionally, the 13-bit “Fragment Offset” field of each fragment packet is calculated based on where the first byte of the fragment is situated, in length of 8-byte double- words, relative to the start of the original packet. One of the bits of the “Flags” field, the More Fragments (MF) bit, is set for all fragments except the last one. This information allows the receiving host to identify and assemble the fragments back into the original packet. It is possible that these fragment packets need further fragmentation at another network with an even smaller MTU. However, reassembly is done only once for the packet at the receiver.
The IP protocol allows the fragmentation/reassembly feature to be turned off by setting another bit of the “Flags” field, the so-called Don’t Fragment (DF) bit. When that bit is set, the packet would be dropped under the scenario described in the previous paragraph. Additionally, the router that dropped the packet would send an error notification message to the sender of the packet via ICMP.
Figure 2: IP header format. [Figure 18.6 of Stalling04] Each row represents a 4 byte word. The total length is always a multiple of 4 bytes after possible padding.
The design of the IP fragmentation/reassembly functionality can be viewed as an application of the “Simplicity over Performance” principle. It certainly has a negative performance impact on the routers that have to perform the checking and the fragmentation. But it avoids imposing a standard MTU size on every link technology and thus removes a potential barrier for connecting a new type of network into the Internet. Instead, a minimum MTU is instituted, which is 576 bytes for the current version of IP (version 4) and 1280 bytes for IP version 6.
3.2. Addressing
The basic approach of the three-level hierarchical addressing scheme as described in Section 2.3 remains unchanged through the years. More specifically, the process portion of the address definition, called port, has been standardized as part of both TCP and UDP header formats, and the network and host portions of the address definition have been combined into one 32-bit value, called IP address, which should be globally unique. For ease of writing, an IP address is usually represented in the so-called dotted-decimal form, in which the 32 bits are partitioned into four bytes written in their decimal form and separated by a period (dot). For example, “192.128.10.168” is the IP address assigned to the network interface installed on the laptop that I use to write this chapter.
3.2.1. Subnet and Subnet Mask
As shown in Figure 3, an IP address is composed of two continuous blocks of bits. The left block contains the “Network bits” and identifies the home network (or subnet) for the host. All network interfaces in one subnet should be assigned the same block of network bits, called the subnet prefix. The right block contains the “Host bits”, which should be uniquely assigned to each network interface installed on a host in the subnet.
To reduce the size of the forwarding tables at routers, routing in the Internet is done based on matching subnet prefixes instead of matching the entire 32-bit addresses. Accordingly, one or more gateway routers should be attached to each subnet. The Internet routing and forwarding algorithms are only responsible for transporting packets to these gateways, which then deliver the packets to the receiving hosts (or more precisely, the network interfaces of these hosts) using a technology specific link protocol. Similarly, packets destined for a remote host (i.e., not in the same subnet as the sending host) also have to depart through the gateways.
Clearly, a method for determining the boundary between the network and host blocks of an IP address is required for extracting the right subnet prefix. For example, “192”,
Network bits Host bits
IP address: total 4 bytes = 32 bits
Network bits Host bits
IP address: total 4 bytes = 32 bits
Figure 3: IP address layout
part of “navy.mil”, and so on so forth. All network domains can be thought of being part of a root domain. A network domain may contain multiple subnets and subnets of the same domain are typically administrated by one domain authority. Since the IP protocol does not recognize FQDNs, DNS provides applications a service that translates an FQDN into its IP address counterpart, and vice versa Each domain authority is responsible for setting up a DNS server that maintains a mapping between the FQDNs and IP addresses of all local hosts in its domain and answers queries about the mapping from either an application running on a local host or a remote DNS server on behalf of a remote application. A detailed specification of the DNS protocol is given in RFC 1035.
The Dynamic Host Configuration Protocol (DHCP) supports auto-configuration of a network interface. To enable this feature on a subnet, one must set up a DHCP server and assign to it a pool of free IP addresses for that subnet. When a host in the subnet is booted up, it will use broadcast to reach, maybe via a relay agent, the DHCP server and request an IP address and other information required for configuring its network interface. In response, the server will typically remove an address from the free address pool and allocate it to the host for a fixed duration. The host will contact the server to renew the allocation periodically when it stays up for a long time. The host may also contact the server to explicitly return its address to the pool of free addresses, e.g., when the host is being shut down. A detailed specification of DHCP can be found in RFC 951.
3.2.3. NAT and IPv
In the mid 1990s, due to years of explosive growth of the Internet, a crisis of IP address shortage seemed looming. Theoretically, the 32-bit address space provides close to 4 billion unique addresses. However, even with classless network allocation, a significant percentage of allocated addresses are unused and thus wasted. Also, many addresses are reserved for special purposes: broadcast, multicast, private, etc., and not available for hosts. Therefore, when people started to talk about connecting everything, from cell phones to toasters, to the Internet, it was perceivable that the pool of unallocated IP addresses could soon run dry. In response to this crisis, two major solutions were proposed. One was supposedly a near-term fix which requires no change of the current IP address format and the other was touted as a long-term solution which changes the address format to make it 128-bit long.
The near-term solution is called Network Address Translation (NAT), specified in RFC
- In this scheme, a network’s external connection must go through a NAT server. The server replaces the source address and source port pair of every outgoing packet with its own IP address and a “surrogate” source port that is unique to a specific source address and source port combination. In other words, there is a one-to-one mapping between a source address and source port combination to a “surrogate” port. The NAT server records such mappings in a hash table keyed by the value of the “surrogate” port. The server also inspects every incoming packet, uses the packet’s destination port field as the key to find the right address mapping for the packet, overwrites the destination address and destination port fields with the ones obtained from the mapping, and finally
forwards the packet on inside the network. Thus, it is not necessary to assign globally unique addresses to hosts inside the network. A common practice is to use private address ranges for these hosts. Only the NAT server needs to have a globally unique address, making NAT an effective solution for mitigating the address shortage problem.
The long-term solution requires upgrading the IP protocol (version number 4) to a new version, IP version 6 (IPv6). In addition to a drastically larger address space than IPv4, IPv6 also includes new features such as auto-configuration and a streamlined header structure. Interested readers are referred to RFC 2460 and [Davies02] for details about IPv6.
3.3. Dynamic Routing
Routing in the context of the Internet is about maintaining consistent forwarding tables at the routers, in accordance with the network’s store and forward communication paradigm. In the early days of the Internet, routing was not a major issue because of the small number of networks connected to it. Routing within a network was often done with a private protocol and routes between networks were static and manually set up. [Clark88] Later, as the size of the Internet grew, dynamic routing became necessary as the topology of the network constantly changed.
Before we delve into routing, let’s briefly look at how forwarding is done given consistent forwarding tables at all routers. As mentioned in Section 3.2.1, the forwarding is done by matching subnet prefixes. A typical forwarding table at a router, often referred to as the Forwarding Information Base (FIB) for the router, contains entries (i.e., routes) in the format of: , , . is the subnet prefix of the destination network for this route, the interface to use as part of this route to reach the destination, and a measure of goodness of this route. To forward a packet, the router first looks up its FIB with the packet’s destination address and looks for subnet prefix matches using the method described in the end of Section 3.2.1. When the packet’s destination address matches multiple routes in the FIB, the router chooses the route with the longest prefix match, i.e., with the most matching network bits. If there are more than one longest prefix matches, the router uses the field to break the tie. After determining a route, the router forwards the packet to the output port as defined by that route’s .
3.3.1. Hierarchical organization of networks
To scale to millions of networks, a two-level routing hierarchy has been defined for the Internet, analogous to the “first state, then city, and finally street” way of delivering mail by the post offices. At the top level, routing is done among network domains. Each domain is designated as an autonomous system (AS) and assigned a unique 16-bit AS number for routing purposes. For example, my school’s domain “nps.navy.mil” is also AS 257. Currently, there are about 30,000 active ASes in the Internet. At the bottom level, within an AS, routing is done between routers inside that AS. This “divide-and-
The AS-level topology is a mesh, with each AS having connectivity with one or more other ASes based on business agreements. Because ASes are independently managed, there is no uniform scale for the link cost metric across different ASes. So determining the distance between two ASes based on adding link costs is not very meaningful. Instead, policy is more important in inter-domain routing. For example, an Internet Service Provider (ISP) may choose to avoid a particular AS (belonging to a competitor) in all its routes. To assist policy based routing, the Internet uses a path vector protocol called Border Gateway Protocol (BGP) for inter-domain routing. [RFC 4271] Each AS sets up one or more BGP border routers for exchanging path vectors, each of which is a full sequence of ASes to use to reach a specific destination network, with border routers of neighboring ASes. In general, an AS will advertise a route learned from one neighbor to other neighbors after appending its own AS number to that route. Policy-based actions may be specified in three stages of BGP operation at a border gateway. First, import filters may be placed to reject certain routes received from a neighboring AS. Second, policy may be defined regarding how multiple imported routes for the same destination are ranked. Third, export filters may be placed to restrict the scope of route advertisements to neighboring ASes.
3.4. Resource Allocation
Resource allocation did not receive serious consideration in the original design of the Internet architecture because of the datagram service principle. However, as the reach of the Internet extends and the access speed increases, latency or loss sensitive applications such as video phone start to be deployed. These applications require the network to provide some minimum level of performance guarantee with respect to throughput, packet delay, packet loss rate, etc. A new catch phrase, quality of services (QoS), has since been coined by the networking community to refer to the level of performance guarantee a computer network provides.
While some people still view over-provisioning, i.e., making bandwidth so abundant that link congestion is unlikely, as a viable solution to all QoS problems, both the network research and operational communities have recently explored alternative solutions aimed at avoiding link congestion through elaborate resource allocation schemes. These efforts are described below.
3.4.1. Traffic engineering
Traffic engineering involves adapting the flow of packets through the network based on a given set of performance objectives and the traffic matrix, i.e., the observed typical volume of traffic from each ingress point to each egress point. Often, a network designer needs to deal with conflicting performance objectives, such as minimizing the maximum link utilization and bounding the propagation delay between each pair of routers. Satisfying them simultaneously for a dynamic network environment is very challenging under the current Internet architecture. A good commentary on the existing traffic engineering approaches is given in [Rexford04], which we will quote below:
“Early attempts to engineer the flow of traffic involved extending the routing protocols to compute load-sensitive routes in a distributed fashion. In these protocols, the cost of each link is computed as some (possibly smoothed) function of delay or utilization, in order to steer packets away from heavily-loaded links. However, routing oscillations and packet loss proved difficult to avoid, since routers were computing routes based on out-of-date information that changed rapidly, and the effort was eventually abandoned. To improve stability, the distributed algorithms were extended to compute a path for groups of related packets called flows. These load-sensitive routing protocols can have stability problems as well, unless the dynamic routing decisions are limited to aggregated or long-lived flows. Perhaps more importantly, the protocols require underlying support for signaling and distributed algorithms for optimizing paths for multiple metrics.
Many existing IP networks have instead adopted a centralized approach for engineering the flow of traffic using traditional IP routing protocols (e.g., OSPF). In this scheme, the management plane collects measurement data to construct a network-wide view of the offered traffic and the network topology. Since the optimization of the OSPF weights is an NP-complete problem, the management plane conducts a local search through candidate settings of the link weights, looking for a solution that satisfies the various performance objectives. Considering additional performance metrics is as simple as changing the objective function used to evaluate the solutions. However, this approach has its limitations in satisfying different metrics for traffic to different destinations, and for avoiding disruptions during failures and planned maintenance. Ultimately, having a single integer weight on each link is not sufficiently expressive, though this approach has proven very useful in practice.”
3.4.2. Integrated Services (IntServ) Model
In the early 1990s, the network research community made a serious attempt to extend the datagram service model and retrofit a QoS solution over the Internet. The effort was motivated by the seminal work of Parekh and Gallager which shows that the end to end delay of one application’s packets can be upper bounded regardless of the behaviors of other applications if an appropriate packet scheduling algorithm, such as Packetized Generalized Processor Sharing (P-GPS) or weighted fair queuing (WFQ), is used at every output link that the packets traverse. The new service model was named Integrated Services (IntServ) after its lofty goal to meet the QoS requirements of all types of application data including interactive audio and video. [RFC 1633] The core of the service model is a new type of service called “guaranteed service”, which provides a deterministic (i.e., for 100% of the packets) guarantee of performance, in terms of maximum end-to-end packet delay and minimum throughput, on a per application basis. All packets for an application that has subscribed to this service traverse the same set of links, and are referred to as a flow. The flow has a separate buffer at each output link and receives a guaranteed rate of service from the packet scheduling algorithm based on the flow’s bandwidth requirement. Clearly, in order for the guaranteed service to work, the application must reserve network resources (link bandwidth, buffer, etc.) along a network
time as part of the MPLS connection (tunnel) set-up process performed by a Label Distribution Protocol (LDP).
MPLS is mostly used by an ISP as a local traffic engineering solution, often combined with DiffServ mechanisms. Typically, a set of MPLS tunnels is preconfigured within the ISP’s network. The ingress routers of the ISP classify all arriving packets based on their header fields, and insert corresponding MPLS header fields at the output link for those classified to be transported by one of the MPLS tunnels. More information about MPLS can be found in RFC 3031.
3.5. Security
For the reason explained in Section 2.2, security was not high on the original list of goals for the Internet. Today, with the Internet becoming an open infrastructure for E- commerce and E-government, security is one of the most pressing issues faced by the Internet community. Several security mechanisms such as firewall, virtual private network, transport layer security, secure email, and public key infrastructure (PKI), have been added to the Internet architecture with some level of successes. Two of them are described below.
3.5.1. Firewall
A firewall is a combination of specialized hardware and/or software acting as a network’s security gate that can restrict types of communication between the network and the public Internet, mainly to prevent unauthorized access to the network’s resources. Typically, a firewall administrator has configured the firewall with a set of packet filtering rules based on security policy. The firewall inspects the header fields of all packets that come in and out of the network and drops those matching the filtering rules. For example, a firewall may only allow Web traffic to come in the network by filtering out all packets that don’t carry an HTTP payload. A firewall can also be stateful in that it will try to enforce certain communication patterns involving several packet exchanges. For example, a stateful firewall will deny a TCP connection response (so-called TCP SYN-ACK message) from coming in if it has not seen a corresponding connection request going out.
3.5.2. Virtual Private Network (VPN)
Often an organization spans multiple geographical locations. It’s very expensive for this organization to build a private data network with leased lines to connect all its sites. An alternative approach is to use the public Internet for connectivity and rely on additional security protocols for data privacy, resulting in a virtual private network (VPN). Currently, most VPNs are built by setting up a VPN proxy between each site network and the Internet. The proxies run a tunneling protocol that allows packets for this VPN to be encrypted and encapsulated with additional headers at the proxy of the source site and then decrypted and de-capsulated at the proxy of the destination site. By treating the network as black box, VPN is a design based on the end-to-end argument. There are two
types of VPN tunneling protocols: some, like L2TP, run at layer 2 (link layer), and the others, like IPsec, run at the layer 3 (IP layer). L2TP and IPsec are defined in RFC 3931 and RFC 4301, respectively.
In summary, the current security techniques for the Internet focus on establishing a security perimeter around a network and preventing unwanted traffic from coming in. Very little can they do to defend against attacks originated inside the security perimeter. It is also very difficult to verify if the security perimeter has been properly configured or if the security perimeter will hold in the event of link or node failures. [Xie05]
- Future of Internet Architecture
Starting from this section, we will look forward and examine the future of the Internet architecture. Several stirring proposals like [Clark03] and [Greenberg05b] have come out recently calling for a clean slate design of the Internet architecture. Regardless of whether they will stand the test of time, these proposals constitute serious efforts aimed at understanding the limitations of the current Internet architecture and seeking future directions in network design. Due to space constraints, the rest of the discussion will be based mainly on one of them, called the 4D architecture. [Greenberg05b]
The 4D architecture was conceived by a team of researchers from Carnegie Mellon, Princeton, AT&T Research, and Naval Postgraduate School, including the author of this chapter. The 4D architects argue that the current Internet architecture has reached the end of its historical role because it does not have intrinsic capacity to meet emerging QoS and security requirements and the bandage solutions such as presented in Sections 3.4-3. are creating an even bigger problem by inducing bewilderingly high network management complexity. [Greenberg05a,b]
To better understand this argument, let’s introduce another abstraction of the Internet architecture based on the time scale of execution of its constituent functions. Specifically as described in [Rexford04], the current Internet architecture can be decomposed into three planes:
“Data plane: The data plane is local to an individual router, or even a single interface card on the router, and operates at the speed of packet arrivals, down to nanoseconds per packet. For example, the data plane performs packet forwarding, including the longest-prefix match that identifies the outgoing link for each packet, as well as the access control lists (ACLs) that filter packets based on their header fields. The data plane also implements functions such as tunneling, queue management, and packet scheduling.
Control plane: The control plane consists of the network-wide distributed algorithms that compute parts of the state in the data plane. The convergence times of these algorithms vary from seconds to minutes. For example, the control plane includes BGP update messages and the BGP decision process, as well as the Interior Gateway Protocol (such as OSPF), its link-state advertisements (LSAs), and the Dijkstra's
