the network flow language (nfl) for active sensor networks (asns)
DESCRIPTION
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. ASN. - PowerPoint PPT PresentationTRANSCRIPT
The Network Flow Language The Network Flow Language (NFL)(NFL)
for Active Sensor Networks (ASNs)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
Scenario
Use
r N
eed
s
Resource Availability
SN
ASN
+ A
Active Networks ANet render networks programmable
Deploy code dynamically to create new node functionality Approaches: code delegation or packet capsules
Virtual Active Net (VAN)
Physical Medium
Active Element
OS Environment
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
The NetScript Language
NetScript Dataflow Model
Example: IP stack Dynamic deployment of new stack components On-the-fly change/upgrade of functionality
Eth DemuxEth
IPX
AppleTalk
IP
UDP
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 NetScriptboxes and links
Node
Mark processing by NFL Known marks are routed to processing boxes Unknown marks spawn processing boxes from NFL servers
NFL flow NetScriptboxes and links
Node
Server
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 controlTarget is very fast web access
Looking at other systems proposed by SenseIT researchersImplement components in NFLDrive the design and implementation of the language
Near Future Challenges Porting NetScript to WINS
NetScript currently works on Java VMHeavy use of resources Java VM for Windows CE
Port dynamic deployment of boxesBox servers come and goSingle 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 Examples of NFL ApplicationsApplications
Example: Prioritization of Samples Problem: samples have different levels of priorities and the
network has to prioritize delivery of flows
5 10 0
PriorityQueue
5 1 10 07
Data flows In
NetScriptboxes and links
NodeData flow Out
7 1 0
0
PrioritySorter
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
Flow A
FlowSorter
B A B B
Flow B
AA A A A
Example: Simple Diffusion Routing (II) Problem: handling failures to links and nodes New NetScript boxes are loaded to handle enhanced functions
Flow AFlowSorter
B A B B
Flow B
AA A A A
DiffusionCriteria
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 sensorSensor 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