Re: Not understanding something in LLC

Hi . I have been searching in a lot of pages and in books to see if there
could be LLC frames other than those that have a 0x03 control field value
using SNAP (so they have 5 additional bytes after the LLC control field) and
i have found that many of them say that the control field must have the 0x03
value;
I dont know,for example you can see it in

http://www.javvin.com/protocolSNAP.html

where it says :

When SNAP is present the DSAP and SSAP fields within the LLC header contain
the value 170 (decimal) each and the Control field is set to 3 (unnumbered
information).
or for example in the book " Network protocol handbook" from Mathew Naugle
(McGraw-Hill Series on Computer Comunications) it says also that the control
field must have a value 0x03.
I come back to this issue because im in a trouble with the implementation of
LLc type2.
Suppose i have a connection component like the one described in the ISO 8802
for managing Type2 traffic in a local LSAP.Eacj connection component has an
identifier composed of DA,DSAP,SA,SSAP. So then i can have a connection
component with the identifier XX:XX:XX:XX:XX:XX,AA,YY:YY:YY:YY:YY:YY,AA to
identify a connection between those SAP's on those LSAPs.
There is a situation in the operation of that component on which when it
detects that the acknowledgement timer has expired it must send a disconnect
indication primitive to the upper layer through the connected LSAP. But the
LSAP is the AA LSAP and there could be a lot of network entities waiting for
a connection to be established. I must know which network entity is the one
whch i have to communicate the DISCONNECT situation. And i haven't any way
to know which entity is the one i need because the connection identifier
tells me onlythe LSAP (AA in this case) but not for example the SNAP which
correponds to the upper network protocol. Im missing something maybe?? I
have thought that maybe the connection must be identified in the
AA-LSAP-situation witha n additional 5 five identifier (the SNAp of teh
upper protocol)
I dont know if i have explained myself correctly, sorry for the mess.
Thanks


2006/6/29, Guy Harris <[email protected]>:
>
> Eduardo Escudero Sánchez wrote:
>
> > But i dont understand. If you go to teh standard 802.2-1998 to the
> > 5.4.2.1 <http://5.4.2.1> for example (Format of the I - PDU) you can see
> > in the drawing that the bits are numbered from 1 to 16 and teh only
> > indication it gives you is that the bit numbered with 1 is the least
> > significant byte so one can deduce from here that the most significant
> > bit of teh conrol field is teh bit numbered with 16 so the first byte of
> > the control field will be the byte whose eight bits are the last eigth
> > bits of the drawing. So you can not go to the last bit of the first byte
> > to see the type of frame because you will be seeing the value of the P/F
> > bit, dont you?
>
> If bits are transmitted in the order in which they're shown in 5.4.2.1;
> the only way in which bit 1 would be the low-order bit of the *second*
> octet of a 2-octet control field would be if the second octet were
> transmitted first.
>
> That seems unlikely to be the case.
>
> Note that the control field is two octets, not a single 16-bit quantity;
> see 3.3.2 "Control field":
>
>        The control field shall consist of one or two octets that shall be
> used
> to designate command and response functions, and shall contain sequence
> numbers when required.
> _______________________________________________
> Ethereal-dev mailing list
> [email protected]
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>

_______________________________________________
Ethereal-dev mailing list
[email protected]
http://www.ethereal.com/mailman/listinfo/ethereal-dev