The IP over ATM Mailing List Archive by date

[mks@msc.edu (Mike Spengler)]

> This is all getting back to the original questions posed in this thread,
> that is, call routing when setting up LLC/SNAP VCs.

I think this is a good place to get back to!

> I think one of the problems here is that we've skipped a layer in defining
> how calls are  routed (that is, we've defined things for an LLC user before
> the LLC layer call handling has been defined).  This makes things a bit
> confusing since we're asking the IP entity to do things that the LLC layer
> should really be doing (like looking at the signalling message and doing
> MTU negotiation, or even defining default values which may not be appropriate
> for other LLC users).

I completely agree.  It seems kind of silly to be building our "standardized" 
IP over ATM solution on top of such a non-defined, non-standard.  The semantics
of using a "shared LLC" entity have not been specified, and as much of this 
thread illustrates, they are likely to be somewhat complex.  From what I've
gathered so far, implementations are either ignoring the sharing issue (IP/ARP
over LLC is all they support anyways) or they admit sharing is possible but
don't allow IP/ARP to share their VCs.  But they are all ad hoc, implementation
specific interpretations.

It also doesn't seem like defining LLC sharing is within the purview of this
group.  Perhaps this is something that the forthcoming ATM Forum Multi-Protocol
BOF should take up?  If someone gets around to specifying how shared LLC 
should work, THEN we can come back and define how IP should work with it.

> I would almost be willing to say that null encapsulation
> would be best since this would get us away from these issues and give IP
> and ATMARP full control over their VCs and would eliminate these LLC layering
> problems (until such a layer is better defined).

Right, one ATMARP VC (per LIS?) and one (or more) IP VCs.  In a PVC-only
environment, the ATMARP VC would have to be a PVC.

Another alternative would be to specify in the B-LLI IE: Layer2=LLC,Layer3=IP.
Now, IP is the owner of the VC, but it uses LLC encapsulation to allow ONLY
IP and ATMARP packets across the VC.

> I think there is general confusion about using LLC VCs simply because the
> use of the LLC layer for ATM is not well defined (and I too may be greatly
> confused here).  I hope we get a deluge of comments too, since this will
> help us all resolve any potential interoperability problems sooner than later.
> I'm always open to a deluge of contructive comments ;-)

I think we need to resolve these issues NOW, before the wide-scale deployment
of (potentially) non-interoperating implementations.   We should not wait for
the document rewrites before we deal with this.  One thing we definitely
should avoid is having to hack up backwards-compatible solutions.

-- 
Mike Spengler				Minnesota Supercomputer Center, Inc.
Email: mks@msc.edu			1200 Washington Ave. So.
Phone: +1 612 337 3557			Minneapolis MN 55415
FAX:   +1 612 337 3400