Subject: RE: Fw: [tnua] [Fwd: Re: [Sigtran] IUA: Bit order in DLCI field.. . please explain again]

From: Tuexen Michael <[email-masked]>
Date: Thu, 4 Jul 2002 16:52:17 +0200

Ken,

from RFC 3057:

   The DLCI format is shown below in Figure 6.

      0     1     2     3     4     5     6     7
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |  0  | SPR |      SAPI                         |
   +-----------------------------------------------+
   |  1  |            TEI                          |
   +-----------------------------------------------+

              Figure 6  DLCI Format

   SPR:  Spare 2nd bit in octet 1, (1 bit)

   SAPI: Service Access Point Identifier, 3rd through 8th bits in octet
      1 (6 bits)

   TEI:  Terminal Endpoint Identifier, 2nd through 8th bits in octet 2
      (7 bits)

   The DLCI field (including the SAPI and TEI) is coded in accordance
   with Q.921.

In my understanding this text (including the figure) states that you
encode the DLCI the same way you do it in Q.921. This is illustrated
by figure 6. But I think the goal is that you do not modify your data
and encode it as described in Q.921.

From Q.921 it is clear that the '1' at the TEI byte is the
least significant bit of the byte. 

This should also hold for the representation in the IUA accordig to the
sentence 'The DLCI field is coded in accordance with Q.921.'
This figure therefore is not very helpful. At least it must be stated
that the bit numbered as 0 is the least significant bit of the byte which
is not the usual way in the IETF. From http://www.ietf.org/ID-nits.html

Bit and Byte order in drawings

     Historically, RFCs have specified byte and bit order according to a US DoD
     rule which made byte zero be the first byte in an address range, and bit
     zero be the most significant bit in a word or field.
     For example, you will find drawings like this one (from RFC 791) in many RFCs:
     when you make drawings like it, you should follow
     the same rule. Label your bit positions, bit zero is the most significant bit,
     and place the first addressable byte at the upper left-hand corner. 

The same problem came up several times and I always suggested 'delete the figure'.
Everyone knows what to do from the ITU recommendation and it is difficult to
transform.

So I would suggest:

Put in the Implementors Guide text that clearly states that the format of
Q.921 is used and give a figure which talks about most/least significant bits.

I can send you text, if you want. In summary this means that format #2 is the correct
one, not format #1 because you do not want to modify the DLCI during processing.

I will fix the ethereal dissector according the Q.921 encoding.

Best regards
Michael

Michael Tuexen    Tel.:   +49 89 722 47210
Siemens AG        Fax:    +49 89 722 48212
ICN WN CC SE 7    e-Mail: [email-masked]

