To be evaluated, a PLAN program is bundled into a packet, injected into the
active network, and then evaluated. As a result of evaluation, the packet
may create other packets which may then be evaluated at other nodes in the
network.
3.1 Terminology
A PLAN chunk consists of three components: the code, the
fn_to_exec, and the bindings; the latter two are referred
to collectively as the invocation. The code consists of a
series of definitions which bind names to abstractions; these abstractions
may be functions, values, or exceptions. The invocation
consists of the function call (i.e., function name fn_to_exec
and actual parameters a1,...,an -- the bindings) to be
evaluated at the next evaluation point, where the set of all definitions in
the code part (as well as the predefined service functions) serve as the
legal environment for the call. Note that the bindings
must be values since PLAN supports a call-by-value semantics.
A chunk is both conceptual and concrete: PLAN values of type
'a chunk are first-class chunks.
A PLAN interface identifies a link to a physical network.
Interfaces are represented by values of the PLAN type dev. Each
interface has both a network and a link layer address (the form of the
former is universal while the latter is physical network-specific). Since a
PLAN node might have links to several physical networks (a router, for
example, in the current Internet, has several interfaces each of which may
have a different IP and Ethernet address), a single node might be associated
with several PLAN interfaces.
A PLAN packet carries a PLAN chunk to be executed on an active node.
In addition to the chunk, the packet also contains some additional fields:
the evaluation destination, the resource bound (explained
later), and the routing function (among others). The evaluation
destination (or evalDest) names the next active node which should
evaluate the chunk. The routing function serves to define how the packet
will be transported from the current node to the evalDest. The resource
bound (or RB), indicates the sum total of the number of hops this
packet or any of its progeny may make. This serves to limit the network
resource usage of any PLAN application.
Finally, a PLAN application consists of a series of PLAN packets that
comprise a task. This is different than a host application, which is
a program that runs on a end-node in the network, and may be written in some
language other than PLAN. In the simplest case, a PLAN application is
defined by the injected packet and all of its resulting progeny. More
often, PLAN applications may cooperate with host applications to complete a
task.
Figure 1: PLAN network: the PLAN evaluation
environment
3.2 Model of Evaluation
To understand how PLAN programs evaluate, it is imperative to understand
their evaluation environment, the PLAN network, depicted in
Figure 1. A PLAN network consists of hosts, which form the
end-points of the environment, and routers, which form the cloud.
Collectively, hosts and routers are referred to as nodes. Hosts are
essentially distinguished from routers in that they may serve host
applications which form part of a PLAN application. All nodes must be
capable of evaluating PLAN programs.
A PLAN packet begins its life at a host, specifically within a host
application. The application constructs a PLAN packet and injects it
into the active network by handing it to the PLAN interpreter on its host.
This is done by creating a PLAN port between the application and the
interpreter, called the injection PLAN port (or implicit PLAN port). This
PLAN port allows the interpreter to provide output to the application, and allows
the application to submit new PLAN packets.
The local interpreter then proceeds to route the packet to its evalDest,
making use of the provided routFun to determine the next hop. At each hop
on the way to the evalDest, resource bound is subtracted from the packet; if
at any time the resource bound is exhausted, the packet is terminated and a
message is sent back to the source for potential recovery. When a PLAN
packet reaches its evalDest, its program is evaluated. First, the code is
parsed top-down to register the top-level bindings. All function bindings
respect static scoping; that is, the set of bindings available to a
function when it is evaluated are those that were available when it was
defined. Evaluation then begins with the function call f(a1,...,an)
defined by the invocation. Any value that would have been returned by the
function is discarded.
Any exceptions (see Section 4) which are not explicitly handled by
the PLAN program will be processed by the packet's designated handler;
see Section 4.2.
