ARL Wiki - Recent changes [en]

Running The GPE Forest Demo

2009-11-20T22:00:15Z

User:Ken Wong

2009-11-18T21:41:10Z

←Older revision		Revision as of 21:41, 18 November 2009
Line 21:		Line 21:
	* [[ GENI Deployment Plan ]]		* [[ GENI Deployment Plan ]]
	* [[ The Forest Project ]]		* [[ The Forest Project ]]
-	* [[ Running The ~~GEC 6~~ Forest Demo ]]	+	* [[ Running The GPE Forest Demo ]]
	* [[ The GEC 6 Demos ]]		* [[ The GEC 6 Demos ]]

Special:Log/move

2009-11-18T21:40:34Z

Running The GEC 6 Forest Demo moved to Running The GPE Forest Demo

Running The GEC 6 Forest Demo

2009-11-18T21:40:02Z

←Older revision		Revision as of 21:40, 18 November 2009
Line 2:		Line 2:

	CAVEAT: THIS FILE HAS BEEN LOADED WITH RAW TEXT AND NOT MEANT TO BE READ YET.		CAVEAT: THIS FILE HAS BEEN LOADED WITH RAW TEXT AND NOT MEANT TO BE READ YET.
		+
		+	[[The GEC 6 SPP Demos#The Forest Demo]] gave an abstract description of the Forest Demo.
		+	This page gives the steps required to run the GEC 6 Forest Demo.j
		+
		+	=== Preparation ===
		+
		+	<table align=right border=1 cellpadding=3 cellspacing=0 >
		+	<tr>
		+	<th>File</th>
		+	<th>Purpose</th>
		+	<th>Where To Run</th>
		+	</tr>
		+	<tr>
		+	<td>''demo_GEC4_SPP3_Slice1.sh''</td>
		+	<td>Configure R1</td>
		+	<td>SPP3/Slice1</td>
		+	</tr>
		+	<tr>
		+	<td>''demo_GEC4_SPP2_Slice1.sh''</td>
		+	<td>Configure R2</td>
		+	<td>SPP2/Slice1</td>
		+	</tr>
		+	<tr>
		+	<td>''demo_GEC4_SPP3_Slice2.sh''</td>
		+	<td>Configure R3</td>
		+	<td>SPP3/Slice2</td>
		+	</tr>
		+	<tr>
		+	<td>''start_recvs.sh''</td>
		+	<td>Start three <br> ''iperf'' UDP receivers</td>
		+	<td> Remote host </td>
		+	</tr>
		+	<tr>
		+	<td>''start_xmits_3.sh''</td>
		+	<td>Start three <br> ''iperf'' UDP senders</td>
		+	<td> Remote host </td>
		+	</tr>
		+
		+	<tr>
		+	<td>''changeQparams.sh''</td>
		+	<td>Change threshold and <br> bandwidth parameters</td>
		+	<td> R1 GPE </td>
		+	</tr>
		+	<tr>
		+	<td>''change1Filter.sh''</td>
		+	<td>Change one filter</td>
		+	<td> R1 GPE </td>
		+	</tr>
		+	<tr>
		+	<td>''create_fp''</td>
		+	<td>Allocate FP and handle <br> LD and EX traffic </td>
		+	<td>R1 GPE </td>
		+	</tr>
		+	<tr>
		+	<td>''client''</td>
		+	<td>Create and configure MIs, <br> queues and filters </td>
		+	<td>R1 GPE </td>
		+	</tr>
		+	<tr>
		+	<td>''2_Routers_remote.onl''</td>
		+	<td>RLI jar file</td>
		+	<td>remote client</td>
		+	</tr>
		+	</table>
		+
		+	gec6-forest-main.tar:
		+
		+	* gec6-forest-config.sh
		+	* gec6-forest/
		+
		+	gec6-forest-router.tar:
		+
		+	** ~/WASH/
		+	***
		+	** ~/gpe-forest/
		+	** ~/gpe-forest-config
		+
		+	gec6-forest-host.tar:
		+
		+	** resrv
		+	** client
		+	* ~/forest/
		+	** scripts: =probe, runR, runH, killR, killH,
		+	** files
		+	** wunet5s
		+	* ~/bin
		+	** =probe
		+
		+
		+
		+	You will need the 10 files (shown right) in order to do the Demo.
		+	All but the last three files are Bash shell scripts.
		+	The files ''create_fp'' and ''client'' are executables that are used by the first three scripts.
		+	The last file is the jar file used by the RLI GUI that displays the traffic bandwidths and queue
		+	lengths.
		+
		+	You will also have to do the following before you can run the entire Demo:
		+
		+	* Get an SPP PlanetLab account
		+	* Install version 1.6 of the Java Run-time Environment (JRE)
		+
		+	The JRE is only required if you plan to run the graphical interface for displaying bandwidth and
		+	queue length statistics.
		+
		+	== HERE HERE ==

	The IP addresses <ref>The IP addresses used in a deployment will be different than these addresses		The IP addresses <ref>The IP addresses used in a deployment will be different than these addresses

The GEC6 SPP Demos

2009-11-17T05:24:49Z

The Forest Demo:

←Older revision		Revision as of 05:24, 17 November 2009
Line 2:		Line 2:

	== The Forest Demo ==		== The Forest Demo ==
		+
		+	[[Running The GEC 6 Forest Demo]]

	== The Fast-Path Demo ==		== The Fast-Path Demo ==

User:Ken Wong

2009-11-17T05:23:57Z

←Older revision		Revision as of 05:23, 17 November 2009
Line 22:		Line 22:
	* [[ The Forest Project ]]		* [[ The Forest Project ]]
	* [[ Running The GEC 6 Forest Demo ]]		* [[ Running The GEC 6 Forest Demo ]]
		+	* [[ The GEC 6 Demos ]]

	* [[ The Wunet Protocol ]]		* [[ The Wunet Protocol ]]

The GEC6 SPP Demos

2009-11-17T05:23:25Z

New page: Category:The SPP == The Forest Demo == == The Fast-Path Demo ==

New page

[[Category:The SPP]]

== The Forest Demo ==

== The Fast-Path Demo ==

Running The GEC 6 Forest Demo

2009-11-17T05:22:21Z

New page

[[Category:The SPP]]

CAVEAT: THIS FILE HAS BEEN LOADED WITH RAW TEXT AND NOT MEANT TO BE READ YET.

The IP addresses <ref>The IP addresses used in a deployment will be different than these addresses
and will need to be discovered by a process described later.</ref> of the interfaces are shown in
the figure (right).
Unlike a typical PlanetLab node, an SPP user will need to use more than the node's IP address.
For example, R1's IP address is 10.1.16.1.
But a user needs to know the sockets associated with all of R1's meta-interfaces
as well as a few other sockets such as the slowpath tunnel.
The Demo uses port 20000 with each of the five IP addresses 10.1.1.1, 10.1.2.1, 10.1.3.1,
10.1.16.1 and 10.1.32.1 to form the sockets for the five meta-interfaces of R1's fastpath;
that is, (10.1.1.1, 20000), (10.1.2.1, 20000),
(10.1.3.1, 20000), (10.1.16.1, 20000) and (10.1.32.1, 20000).

<br clear=all>

=== Preparation ===

<table align=right border=1 cellpadding=3 cellspacing=0 >
<tr>
<th>File</th>
<th>Purpose</th>
<th>Where To Run</th>
</tr>
<tr>
<td>''demo_GEC4_SPP3_Slice1.sh''</td>
<td>Configure R1</td>
<td>SPP3/Slice1</td>
</tr>
<tr>
<td>''demo_GEC4_SPP2_Slice1.sh''</td>
<td>Configure R2</td>
<td>SPP2/Slice1</td>
</tr>
<tr>
<td>''demo_GEC4_SPP3_Slice2.sh''</td>
<td>Configure R3</td>
<td>SPP3/Slice2</td>
</tr>
<tr>
<td>''start_recvs.sh''</td>
<td>Start three <br> ''iperf'' UDP receivers</td>
<td> Remote host </td>
</tr>
<tr>
<td>''start_xmits_3.sh''</td>
<td>Start three <br> ''iperf'' UDP senders</td>
<td> Remote host </td>
</tr>

<tr>
<td>''changeQparams.sh''</td>
<td>Change threshold and <br> bandwidth parameters</td>
<td> R1 GPE </td>
</tr>
<tr>
<td>''change1Filter.sh''</td>
<td>Change one filter</td>
<td> R1 GPE </td>
</tr>
<tr>
<td>''create_fp''</td>
<td>Allocate FP and handle <br> LD and EX traffic </td>
<td>R1 GPE </td>
</tr>
<tr>
<td>''client''</td>
<td>Create and configure MIs, <br> queues and filters </td>
<td>R1 GPE </td>
</tr>
<tr>
<td>''2_Routers_remote.onl''</td>
<td>RLI jar file</td>
<td>remote client</td>
</tr>
</table>

You will need the 10 files (shown right) in order to do the Demo.
All but the last three files are Bash shell scripts.
The files ''create_fp'' and ''client'' are executables that are used by the first three scripts.
The last file is the jar file used by the RLI GUI that displays the traffic bandwidths and queue
lengths.

You will also have to do the following before you can run the entire Demo:

* Get an SPP PlanetLab account
* Install version 1.6 of the Java Run-time Environment (JRE)

The JRE is only required if you plan to run the graphical interface for displaying bandwidth and
queue length statistics.

<br clear=all>

=== Part 0: Configuring R1 and R2 ===

Since the same approach is used to configure each of the routers, we only
describe how to configure R1.
Configuration consists of the following three sequence of commands:

<pre>
remote> ssh pl_GEC4_slice_01@spp3.arl.wustl.edu # login to SPP3/Slice1
R1> ./demo_GEC4_SPP3_Slice1.sh # run configuration script
R1> ./runSliced.sh # run slice monitoring daemon
</pre>

We use the terms R1, R2 and R3 synonomously with SPP3/Slice1, SPP2/Slice1 and SPP3/Slice2 respectively.
We configure R2 in the same manner but use the script ''demo_GEC4_SPP2_Slice1.sh''.

The configuration script ''[[ demo_GEC4_SPP3_Slice1.sh ]]'' configures R1 by:

* Adding an endpoint to the line card so that we can use the daemon process ''sliced'' for monitoring
* Creating one fastpath (FP) with a bandwidth of 1.08 Gb/s that can have up to 50 filters, 50 queues and 50 stats indices
* Running a process that handles ''local delivery'' (LD) and ''exception'' (EX) traffic.
* Creating five ''meta-interfaces'' (MIs) within the FP that correspond to the five paths through R1
* Creating and configures 15 packet queues and binds them to MIs
* Installing 26 filters for packet forwarding

These components are created by running two command interpreters: ''create_fp'' and ''client''.
The ''create_fp'' program creates a fastpath and handles LD and EX traffic (e.g., ''ping'' and ''traceroute'').
The ''client'' program is used for all other creation and configuration tasks.

These programs provide the abstractions for configuring an ''IPv4 router'' and use a library
of functions that implement the substrate abstraction provided by an SPP.
[[ Overview Of The SPP Architecture ]] briefly describes the mechanisms and interface provided by
the SPP substrate<ref>The term ''substrate'' as used here should be viewed as being synonomous to
''implementation'' or ''physical layer''. Although the term has its roots in previous work on
diversifying the Internet, you should not interpret it as identical to its usage in that context.</ref>.

== Blah ==

HOW TO RUN 3-ROUTER DEMO

o Current Setup
- R1 = DC
- R2 = SLC
- R3 = KC

o General Info
- $WUNET below is wunet directory (e.g., wunet5, wunet5s) and should be set
and exported into the environment <<<<< NOTE >>>>>
- ~/gec6-[23]R-xterms source to open host xterms for 2R and 3R
- ~/kenw/${WUNET}/topology.source source to set topology shell variables
- ~/kenw/${WUNET}/run run demo leaving stdout and stderr in
r[12]/*log and r[12]/*err
- tar files
bang:kenw-gec6-host.tar extract for PlanetLab host
bang:kenw-gec6-router.tar extract for SPP (maybe old)
bang:kenw-gec6-main.tar extract for host with controlling window
(i.e., where you execute the run
script)
- router files
$loginR[123]:kenw/${WUNET}/3R/r[123]/{lt,rt,vt,st}
~/kenw/demo/ directory for running setup-*.sh and
teardown-*.sh (contains symolic
links to reservation xml files)
~/kenw/scripts/ scripts (e.g., get-info.sh, setup-dc.sh)
get-info.sh get interface attributes
plab-ip.source source to define IP addresses of hosts
plab-uptime.sh find host load averages
setup-proto.sh DEPRECATED
setup-dc.sh symlinked to setup-spp.sh
setup-kc.sh symlinked to setup-spp.sh
setup-slc.sh symlinked to setup-spp.sh
setup-spp.sh setup SPP (make reservation,
sort-uptime.pl sort output of plab-uptime.sh in
increasing longterm load average order
spp-ip.source source to define IP addresses of SPPs
alloc GPE bw, alloc LC bw)
teardown-dc.sh teardown SPP (reverse setup)
wunet-pps.pl DEPRECATED (computes pkts/sec from
old stats file)

~/kenw/files/ files used by scripts (e.g., reservation
xml files)
~/kenw/help/ various help files (usually output of
--help)
- ~/kenw/${WUNET}/3R/ files
run symlinked to run3R
run3R run demo leaving stdout and stderr in
r[123]/*log and r[123]/*err
=status ls -l r*/*err r*/*log
=getstats get r[123]/stats file from R[123]
do-charts.sh [Pollsec] display r[123]stats
ctrl-charts.sh pause/resume charts display
wunet-chart.pl displays chart for 1 router
=EAGAIN extract EAGAIN stats from R[123]/log
clean rm -f r*/*err r*/*log r*/stats
wunet-chart-avg.pl same as wunet-chart.pl but averages over
successive pairs of stats lines
do-charts-avg.sh .
ctrl-charts-avg.sh .
demo.html description of data

�
- ~/kenw/${WUNET}/2R/ files
run run demo leaving stdout and stderr in
r[12]/*log and r[12]/*err
=status ls -l r*/*err r*/*log
=getstats get r[12]/stats file from R1 and R2
do-charts.sh [Pollsec] display r[12]stats
ctrl-charts.sh pause/resume charts display
=EAGAIN extract EAGAIN stats from R[12]/log
clean rm -f r*/*err r*/*log r*/stats

o Old screen shots
- screens/run-[123]/*.png xxxxx

o ### MAIN window (northeast or east corner of screen)

### FIND HOSTS WITH LOWEST LONGTERM LOAD AVERAGES
cd ~/kenw/demo
plab-uptime.sh > uptime.txt # get uptime of potential hosts
# (may need to delete some hosts
# to get to run to completion)
sort-uptime.sh < uptime.txt > uptime-sorted.txt
# sort in non-decreasing longterm
# load average order
### UPDATE TOPOLOGY FILE
... check choice of hosts in ~/kenw/${WUNET}/2R/topology.source ...
... modify topology file if necessary ...
### PREPARE TO RUN
cd ~/kenw/${WUNET}/3R
source ../topology.source # not necessary except for convenience

o ### ROUTER WINDOWS
- Prepare routers
- DC window (southeast corner of screen)
+ open window titled DC
+ ssh to router DC: or "ssh -v $loginR1"
+ setup router
cd kenw/demo
get-info.sh # show interface attributes
setup-dc.sh | tee setup-dc.out | more # setup SPP
- SLC window (west side of screen)
+ open window titled SLC
+ ssh to router SLC: or "ssh -v $loginR2"
+ setup router
cd kenw/demo
get-info.sh
setup-slc.sh | tee setup-slc.out | more
- KC window (southwest corner of screen)
+ open window titled KC
+ ssh to router KC: or "ssh -v $loginR3"
+ setup router
cd kenw/demo
get-info.sh
setup-kc.sh | tee setup-kc.out | more

o ### HOST WINDOWS H[123][123]
- Open host windows H[123][123] (9 small windows titled H11, H12, ...)
- OPTIONAL ... just shows something is happening on hosts
- new window
source ~/gec6-3R-xterms

9 windows appear tiled in 3 columns near northwest corner of screen

o Run ~/bin/=probe on each of the routers and hosts
- the script greps the output of "ps clax" for wuRouter and wuRscript for
routers and wuHost and wuHscript for hosts
- two successive lines of "- -" indicates that none of the processes of
interest are running

�
o ### MAIN WINDOW
- Start the run

### CLEAN UP OLD ERROR, LOG AND STATS FILES
script # >>> optional
clean # rm err, log and stats files from r*
### START RUN
run # run for about 2 minutes
... look at other windows to see =probe output ...
### WAIT FOR COMPLETION
=status # show error and log files
... wait for end of run ...
=status # show error and log files
### GET STATS FILES FROM GPES
=getstats # get r[123]/stats
ls -l r*/stats
### CHART STATS
do-charts.sh # show charts of stats
ctrl-charts.sh # any key entry toggles between pause
# and resume
### LOOK AT EAGAIN ERRORS
=EAGAIN # look at EAGAIN stats
###
exit # >>> only if ran script command

- should see wuRscripts, wuRouter, wuHscripts and wuHost running

o Save run stats (e.g.)

mkdir stats.d/run-X-stats
tar cf kenw.tar r[12]
cd stats.d/run-X-stats
tar xf ../kenw.tar

o Clean up the routers
- run the teardown-*.sh script in the kenw/demo/ directory; e.g.,

SLC> cd kenw/demo
SLC> teardown-slc.sh | tee teardown-slc.out | more

�
o Setting up a PlanetLab host
- copy tar file to host and extract

ssh YOUR_HOST
rm -f wunetRuns
scp kenw@bang.arl.wustl.edu:kenw-gec6-host.tar . # get tar file
cp .bashrc dot-bashrc.ORIG # save .bashrc (optional)
tar xf kenw-gec6-host.tar # extract
=probe # test that you can run ./bin/=probe

o Setting up a GPE (same as for host but use different tar file)

ssh YOUR_GPE
rm -f wunetRuns
scp kenw@bang.arl.wustl.edu:kenw-gec6-router.tar . # get tar file
cp .bashrc dot-bashrc.ORIG # save .bashrc (optional)
tar xf kenw-gec6-router.tar # extract
=probe # test that you can run ./bin/=probe
cd kenw/demo # .
get-info.sh # . get interface attributes

o Setting up MAIN host (same as for host but use different tar file)

ssh YOUR_RUN_HOST
rm -f wunetRuns
scp kenw@bang.arl.wustl.edu:kenw-gec6-main.tar . # get tar file
tar xf kenw-gec6-main.tar # extract
export WUNET=wunet5s # or whatever
ls -l wunetRuns # does symlink point to right place ???
# should point to kenw/${WUNET}
ls wunetRuns # .
cd wunetRuns/3R # .
ls # .

The Forest Project

2009-11-17T05:13:55Z

←Older revision		Revision as of 05:13, 17 November 2009
Line 1:		Line 1:
-	~~THE FOREST PROJECT~~	+	[[Category:The SPP]]

	== Introduction To The Forest Project ==		== Introduction To The Forest Project ==

User:Ken Wong

2009-11-17T05:13:03Z

←Older revision		Revision as of 05:13, 17 November 2009
Line 20:		Line 20:
	* [[ SPP Control Software ]]		* [[ SPP Control Software ]]
	* [[ GENI Deployment Plan ]]		* [[ GENI Deployment Plan ]]
		+	* [[ The Forest Project ]]
		+	* [[ Running The GEC 6 Forest Demo ]]
		+
		+	* [[ The Wunet Protocol ]]
		+	* [[ Inside The wunet Source Code ]]
		+	* [[ The Forest Protocol ]]
		+	* [[ Development Of The Forest Protocol ]]
		+	* [[ The GEC 6 Forest Demo ]]
		+	* [[ Design Of The Forest Fastpath ]]
		+	* [[ The GEC 6 Fastpath Demo ]]

	Bullet list:		Bullet list:

The Forest Project

2009-11-17T05:07:46Z

Wiki Pages:

←Older revision		Revision as of 05:07, 17 November 2009
(4 intermediate revisions not shown.)
Line 6:		Line 6:
	process for a new protocol targeted for the SPP (Superchared Planetlab		process for a new protocol targeted for the SPP (Superchared Planetlab
	Platform).		Platform).
-	A typical Planetlab user wishing to develop a Fast-Path (FP) implementation of	+	As noted in the page [[Internet Scale Overlay Hosting]],
-	a new protocol will typically follow these steps:	+	a typical Planetlab user wishing to develop a Fast-Path (FP) implementation of
		+	a new protocol will typically follow these broad steps:

-	~~<< INSERT >>~~	+	# Develop a slow-path version by writing a stylized socket program that captures the semantics of the protocol processing and debug it using almost any host.
		+	# Repeat the testing of the slow-path version of the router software on the SPPs' GPEs.
		+	# Send to the SPP developers information regarding the slow-path program that handles your new protocol (e.g., slow-path code, test results, informal/formal protocol description).
		+	# The SPP developers will transform the slow-path socket program into a slow-path part that will run on a GPE and a fast-path part that will run on an NPR.
		+
		+	In Step 4, the slow-path part typically handles the control path and exception processing; and the fast-path part handles the data path.
		+	Note that Step 1 can even be done using a single host if only attempting to eliminate gross functional bugs.
		+	As discussed in [[ Development of the Forest Protocol ]],
		+	variations of the above steps can be profitably used.

	== History ==		== History ==
Line 28:		Line 37:
	* Forest Pages		* Forest Pages
	** [[ The Forest Protocol ]]		** [[ The Forest Protocol ]]
		+	** [[ Development Of The Forest Protocol ]]
	** The GEC 6 Demo		** The GEC 6 Demo
	*** [[ The GEC 6 Forest Demo ]]		*** [[ The GEC 6 Forest Demo ]]
-	*** [[ ~~How To Run~~ The GEC 6 Forest Demo ]]	+	*** [[ Running The GEC 6 Forest Demo ]]
	** [[ Design Of The Forest Fastpath ]]		** [[ Design Of The Forest Fastpath ]]
	* Related Pages		* Related Pages
	** [[ The GEC 6 Fastpath Demo ]]		** [[ The GEC 6 Fastpath Demo ]]

Internet Scale Overlay Hosting

2009-11-16T17:24:39Z

←Older revision		Revision as of 17:24, 16 November 2009
Line 363:		Line 363:
	Programming GPEs (General-purpose Processing Engines) is similar to programming any general-purpose processor with multiple network interfaces.		Programming GPEs (General-purpose Processing Engines) is similar to programming any general-purpose processor with multiple network interfaces.
	We are currently working through an example of this process using an early version of the Forest Protocol.		We are currently working through an example of this process using an early version of the Forest Protocol.
-	This effort is described in [[The Forest ~~Protocol Development For SPPs~~]].	+	This effort is described in [[The Forest Project]].

	Using a GPE is similar to using any PlanetLab node except that SPP slices are administered through a special PLC (PlanetLab Central) site at http://drn06.arl.wustl.edu/.		Using a GPE is similar to using any PlanetLab node except that SPP slices are administered through a special PLC (PlanetLab Central) site at http://drn06.arl.wustl.edu/.

The Forest Project

2009-11-16T17:23:16Z

New page: THE FOREST PROJECT == Introduction To The Forest Project == The ''Forest Project'' is an effort to demonstrate the complete development process for a new protocol targeted for the SPP (S...

New page

THE FOREST PROJECT

== Introduction To The Forest Project ==

The ''Forest Project'' is an effort to demonstrate the complete development
process for a new protocol targeted for the SPP (Superchared Planetlab
Platform).
A typical Planetlab user wishing to develop a Fast-Path (FP) implementation of
a new protocol will typically follow these steps:

<< INSERT >>

== History ==

A slow-path Forest implementation was first demonstrated at the GEC 6
Conference.

== The Wunet Protocol ==

== The Forest Protocol ==

== Wiki Pages ==

* The SPP Architecture
* The wunet Protocol
** [[ The Wunet Protocol ]]
** [[ Inside The wunet Source Code ]]
* Forest Pages
** [[ The Forest Protocol ]]
** The GEC 6 Demo
*** [[ The GEC 6 Forest Demo ]]
*** [[ How To Run The GEC 6 Forest Demo ]]
** [[ Design Of The Forest Fastpath ]]
* Related Pages
** [[ The GEC 6 Fastpath Demo ]]

Internet Scale Overlay Hosting

2009-11-16T17:21:11Z

←Older revision		Revision as of 17:21, 16 November 2009
Line 351:		Line 351:

	We anticipate that a typical SPP user will develop their router software in		We anticipate that a typical SPP user will develop their router software in
-	~~three~~ steps:	+	four steps:

-	* Develop a slow-path version by writing a stylized socket program that captures the semantics of the protocol processing and ~~debugging~~ it ~~running~~ on the SPPs' GPEs.	+	* Develop a slow-path version by writing a stylized socket program that captures the semantics of the protocol processing and debug it using any PlanetLab-like host.
		+	* Repeat the testing of the slow-path version of the router software on the SPPs' GPEs.
	* Send to the SPP developers information regarding the slow-path program that handles your new protocol (e.g., slow-path code, test results, informal/formal protocol description).		* Send to the SPP developers information regarding the slow-path program that handles your new protocol (e.g., slow-path code, test results, informal/formal protocol description).
	* The SPP developers will transform the slow-path socket program into a slow-path part that will run on a GPE and a fast-path part that will run on an NPE.		* The SPP developers will transform the slow-path socket program into a slow-path part that will run on a GPE and a fast-path part that will run on an NPE.
		+	** The slow-path part typically handles the control path and exception processing.
		+	** The fast-path part handles the data path.

	This approach is needed because programming NPEs (used for the fast-path) is specific to the IXP network processors.		This approach is needed because programming NPEs (used for the fast-path) is specific to the IXP network processors.
-	~~But programming~~ GPEs (General-purpose Processing Engines) is similar to programming any general-purpose processor with multiple network interfaces.	+	Programming GPEs (General-purpose Processing Engines) is similar to programming any general-purpose processor with multiple network interfaces.
	We are currently working through an example of this process using an early version of the Forest Protocol.		We are currently working through an example of this process using an early version of the Forest Protocol.
-	This effort is described in [[Forest Protocol Development For SPPs]].	+	This effort is described in [[The Forest Protocol Development For SPPs]].

	Using a GPE is similar to using any PlanetLab node except that SPP slices are administered through a special PLC (PlanetLab Central) site at http://drn06.arl.wustl.edu/.		Using a GPE is similar to using any PlanetLab node except that SPP slices are administered through a special PLC (PlanetLab Central) site at http://drn06.arl.wustl.edu/.