[e2e] common interface: path or node?
touch at ISI.EDU
Mon Apr 26 08:40:09 PDT 2004
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
> 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
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.
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).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20040426/4a4d694c/signature.bin
More information about the end2end-interest