Overview Of The SPP Architecture
This section gives an overview of the SPP architecture. It describes the key hardware and software features that make it possible to support the main abstractions provided to an SPP slice/user:
- Slice
- Fastpath
- Meta-Interface
- Packet queue and scheduling
- Filter
Coupled with these abstractions are the following system features:
- Resource virtualization
- Traffic isolation
- High performance
- Protocol extensibility
These features allow the SPP to support the concurrent operation of multiple high-speed, virtual routers and allows the user to add support for new protocols. For example, one PlanetLab user could be forwarding IPv4 traffic while a second one could be forwarding I3 traffic. Meanwhile a third user could be programming the SPP to support MPLS.
We begin with a very simple example of an IPv4 router to illustrate the SPP concepts. Then, we briefly review the SPP's main hardware components. Finally, we describe the architectural features in three parts. The first two parts emphasize the virtualization feature of the SPP while the third part emphasizes the extensibility of the SPP. Part I describes how packets travel through the SPP assuming that it has already been configured with a fastpath for an IPv4 router. Part II describes what happens when we create and configure the SPP abstractions (e.g., create a meta-interface and bind it to a queue) for the router in Part I. Part III sketches how the example would be different if the router handled a simple virtual circuit protocol instead of IPv4.
Contents
IPv4 Example
We begin with a simple example of two slices/users (A and B) concurrently using the same SPP as an IPv4 router (R). As shown in the figure (right), A's traffic is between the endhosts H1 and H3, and B's traffic is between H2 and H4. Traffic will travel over multiple Internet hops from an endhost to router R. Also, H1 and H2 are in the same stub network, and H3 and H4 are in the same stub network. (Note: The IP addresses in the figure were chosen for notational convenience and do not refer to existing networks.) Furthermore, both slices want 100 Mb/s of bandwidth in and out of R. We have purposely elected to make the logical views of the two slices as similar as possible to show how the SPP substrate can host this virtualization.
From a logical point of view, each user of router R needs a configuration (right) which includes, as a minimum, one fastpath consisting of three meta-interfaces (m0-m2), four queues (q0-q3), and six filters (f0-f5). Meta-interface m0 goes to R itself; m1 to H1 and H2; and m2 to H3 and H4.
|
|
The configuration for both slices will reflect these properties of the example:
- Both slices are concurrently using the same SPP;
- They have identical service demands;
- But they are communicating between different pairs of hosts (and socket addresses); and
- The SPP provides fair sharing of its bandwidth.
Thes differences will be reflected in each slice's configuration of R. Their configurations will be identical except for the following:
- The UDP port numbers of their meta-interfaces because the SPP distinguishes between flows through the tunneling.
- Some fields in the filters will reflect the different socket addresses used at the endhosts.
Slices A and B will have the logical views shown in the tables (right). Note the following:
- The total bandwidth of the meta-interfaces (202 Mb/s) can not exceed the bandwidth of the fastpath (FP).
- There should be atleast one queue bound to each meta-interface (MI).
- The highest numbered queues are associated with meta-interface 0 which are for local delivery and exception traffic.
- The only difference between the two tables is that the UDP port number of the MI sockets are 22000 for slice A and 33000 for slice B.
| MIout | |||
|---|---|---|---|
| MIin | m0 | m1 | m2 |
| m0 | f0 | f1 | |
| m1 | f2 | f3 | |
| m2 | f4 | f5 | |
There are six filters. Each meta-interface has two filters, one for each possible meta-interface destination. For example, traffic from m1 can go to m0 or m2.
So, how does the SPP make it appear that each slice has two dedicated 100 Mb/s paths through R even when traffic from both slices is coming in at the same time?
SPP Hardware Components
For a developer, the most important hardware components of an SPP are the Processing Engines (right). There are two types of Processing Engines (PEs): 1) a General-Purpose Processing Engine (GPE), and 2) a Network Processor Engine (NPE). A GPE is a conventional server blade running the standard PlanetLab operating system. A user can log into a GPE (using ssh) and can run processes that handle packets. An NPE includes two IXP 2850 network processors, each with 16 cores for processing packets and an xScale management processor. The NPE has a 10 GbE network connection and is capable of forwarding packets at 10 Gb/s.
All input and output passes through a Line Card (LC) which is an NPE that has been customized to route traffic between the external interfaces and the GPEs and NPEs. The LC has ten GbE interfaces, some of which will have public IP addresses while others will be used for direct connection to other SPP nodes.
The Control Processor (CP) configures application slices based on slice descriptions obtained from PlanetLab Central, a centralized database that is used to manage the global PlanetLab infrastructure. The CP also hosts a netFPGA, allowing application developers to implement processing in configurable hardware, as well as software.
[...[ FIGURE SHOWING 3 PKT PATHS ]...]
When we describe how the SPP processes packets, you will see that:
- For most packets, the main job of the LC is to forward packets to the NPE with the correct fastpath (FP).
- In most cases, packets going to the GPE are from the NPE although they can also come from the LC.
- Packets going to the GPE from an NPE are associated with a FP (e.g., IPv4 ICMP packet).
- Packets going to the GPE from the LC are going to an endpoint configured by a user that is NOT part of a FP.
Keeping these points in mind should make it easier to understand the partitioning of activities among SPP components.
Part I: IPv4 Packet Forwarding
PlanetLab Headers
[...[ FIGURE SHOWING ENCAPSULATION ]...]
Let's focus on slice A's traffic which is coming from socket (9.1.1.1, 11000) at H1 and going to socket (7.1.1.1, 5000) at H2. Conceptually, a transit packet coming to router R has the form (H, (H', D)) where H is the Planetlab (or outer) IP+UDP header, H' is the inner IP+UDP header, and D is the UDP data. The destination socket in H (outer header) will reflect the UDP tunnel associated with m1 (MI 1); i.e., (9.3.1.1, 22000). While the source and destination sockets in H' (inner header) will reflect the source and destination sockets of the application; i.e., (9.1.1.1, 11000) and (7.1.1.1, 5000).
Similarly, if we examine slice B's packets, the destination socket in H (outer header) will be (9.3.1.1, 33000); i.e., the same IP address used by slice A but a different port number. The source and destination sockets in H' (inner header) will be (9.2.1.1, 12000) and (7.1.1.2, 6000) which reflect the different application sockets used by slice B.
If we extended this example so that packets transited through multiple PlanetLab nodes, the outer header H would change as they passed through each node while the inner header H' would remain unchanged. This situation is analogous to the case when an IP packet transits multiple ethernet networks where IP packets are encapsulated in an ethernet frame which changes as the packet moves through the networks but the IP packet header remains fixed.
Forwarding A Packet
XXXXX
a router forwards packets by finding an entry that matches a packet's header and then
It should now be fairly obvious that one way to conceptually support both A's transit traffic and B's
transit traffic is to have a forwarding table
In order to forward a packet
In our example, the SPP would process an incoming transit packet in the following way:
- LC(in): Determine the slice context from the PlanetLab headers and forward the packet to the designated NPE.
- NPE: Create new PlanetLab headers, enqueue the packet for the outgoing MI and forward the packet to the LC.
- LC(out): Add the ethernet header and transmit the frame.
Internal Identifiers
Before describing how these steps are carried out in the SPP, it is worth noting that most of the abstractions presented to a user (e.g., queues, filters) are implemented with corresponding actual SPP components. A user's logical view (e.g., MI 3) is supported by mapping the user's logical resources onto the SPPs actual resources. A user's queues, filters and meta-interfaces are mapped to the SPP's actual queues, filters and meta-interfaces that have been assigned to the user as part of its context. The user's abstract components and actual components have non-negative identifiers; e.g., a queue with QID 3. So, in our example, even though both users have a queue with queue ID 3, they are mapped to different actual queues with their own unique queue IDs. During packet processing, the user's logical identifiers are mapped to the SPP's actual (or internal) identifiers.
These mappings are carried out by the TCAM (Ternary Content-Addressable Memory) in each NPE. Basically, the TCAM is a database of key-result pairs. It selects an entry whose key matches selected packet information and outputs the corresponding result.
The TCAM in the LC determines the slice context and related internal and external identifiers based on the PlanetLab headers of an incoming packet. These identifiers include:
- FPid: Fastpath ID
- Copt: Code option
- rxMIid: Incoming Meta-Interface ID
- VLANtag: VLAN tag to be used to identify fastpath
[...[ IPv4 TCAM FILTER FIGURE ]...]
The figure (right) shows the format of the NPE's TCAM key and result fields. The key includes the key fields from the user's filters (e.g., destination IP address) and outputs a result that includes primarily forwarding information from the user's filter (e.g., --txdaddr).
XXX
Part II: Configuring the SPP
xxx
Part III: A Virtual Circuit Router
xxx
