Difference between revisions of "Overview Of The SPP Architecture"
m |
|||
| Line 14: | Line 14: | ||
* Traffic isolation | * Traffic isolation | ||
* High performance | * High performance | ||
| + | * Protocol extensibility | ||
| − | + | These features allow the SPP to support the concurrent operation of multiple high-speed, | |
| − | virtual routers. | + | 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. | We begin with a very simple example of an IPv4 router to illustrate the SPP concepts. | ||
| Line 27: | Line 31: | ||
virtual circuit protocol instead of IPv4. | virtual circuit protocol instead of IPv4. | ||
| − | == Example == | + | == IPv4 Example == |
[[ Image:example-two-slices-one-spp.png | thumb | right | 400px | Two Slices Sharing One SPP ]] | [[ Image:example-two-slices-one-spp.png | thumb | right | 400px | Two Slices Sharing One SPP ]] | ||
| − | We begin with a simple example of two users concurrently using the same SPP | + | We begin with a simple example of two users (A and B) concurrently using the same SPP |
| − | as an IPv4 | + | as an IPv4 transit router (R3) between the same two routers (R1 and R2) that are attached to ports |
1 and 2 of the SPP (see figure to the right). | 1 and 2 of the SPP (see figure to the right). | ||
Furthermore, both users need 100 Mb/s bandwidth in each direction | Furthermore, both users need 100 Mb/s bandwidth in each direction | ||
| Line 41: | Line 45: | ||
[[ Image:example-two-slices-one-spp-logical.png | thumb | right | 400px | Logical Configuration of Each Slice ]] | [[ Image:example-two-slices-one-spp-logical.png | thumb | right | 400px | Logical Configuration of Each Slice ]] | ||
| − | From a logical point of view, each user needs | + | From a logical point of view, each user of R3 needs a configuration (right) which includes |
one fastpath consisting of three meta-interfaces (m0-m2), four queues (q0-q3), | one fastpath consisting of three meta-interfaces (m0-m2), four queues (q0-q3), | ||
and six filters (f0-f5). | and six filters (f0-f5). | ||
| − | Meta-interface m0 goes to | + | Meta-interface m0 goes to R3 itself; m1 to R1; and m2 to R2. |
| − | The | + | The configuration of R3 for both users is identical except for UDP port numbers of |
| − | in the | + | their meta-interfaces. |
| − | Note the following | + | Both user A and B will have the logical views shown in the tables (right). |
| + | Note the following: | ||
| − | * The total bandwidth of the meta-interfaces can not exceed the bandwidth of the fastpath. | + | * 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. | + | * 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 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 UDP port number of the MI sockets are 22000 for user A and 33000 for user B. | ||
{| border=1 cellspacing=0 cellpadding=3 align=right | {| border=1 cellspacing=0 cellpadding=3 align=right | ||
| − | ! | + | ! User A || MI Socket || BW <br> (Mb/s) || Queues |
|- | |- | ||
| − | | FP || 202 || <br> | + | | FP || na || 202 || <br> |
|- | |- | ||
| − | | m0 || 2 | + | | m0 || (10.1.16.3, ''22000'') || 2 || q2, q3 |
|- | |- | ||
| − | | m1 || 100 || q0 | + | | m1 || (10.1.32.2, ''22000'') || 100 || q0 |
|- | |- | ||
| − | | m2 || 100 || q1 | + | | m2 || (10.1.17.1, ''22000'') || 100 || q1 |
| + | |} | ||
| + | |||
| + | {| border=1 cellspacing=0 cellpadding=3 align=right | ||
| + | ! User B || MI Socket || BW <br> (Mb/s) || Queues | ||
| + | |- | ||
| + | | FP || na || 202 || <br> | ||
| + | |- | ||
| + | | m0 || (10.1.16.3, ''33000'') || 2 || q2, q3 | ||
| + | |- | ||
| + | | m1 || (10.1.32.2, ''33000'') || 100 || q0 | ||
| + | |- | ||
| + | | m2 || (10.1.17.1, ''33000'') || 100 || q1 | ||
|} | |} | ||
| Line 90: | Line 108: | ||
<br clear=all> | <br clear=all> | ||
| − | == Part I: Packet Forwarding == | + | == Part I: IPv4 Packet Forwarding == |
xxx | xxx | ||
Revision as of 15:18, 12 June 2009
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 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 describe the architectural features in three parts. 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 users (A and B) concurrently using the same SPP as an IPv4 transit router (R3) between the same two routers (R1 and R2) that are attached to ports 1 and 2 of the SPP (see figure to the right). Furthermore, both users need 100 Mb/s bandwidth in each direction (R1 to R2 and R2 to R1) and no special treatment of traffic.
From a logical point of view, each user of R3 needs a configuration (right) which includes one fastpath consisting of three meta-interfaces (m0-m2), four queues (q0-q3), and six filters (f0-f5). Meta-interface m0 goes to R3 itself; m1 to R1; and m2 to R2.
The configuration of R3 for both users is identical except for UDP port numbers of their meta-interfaces. Both user 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 UDP port number of the MI sockets are 22000 for user A and 33000 for user B.
| User A | MI Socket | BW (Mb/s) |
Queues |
|---|---|---|---|
| FP | na | 202 | |
| m0 | (10.1.16.3, 22000) | 2 | q2, q3 |
| m1 | (10.1.32.2, 22000) | 100 | q0 |
| m2 | (10.1.17.1, 22000) | 100 | q1 |
| User B | MI Socket | BW (Mb/s) |
Queues |
|---|---|---|---|
| FP | na | 202 | |
| m0 | (10.1.16.3, 33000) | 2 | q2, q3 |
| m1 | (10.1.32.2, 33000) | 100 | q0 |
| m2 | (10.1.17.1, 33000) | 100 | q1 |
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.
| MIout | |||
|---|---|---|---|
| MIin | m0 | m1 | m2 |
| m0 | f0 | f1 | |
| m1 | f2 | f3 | |
| m2 | f4 | f5 | |
xxxxx
Part I: IPv4 Packet Forwarding
xxx
Part II: Configuring the SPP
xxx
Part III: A Virtual Circuit Router
xxx
