Subject: Re: [Sigtran] SUA: Filler in Global Title Address

From: [email-masked]
Date: Mon, 19 Aug 2002 14:29:44 +0530

Hi Brian,

Section 3.1.5 talks about the padding bytes, section 3.10.2.3 uses the term
filler bytes. So rules listed in section 3.1.5 does not apply for Global Title
Digits. Please use the term padding in section 3.10.2.3. Again, this has caused
interoperability issues once, a clarification will help avoid any such issues in
future with other Vendors.

Best Regards,
-Sandeep

"Brian F. G. Bidulock" <[email-masked]> on 08/19/2002 12:56:40 PM

Please respond to [email-masked]

To:   Sandeep Mahajan/HSS@HSS
cc:   Vince Deters <[email-masked]>, [email-masked],
      [email-masked], Asif Patel <[email-masked]>

Subject:  Re: [Sigtran] SUA: Filler in Global Title Address

Sandeep,

Ok, its *really* old, but per SUA-08:

> > 80 01 00 0b    06 00 00 00    00 41 61 00

Tag:      0x8001
Length:        0x000b
No. Digits:    0x06
Trans. Type:   0x00
Num. Plan:     0x00
Nature of Add: 0x00
GT Digits:     0 0 1 4 1 6
Padding:  0x00

This coding is correct per section 3.1.5 of the same document.

> > 80 01 00 0c    06 00 00 00    00 41 61 00

Tag:      0x8001
Length:        0x000c
No. Digits:    0x06
Trans. Type:   0x00
Num. Plan:     0x00
Nature of Add: 0x00
GT Digits:     0 0 1 4 1 6
Filler:        0 0

This coding is also correct per section 3.10.2.3.

I don't see where any change is required.  It is incorrect to
reject the first (or second) parameter coding.

The text should stand.

--brian

