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

From: Ken Morneault <[email-masked]>
Date: Tue, 02 Jul 2002 13:00:56 -0400

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