Download florissi_ASN10-99 - Electrical and Computer Engineering, ECE

The Network Flow Language
(NFL)
for Active Sensor Networks (ASNs)
Danilo Florissi, Yechiam Yemini (YY),
Sushil da Silva, Hao Huang
Columbia University, New York, NY 10027
http://www.cs.columbia.edu/dcc/asn
{df,yy,dasilva,hhuang}@cs.columbia.edu
Toward Programmable Adaptive SNs
Key ideas
 Active
Networks (ANets) enable programming of network
transport and processing functions
 SNs need to adapt flexibly to limited resources, changing
external conditions, and different foci of user interest
Goal: facilitate programmable adaptive SNs through ANet
ASN
SN
Scenario
Active Networks
ANet render networks programmable
 Deploy
code dynamically to create new node functionality
 Approaches: code delegation or packet capsules
The NetScript Language
Dataflow model:
 Active
element = packet stream processor engine
Active elements are composed from boxes (computational
channels)
 Boxes encapsulate computations
 Composition through interconnection
 Synchronization of streams motions
 Allocation of underlying resources
 Simple model of inter-operability
NetScript Dataflow Model
Example: IP stack
 Dynamic
deployment of new stack components
 On-the-fly change/upgrade of functionality
IPX
Eth
Eth Demux
UDP
IP
AppleTalk
TCP
Marks in Web Documents
HTML: embedded marks define operations on object
XML: support programming of marks
Syntax and semantics of marks are programmable
 DTD
files define syntax
 XSL files define semantics
Marks meaning can vary in time and among processors
 XSL files can be dynamically loaded and changed
NFL: Language for Marked Flows
Marked language to program processing of network flows
NFL programs flows ~ XML programs Web documents/objects
Marks replace protocol headers and can program:
 Routing,
flow control, admission control, resource
reservation, content filtering, caching, etc.
Marks can extend or replace protocol stacks
NFL Main Components
Mark syntax
 FTD:
Flow Tag Definition ~ DTD
Mark semantics
 XFL: eXtensible Flow Language ~ XSL
 NetScript: natural candidate for semantics of NFL marks
NFL is an execution environment for programming active
sensor applications
NFL flow
NetScript
boxes and links
Node
Mark processing by NFL
Known marks are routed to processing boxes
Unknown marks spawn processing boxes from NFL servers
Server
NFL flow
NetScript
boxes and links
Node
What Can You Do With Marks?
Create your own protocols
 Marks
replace protocol headers
 Marks are naturally stacked through nesting
Combine networking and computing functions
 E.g., contents-based routing
 E.g., contents-based error/QoS control
Program a SN dynamically
Recent Work
Design of NFL
 Overall
runtime architecture
 Language syntax and semantics
 Integration with NetScript
Start design and implementation of sample application
 Efficient HTTP protocol (UXTP)
On-demand control
Target is very fast web access
 Looking
at other systems proposed by SenseIT researchers
Implement components in NFL
Drive the design and implementation of the language
Near Future Challenges
Porting NetScript to WINS
 NetScript
currently works on Java VM
Heavy use of resources
Java VM for Windows CE
 Port
dynamic deployment of boxes
Box servers come and go
Single hop or multiple-hop
Optimize use of limited resources
 Minimize
memory demand on sensors
 Minimize overhead of NFL runtime
NFL implementation of interesting SenseIT applications
Examples of NFL
Applications
Example: Prioritization of Samples
Problem: samples have different levels of priorities and the
network has to prioritize delivery of flows
Data flows In
7
1
0
5
10
0
Priority
Sorter
Priority
Queue
Node
7
5
1
NetScript
boxes and links
Data flow Out
10
0
0
Code: Priority in NFL
Samples are marked with name and priority levels
Sensor Server:
<samples URI=”http://www.cs.columbia.edu/multicast1270”>
<data priority=5>
12, 15, 14, 17
</data>
<data priority=10>
7, 75, 882, 1
</data>
<data>
6, 10, 8, 8, 9
</data>
</samples>
Example: Route Discovery for WINS
Problem: WINS sensors deployed in battlefield need to
discover efficient routing to minimize power consumption
Code: Route Discovery for WINS
Sensors broadcast their known distance to peer sensors
Small physical distance ~ less power consumption
Sensor Server:
<announce-name URI=”http://www.sensor16.cs.columbia.edu”>
</announce-name>
Sensor Client:
<announce-routes>
<route-entry>
URI=”http://www.sensor25.cs.columbia.edu” 16 sensor17
</route-entry>
<route-entry>
URI=”http://www.sensor5.cs.columbia.edu” 2 sensor9
</route-entry>
</announce-routes>
Example: Simple Diffusion Routing (I)
Problem: WINS should route data contents, not individual
packets
B
A
B
B
Flow A
Flow
Sorter
Flow B
A
A
A
A
A
Example: Simple Diffusion Routing (II)
Problem: handling failures to links and nodes
New NetScript boxes are loaded to handle enhanced functions
B
A
A
A
A
B
B
Flow
Sorter
Flow A
Diffusion
Criteria
Flow B
A
A
A
A
Code: Simple Diffusion Routing
Sensor Client:
<event-subscribe id=”102” event-label=”image”
URI=”http://www.sensor1076.cs.columbia.edu”
URI=”http://www.cs.columbia.edu/multicast1270”>
</event-subscribe>
Sensor Server:
<samples URI=”http://www.cs.columbia.edu/multicast1270”>
<data> 12, 15, 14, 17 </data>
<image> <!–- image contents> </image>
<data> 6, 10, 8, 8, 9 </data> </samples>
Manager:
<event-notification id=”765” event=”link-down”
URI=”http://www.cs.columbia.edu/multicast1270”>
URI=”http://www.sensor1053.cs.columbia.edu/link7”
</event-notification>
Example: Trading Processor/Bandwidth
Problem: flows should compress or expand to minimize use of
stressed resources in each sensor
Sensor Server:
<flow URI=”http://www.display7.cs.columbia.edu”>
<conditional-compress condition=”bandwidth < 1Mbps”>
<image>
<!-- image data>
</image>
</conditional-compress>
</flow>
Controlling SN With Marks
Marks can be used to configure and control
 Sensor
functions
 End-end QoS delivery by the network and sensors
 Routing strategy to maximize QoS, minimize power, etc.
 Caching of previous samples (for calculation of statistics)
SN Event Processing with Marks
Marks can be used to present event data & control processing
 Specify
the type of data (seismic, streaming audio, etc.)
 The processing of marks at sensors the flow crosses may
depend on local conditions (available processor, link
bandwidth, etc.)
Conclusions, Plans, and Schedule
ANet can bring flexibility and simplicity for SN programming
NFL marked flow processing paradigm can specify and
enhance SN functionality
Plans and Tentative Schedule
 7/1999: New contract started
 8/1999: New SOW
 10/1999: Work on design and implementation of NFL
 1/2000: Projected first prototype of basic NFL
 3/2000: Port to SenseIT devices
 6/2000: Implement relevant SenseIT application(s)
 Interact with SenseIT community to identify key needs
 Use SenseIT applications to drive design