[email-masked] wrote:
(Mon, 19 Aug 2002 11:36:13)
>
>
>
> Hi Brian,
>
> Please read these bytes as per version 8 of SUA specification. But as the
usage
> of "filler" is same across SUA v8 and SUA v14, the same issue applied to v14
> also.
> As far as the text change is concerned, the following is already suggested by
> Vince.
> a) Change the term filler to padding in SUA GT digits, when used for places
> other than a nibble.
> b) In case filler is to be used for padding the GT digits to align the TLV to
4
> byte boundary, these filler bytes are not included in the TLV length. BTW they
> are included in length parameter in case SCCP GT ?
>
> Again , this is not a big issue. only a small interoperability concern. Both
the
> vendors wants to make sure their implementation is generic to interop with
> everybody else and asked for the clarification. Decision on either way is OK,
as
> long as it is clearly stated in the specification/IG.
>
> Best Regards,
> -Sandeep
>
>
>
>
>
> "Brian F. G. Bidulock" <[email-masked]> on 08/19/2002 11:52:13 AM
>
> Please respond to [email-masked]
>
> To:   Vince Deters <[email-masked]>
> cc:   [email-masked], Sandeep Mahajan/HSS@HSS, [email-masked], Asif
>       Patel <[email-masked]>
>
> Subject:  Re: [Sigtran] SUA: Filler in Global Title Address
>
>
>
>
> Vince,
>
> Vince Deters wrote:
> (Sun, 18 Aug 2002 23:34:47)
> > Brian,
> >
> > Responses inline....
> >
> > "Brian F. G. Bidulock" wrote:
> >
> > > Vince,
> > >
> > > Vince Deters wrote:
> (Sat, 17 Aug 2002 15:39:13)
> > > > Brian,
> > > >
> > > > "Brian F. G. Bidulock" wrote:
> > > >
> > > > > Vince,
> > > > >
> > > > > You need to understand SCCP GT before you can code the SUA parameter
> > > > > anyay.  The SCCP specs are normative.  I don't see a problem.  Leave
> > > > > it as it is.
> > > >
> > > > This confusion caused an interoperability problem between our SG and the
> > > > Hughes ASP. Are you really saying that the Hughes engineers mistakenly
> > > > included the filler bits in the subparameter length because they don't
> > > > "understand SCCP GT"?? That's a bit arrogant, isn't it?
> > >
> > > Who was it that included the padding/filler in the length,
> > > yet understood GT so well?  (I have no idea how one could
> > > possibly get it wrong...)
> >
> > Our SG sent the following GTT subparameter to the Hughes ASP:
> >
> > 80 01 00 0b    06 00 00 00    00 41 61 00
>
> Are you sure you wrote this correctly?
>
> Referring to section 3.10.2.3:
>
>      Tag:      0x8001
>      Length         0x000b
>      Reserved: 0x060000
>      GTI:      0x00
>      No. Digits:    0x00
>      Trans. type:   0x41
>      Num. Plan:     0x61
>      Nature of Add: 0x00
>      GT Digits none
>
> As you wrote it, the length value of 0x000b (11) is incorrect.  The
> GTT parameter as you wrote it must have a length of 0x000c (12).
>
>
> >
> > The ASP's parser rejected the subsequent parameter because the GTT
> > subparameter length (0x000B) doesn't include the filler/padding byte at the
> > end. We confirmed that it was expecting a length of 0x000C by sourcing the
> > same GTT from the ASP, which was sent as:
> >
> > 80 01 00 0c    06 00 00 00    00 41 61 00
>
>      Tag:      0x8001
>      Length         0x000c
>      Reserved: 0x060000
>      GTI:      0x00
>      No. Digits:    0x00
>      Trans. type:   0x41
>      Num. Plan:     0x61
>      Nature of Add: 0x00
>      GT Digits none
>
> This is a syntactically semi-correct GTT subparameter (although the
> reserved field is not zero, and the gti and num plan are incorrect).
> However, 0x000c is the correct length.
>
> It appears your situation has nothing to do with filler bits, you are
> not sending a reasonable GTT at all.  ...Unless you just wrote the bits
> down wrong...
>
> >
> > The explanation from Hughes was simply that the extra byte is filler and not
> > padding and therefore it should be included in the length. It seemed a
> > logical interpretation of the draft, which shows such a byte, and labels it
> > filler.
>
> Using what you presented, this is not a reasonable explanation.  The
> reasonable explanation is that your GTT is mangled.
>
> Could you verify that the bytes you sent are correctly shown above?
>
> --brian
>
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
>
>
>
>
>

--
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

_______________________________________________
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: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 19 Aug 2002 04:13:34 -0600

Sandeep,

Where does it say that the rules in 3.1.5 do not apply to Global Title?
Of course they apply:

	Parameter Length: 16 bits (unsigned integer)

	 The Parameter Length field contains the size of the parameter in
	 bytes, including the Parameter Tag, Parameter Length, and
	 Parameter Value fields.  The Parameter Length DOES NOT INCLUDE ANY
	 PADDING BYTES.  However, COMPONSITE PARAMETERS WILL CONTAIN ALL
	 PADDING BYTES, SINCE ALL PARAMETERS CONTAINED WITHIN THIS
	 COMPOSITE PARAMETER WILL BE CONSIDERED MULTIPLES OF 4 BYTES.

Also:
	 The length of the padding is NOT included in the parameter
	 length field.  A sender should NEVER pad with more than 3 bytes.
	 The receiver MUST ignore the padding bytes.
	
In case (1) cited, the receiver is not ignoring padding bytes in violation
of this MUST above.

Section 3.10.2.3 talks about filler, NOT padding.  Section 3.1.5 talks
about padding.  Both codings are valid and the receiver which rejects
the first coding is violating the MUST above.  The receive which rejects
the second parameter violates 3.10.2.3 which permits including filler
if required.

There is no need for clarification.  Read the passages.

--brian

[email-masked] wrote:                                                   (Mon, 19 Aug 2002 14:29:44)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/