Half a croissant, on a plate, with a sign in front of it saying '50c'
h a l f b a k e r y
If you need to ask, you can't afford it.

idea: add, search, annotate, link, view, overview, recent, by name, random

meta: news, help, about, links, report a problem

account: browse anonymously, or get an account and write.

user:
pass:
register,


                             

Active Networking

Packets that think.
  (+2)
(+2)
  [vote for,
against]

I'm using the term "Active Networking" to describe some of my thoughts on the process of taking general network traffic out of the realm of simply being something that's being shipped between endpoints and into the realm of being something that is directed between endpoints, but to some extent, ships itself. Similar in a lot of ways to mobile code, only more generic.

My basic premise behind Active Networking is that large networks tend to get unwieldy very quickly past a certain point. Modifications to the network in near real-time by network administrators to keep things optimal places a lot of strain on certain nodes of the network (historically switches and routers, albeit that these devices are getting smarter all the time, and better protocols are always being developed and deployed). Some of this overhead might be mitigated if the packets had something to say about their routing.

Currently, it's the job of network equipment to take packets and shuttle them down the best path each device knows about with regards to gettting them to their destination. In an Active Network world, network equipment serves as a highly optimized cartographer of it's relevant network scope (for an internal network router, only the internal network and any gateways it's configured to know about and/or use, for instance) and feeds digests of the relevant information to packets. The packets act as both parcels for data and as dynamic routing tables -- there's internal logic to each packet that when updated with new network information, chooses it's next destination and proceeds on it's way. What this improves on is that routers are more flexible and are asked to do less overall. They're still physical pathways to parts of the network, just like bridges, hubs, and switches, but they simply maintain fresh state of the network map and provide computational resources to the packet to decide it's path. The granularity of control over traffic is on each packet, not a rule which arbitrary packets might match. Furthermore, packets may be given roles within the realm of the Active Network, such as discovery packets from other network devices, which carry payloads of network state update data and service request calls.

Some interesting applications of Active Networking: mix networks. Mix networks today (like Zero Knowledge Systems' _Freedom_, AT&T's _Crowds_ and NRL's _Onion Routing_) rely on servers or peer-to-peer type apps to relay traffic around. In an Active Network world, you could potentially enable packets created by a certain application to purposely take obfuscated paths and do internal addressing rewrites. NAT potentially becomes less of an issue: packets with a certain identifier (probably a cryptographic hash) can be granted information about a NAT setup within a network and traverse within it and outside of it, whereas packets without the proper credential are dealt with accordingly. And there's lots more potential uses...

There are loads of potential problems with Active Networking too. First and foremost is that the way networking is done today is pretty effcient, all things considered. Giving packets decision making capabilities and internal logic opens up a whole new slew of security concerns. Actual implimentation of Active Networks would initially have to be done on top of the current network infrastructure or done from scratch with customized hardware and software. And management issues become harder since you can't dictate implicitly where packets go. And, given the current state of affairs, for Active Network to ever become something used Internet wide (which is where I think it would excel best), it would most likely have to be implimented by either Cisco, or _all_ of Cisco's competitors (therefore forcing Cisco to do it).

There's also a lot of more fundamental mathematical questions around Active Networking, but I can't help but be interested.

dnm, Feb 15 2001

Subject-based addressing, publish/subscribe, etc. http://www.tibco.co...ducts/rv/index.html
Subject-based addressing and publish/subscribe implemented on top of TCP/IP solves many of your issues. Hey, guess who I work for! [hippo, Feb 15 2001, last modified Oct 04 2004]

Cisco routers http://www.tibco.co...eases/press167.html
And while you're at it, why not embed this software in the routers? [hippo, Feb 15 2001, last modified Oct 04 2004]

Real-time distribution http://user.tninet....stribution_2-08.htm
[hippo, Feb 15 2001, last modified Oct 04 2004]

Some more on Subject-based addressing http://www.cpu.com/...ries/strategies.htm
...and the alternatives to boring timer or poll-based point-to-point traffic [hippo, Feb 15 2001, last modified Oct 04 2004]

Active Networks at DARPA http://www.darpa.mi...ActiveNetsList.html
An overview of several dozen ongoing research projects on active networks (funded by DARPA). [egnor, Feb 15 2001, last modified Oct 04 2004]

SwitchWare at UPenn http://www.cis.upenn.edu/~switchware/
Includes some good "Related Sites" links. [egnor, Feb 15 2001, last modified Oct 04 2004]

Active Networks at MIT http://www.sds.lcs.mit.edu/activeware/
Likewise. [egnor, Feb 15 2001, last modified Oct 04 2004]

[link]






       hippo: Thanks for those links, I looked at both. Where can I get more technical whitepapers on subject-based addressing and publish/subscribe?
dnm, Feb 15 2001
  

       More links added, biased towards products such as TIB/Rendezvous from TIBCO. Now Hiring.
hippo, Feb 15 2001
  

       Hello? Baked!! They even call it the same thing (well, it's usually termed "Active Networks", not "Active Networking"). It's not widely deployed, but it's definitely a subject of very widespread research. A few simple searches should turn this up.   

       I've added some links; they cover this subject in far more depth than any of us can hope to. (Trying to stem the tide of uninformed speculation that's likely to follow...)
egnor, Feb 15 2001
  

       What's wrong with uninformed speculation? This _is_ Halfbakery.
dnm, Jul 29 2001
  

       Hmm. It seems inefficient to put to much code in the packets themselves, but promising to put more intelligence in how routers handle them. After all, a packet is like a virus; it uses the host's machinery to do almost all of its work.   

       The danger with high-complexity systems is that they become less understandable and thus potentially less stable. This is not to say that a good design cannot produce a more efficient network infrastructure by being more complex.
beland, Mar 07 2003
  

       I see a very great potential bonus: Streaming.   

       Currently streaming the same live feed to 2 people on the same network just means twice as many packets, inevitably creating inefficiencies and packet bloat. An active network could presumably understand that this packet needs to be divided when these two network routes diverge, but not before. Et voila, vastly reduced overhead for streaming. This is all the more potent when streaming over broadband, where most people are on one of only a few services - here in the uk, streaming one stream to ntl, one to BT, one to Telewest would mean 3 streams which divide after they've reached the telco's internal network.   

       On second thoughts, why isn't this being done via normal methods already?
imagin8or, Jun 26 2003
  

       [imagin8or] Actually there already is a technology in place that solves the particular problem you describe, it is called "multicasting". The streamed packets are only sent once, and "fan out" as needed to find all the subscribers.
krelnik, Jun 26 2003
  
      
[annotate]
  


 

back: main index

business  computer  culture  fashion  food  halfbakery  home  other  product  public  science  sport  vehicle