The IP over ATM Mailing List Archive by date

[rick@louie.timeplex.com (Rick Bubenik)]

> Sorry to have to say this, but I think you're still mistaking the
> point I've made. We agree on the role of LLC/SNAP encapsulation.
> 
> >>> >>I also don't understand where in the SETUP the "and its for {IP, ARP,
> >>> >>whatever}" would go
> >>> 
> >>> The point I was making is that they can't, ergo we need
> >>> to clarify how/why an ARP, or IP, or whatever entity above the LLC layer
> >>> behaves/responds to SVC establishment _prior_ to packets arriving.
> 
> 	[..]
> >>Since the LLC/SNAP demultiplexes on fields in the
> >>data stream, it doesn't make sense to indicate in the SETUP what value
> >>will exclusively be used.
> 
> I haven't said we _should_. I've noted that we _can't_, and therefore
> the behaviour of an ARP Server's ARP entity as per rfc1577 is a bit
> presumptuous in its reponse to an SVC 'arriving at its door step',
> so to speak.

I'm not proposing that we _should_ do this either (I think that the
approach in the RFC is reasonable the way it stands).  However, I'd
like to clear up a misconception.  Namely, SVCs _can_ be created in
this manner.   See Appendix D of the UNI 3.0/3.1 specification for an
example of how this is coded (in particular, the example of D.3.3 could
be modified to use the ARP EtherType as the SNAP ID instead of what's
currently there).  The basic rule is that if the B-LLI information
element contains the full SNAP ID, then "null encapsulation" is to be
used on the SVC (as opposed to LLC/SNAP encapsulation) and the SVC
should terminate at the protocol indicated in the B-LLI of the SETUP
message.

As others have noted (including myself), this results in a dedicated
SVC to the ARP server that cannot be used for any other traffic to
the ARP server machine.  I believe that this is the main objection
raised to mentioning this in the RFC as an allowable alternative.

> 	[..]
> >>Proposing to declare which LLC/SNAP (and further down the protocol
> >>chain as I mistakenly was thinking) you will be using in the SETUP is
> >>similar in that it tries to move demultiplexing from the data stream
> >>to the VCI.  I don't see the need to eliminate the role of LLC/SNAP by
> >>dedicating a VC to one LLC/SNAP value.
> 
> I'm not sure why you think I'm proposing that. Such a philosophy
> might be implied from some other posters, but I'm sticking exactly
> to the 'LLC terminates all sorts of VCs, so LLC clients shouldn't
> be making assumptions about who's at the other end' line. Given this,
> I'm asking what clarifications or modifications can be made to the
> ARP Server description in rfc1577.

I agree that the description could use some clarification.  I propose
describing the problem (that LLC/SNAP connection may not have been
created to the machine for the purpose of talking to the ARP server,
and this can't be know when the SETUP message arrives, given the required
B-LLI encoding) and then describing the behavior (that the ARP server
will send an IN-ARP out all SVCs, regardless of the intended use of
the SVC).

	rick