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
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 <guy@xxxxxxxxxxxx>:
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
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev