[e2e] common interface: path or node?

[Joe Touch]

Micah Beck wrote:
...
> The Internet community has defined an interface, the network layer, whose
> role is to move datagrams along a path of intermediate nodes originating at
> a sender and terminating at a receiver.   The common implementation strategy
> is to write a network layer forwarding program which runs at each
> intermediate node and implements a fixed forwarding protocol.  The network
> layer forwarding program can be changed only through an administrative
> process, often manual; there may also be support in ROM or in hardware.
> 
> This implementation strategy leads to a situation in which a widely
> implemented choice of forwarding protocol, in this case a particular flavor
> of IPv4, becomes expensive and disruptive to change.  Cisco is often blamed,
> but one might also blame the implementation strategy, which encourages
> investment in hardware, software and procedures that makes the network layer
> protocol difficult to change.

Alternately, it is precisely the reason the Internet has become 
ubiquitous, vs., e.g., protocols with more "fluxibility" ;-)

> Various discussions on this list concern disagreements over what functions
> should or should not be implemented at the intermediate node - "tussle" has
> been suggested as a term for this kind of dispute. ...
...
> In each of these cases, the use of the network layer as a means to hide the
> existence of intermediate nodes from the endpoint is compromised in some
> respect.  In the case of source routing, the indentity and order of
> individual nodes on the path are exposed.  Even to choose between paths is a
> way of taking account of the fact that they are comprised of different
> nodes.  In the case of Active Networking, the functionality of the
> intermediate node is exposed to endpoints in the form of a programming
> interface.  These are all attempts to achieve flexibility by exposing what
> the different options at the network layer have in common, namely that they
> make use of the same basic store and forward capabilities of intermediate
> nodes.
> 
> This analysis suggests the desirability of devising a *common programmable
> model of the intermediate node* that allows endpoints to implement different
> (yet compatible) network layer forwarding strategies.  If such a model could
> be devised that was generic and simple enough to scale, there would still be
> a question of whether it could be efficient and achieve high performance.
> To the extent that this were possible, the result would be increased
> heterogeneity at the network layer, and perhaps a decrease in the need to
> accept common network layer signalling at that is inaequate to meet the
> transport layer needs of paritcular application communities.
> 
> For some early ideas on the definition of such a programmable model of the
> intermediate node, I would refer interested readers to this paper:
> 
> "An End-to-End Approach to Globally Scalable Programmable Networking"
> Micah Beck, Terry Moore and James S. Plank
> Future Directions in Network Architecture Workshop 2003
> http://loci.cs.utk.edu/ibp/files/LoNC-FDNA03.pdf

On a related note, we developed a model that takes advantage of loose 
source routing together with generic string processing, notably to 
support CDN routing at the network layer:

"DataRouter: A Network-Layer Service for Application-Layer Forwarding,"
J. Touch, V. Pingal, Proc. International Workshop on Active Networks 
(IWAN), Osaka, Springer-Verlag, December 2003.
http://www.isi.edu/touch/pubs/iwan2003

It's fairly simple to implement, and leaves the complexity where it 
inherently lies - in the routing protocol. As to performance, string 
matching can be compiled into fairly efficient code (roughly half the 
rate of conventional IP forwarding).

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20040426/4a4d694c/signature.bin