> -----Original Message-----
> From: Ken Morneault [mailto:[email-masked]]
> Sent: Tuesday, July 02, 2002 7:01 PM
> To: [email-masked]; Venkataramana. N
> Cc: [email-masked]
> Subject: Re: Fw: [tnua] [Fwd: Re: [Sigtran] IUA: Bit order in DLCI
> field.. . please explain again]
> 
> 
> 
> 
> All:
> 
> For better or worse, the format that I believe is correct 
> based on how the RFC
> is written is format #1.  
> 
> Regards,
> 
> Ken
> 
> At 11:52 AM 6/20/2002 +0530, [email-masked] wrote:
> 
> 
> 
> >Hi Venky,
> >
> >If you see the explanation for SAPI (section 3.3.3) and TEI 
> (section 3.3.4) in
> >Q.921,
> >it clearly mentions the following:
> >
> >Within the context:
> >
> >        8    7    6    5    4    3    2    1   | <- Bit
> >       ----------------------------------------
> >                                               |
> >            S    A    P    I          CR   EA  |    Octet 2
> >                                           0   |
> >                                               |
> >            T    E    I                    1   |    Octet 3
> >
> >For SAPI,
> >
> >"The  SAPI  allows  64 service access points to be 
> specified, where bit 3 of the
> >address field
> >
> >octet containing the SAPI is the least significant binary 
> digit and bit 8 is the
> >most significant."
> >
> >For TEI,
> >
> >"The  TEI  subfield  allows  128  values  where bit 2 of the 
> address field octet
> >containing the
> >
> >TEI  is  the  least  significant  binary digit and bit 8 is 
> the most significant
> >binary digit. "
> >
> >
> >
> >you may see "Figure 3/Q.921 - Field mapping convention" for 
> more clarification.
> >
> >
> >
> >hope this makes the picture more clear.
> >
> >
> >
> >regards,
> >
> >-Dipak
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >"Venkataramana. N" <[email-masked]> on 06/20/2002 
> 11:34:50 AM
> >
> >To:   [email-masked]
> >cc:    (bcc: Dipak Bash/HSS)
> >
> >Subject:  Fw: [tnua] [Fwd: Re: [Sigtran] IUA: Bit order in 
> DLCI  field... please
> >      explain  again]
> >
> >
> >
> >
> >Hi Dipak,
> >
> >Please view using fixed size font, like courier
> >
> >ITUT Q.921 DLCI format is
> >
> >        8    7    6    5    4    3    2    1   | <- Bit
> >       ----------------------------------------
> >                                               |
> >            S    A    P    I          CR   EA  |    Octet 2
> >                                           0   |
> >                                               |
> >            T    E    I                    1   |    Octet 3
> >
> >        EA  - Address Field Extension bit
> >        C/R - Command/Response Field
> >
> >Q.921 doc states that:
> >
> >The bits are grouped into octets. The bits of an octet are 
> shown horizontally
> >and are numbered from 1 to 8. Multiple octets are shown 
> vertically and are
> >numbered from 1 to n.
> >
> >The octets are transmitted in ascending numerical order; 
> inside an octet bit 1
> >is the first bit to be transmitted.
> >
> >When a field is contained within a single octet, the lowest 
> bit number of the
> >field represents the lowest order value.
> >
> >
> >I think IUA RFC has presented it in a easy to understand 
> manner, so i feel
> >Format #1
> >
> >             OCTET 2          OCTET 3
> >
> >        0               1               2               3
> >        0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 
> 2 3 4 5 6 7
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |0|S|  SAPI     |1|      TEI    | |             | |   
>           |
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >is correct.
> >
> >
> >What do you think? Correct me if i missed something.
> >
> >Thanks,
> >Venky
> >
> >> >
> >> >Hi Pascal Bouveron ,
> >> >I agree with you that format #2 is correct and should be 
> used/implemented,
> >> >except that, the value you have mentioned for SAPI = 0, TEI = 64.
> >> >In this case, the 32-bit value would NOT then be 0x00030000.
> >> >It would be 0x00810000.
> >> >
> >> >Here the thumb rule is,
> >> >
> >> >for TEI, if you want to put value "X", then in while
> >> >setting the value, set 2*X+1.
> >> >for SAPI, if you want to put value "Y", then in while
> >> >setting the value, set 4*Y.
> >> >
> >> >thanks,
> >> >Dipak
> >> >
> >> >
> >> >
> >> >
> >> >Pascal Bouveron <[email-masked]> on 
> 06/12/2002 10:49:22 PM
> >> >
> >> >To:   "[email-masked]" <[email-masked]>
> >> >cc:    (bcc: Dipak Bash/HSS)
> >> >
> >> >Subject:  [Sigtran] IUA: Bit order in DLCI field... 
> please explain again
> >> >
> >> >
> >> >
> >> >
> >> >Hi,
> >> >
> >> >After having browsed into the mail archives about this 
> subject, i found
> >> >answers
> >> >a bit confusing.
> >> >I would like to make absolutely sure about the DLCI 
> encoding format within
> >the
> >> >DLCI Parameter of the IUA.
> >> >
> >> >Would the DLCI be coded as follows (format #1): (bit 0 is 
> transmitted
> >> >first and
> >> >is the MSBit)
> >> >
> >> >        0                   1                   2         
>           3
> >> >        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 
> 5 6 7 8 9 0 1
> >> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> >       |0|S|  SAPI     |1|      TEI    |                  
>              |
> >> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> >
> >> >With SAPI=0 and TEI=0, the 32-bit value would then be 0x00800000.
> >> >With SAPI=0 and TEI=64=0x40, the 32-bit value would then 
> be 0x00C00000.
> >> >
> >> >Or would it rather be encoded as in format #2 below:
> >> >
> >> >        0                   1                   2         
>           3
> >> >        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 
> 5 6 7 8 9 0 1
> >> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> >       |  SAPI     |S|0|      TEI    |1|                  
>              |
> >> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> >
> >
> >
> >> >With SAPI=0 and TEI=0, the 32-bit value would then be 0x00010000.
> >> >With SAPI=0 and TEI=64=0x40, the 32-bit value would then 
> be 0x00030000.
> >> >
> >> >According to Q.921, the format of the DLCI field is 
> encoded and transmitted
> >in
> >> >the following order:
> >> >(bit 0 is transmitted first, and is the MSBit):
> >> >
> >> >        0                   1
> >> >        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
> >> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> >       |  SAPI     |S|0|      TEI    |1|
> >> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> >
> >> >In my opinion,  format #2 would be the correct format 
> considering that the
> >RFC
> >> >says
> >> >"The DLCI field (including the SAPI and TEI)is coded in 
> accordance with
> >> >Q.921.".
> >> >
> >> >Using Format #2 would seem more "natural", as the 
> transcription to the Q.921
> >> >format is immediate,
> >> >whereas using format #1 would require bit-inversion in 
> each (8-bits) octet of
> >> >the DLCI value
> >> >before encoding it into a Q.921 frame.
> >> >
> >> >However, I faced DLCI format mismatch when trying to 
> interop with several
> >> >other
> >> >vendors' IUA devices, which where obviously using Format #1,
> >> >i.e with SAPI=0 and TEI=0, the 32-bit value is 0x00800000.
> >> >
> >> >Even the Ethereal analyzer decodes the DLCI as in Format #1.
> >> >
> >> >So the question is: Format #1 or Format #2 ?
> >> >
> >> >Thanks,
> >> >Pascal Bouveron -- Netbricks (formerly Omnitel)
> >> >mailto:[email-masked] -- http://www.netbricks.com
> >> >
> >> >
> >> >_______________________________________________
> >> >Sigtran mailing list
> >> >[email-masked]
> >> >https://www1.ietf.org/mailman/listinfo/sigtran
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >_______________________________________________
> >> >Sigtran mailing list
> >> >[email-masked]
> >> >https://www1.ietf.org/mailman/listinfo/sigtran
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Ken Morneault <[email-masked]>
Date: Thu, 04 Jul 2002 17:23:39 -0400

Michael,

I'm fine with this change if everyone else is.  Everyone, please comment.

Ken