Subject: RE: [arch-d] Mobility and multi-homing: Summary and going forward

From: "Bound, Jim" <[email-masked]>
Date: Fri, 11 Nov 2005 10:39:56 -0500

> At the shim6 meeting in Paris, Christian Huitema pointed out that
> while we like to think that TCP & IP are separate layers, that's
> not how people implement them.  I think that any 'layer' between
> transport & IP might be a separate layer on paper, but won't be
> in implementation.

I did not agree with this comment then nor do I now.  I have implemented
a lot of stacks and the transport is always called (referenced if you
prefer) after the IP layer processing.  The entire Internet reference
protocol architecture are virtual layers.  There is one even above the
transport virtual layer and typically the interface to what is known as
user space though that is evolving too.

So if we are to speak of needing a new layer above IP but before
transport processing then that will be a new virtual layer.

Also realize that what we do not want to do is create a bottlneck making
the middle virtual layers fat and slow either.

/jim

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 12 Nov 2005 12:58:00 -0800

>> the middle virtual layers fat and slow either.

    In the spirit of modularity, you could implement the shim in one of the
    following OS process models (ignore kernel versus user space for now):

    (1) As a library called from the TCP/UDP process in both ingress and egress
        directions.

    (2) As a library called from the IP process in both ingress and egress
       directions.

    (3) As a separte process where on egress from TCP/UDP and ingress from IP,
        would use an IPC mechanism. As well as the separate shim process being
        an egress to both TCP/UDP and IP (for each packet direction).

    (4) A library which is shared by both the TCP/UDP and IP processes.

    It would be real nice if (3) could be avoided. And would be nice if
    the shim6 working group would decide if this is a transport function or
    an network layer function so (4) could be avoided.

    So what do people think, can this be implemented as (1) or (2)?

Dino