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

From: [email-masked]
Date: Mon, 19 Aug 2002 11:36:13 +0530

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/

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 19 Aug 2002 00:26:40 -0600

Sandeep,

> > 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)

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

---

From: Vince Deters <[email-masked]>
Date: Mon, 19 Aug 2002 09:22:46 -0400

Brian,

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

Agreed.

> This coding is also correct per section 3.10.2.3.

This coding may be correct for cases where filler is more than one nibble, but section 3.10.2.3 references
Q.713, which restricts filler to one and only one nibble. To quote from my prior note. "If I need to read
Q.715 to understand that filler could be more than one nibble, then at the very least, Q.715 needs to be
referenced in the draft in addition to Q.713. Or remove all references and define filler in the draft. But
don't leave it as is, with one reference to Q.713 that very clearly defines filler as one nibble."

Vince

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 19 Aug 2002 07:39:52 -0600

Vince,

Vince Deters wrote:                                                                (Mon, 19 Aug 2002 09:22:46)
> don't leave it as is, with one reference to Q.713 that very clearly defines filler as one nibble."

You don't need to read Q.715, all you need to do is look at the diagram
in 3.10.2.3 to see that the filler can be more than one nibble.  Thus
the text is sufficient as it stands.

--brian

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

---

From: Vince Deters <[email-masked]>
Date: Mon, 19 Aug 2002 10:11:42 -0400

> the text is sufficient as it stands.

My point is that the diagram and Q.713 are inconsistent - Q.713 restricts filler to one nibble but the diagram
shows more than one nibble. The text is unclear as it stands.

Vince

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 19 Aug 2002 08:23:46 -0600

Vince,

Vince Deters wrote:                                                                (Mon, 19 Aug 2002 10:11:42)
> My point is that the diagram and Q.713 are inconsistent - Q.713 restricts
> filler to one nibble but the diagram shows more than one nibble. The text is
> unclear as it stands.

It is not unclear: the text says:

	"Octets contain a number of address signals and possibly filler as
	 shown:"

and
	"Address signals to be coded as defined in ITU-T Q.713 Section
	 3.4.2.3.1."

This does not say that the use of filler is per ITU-T Q.713; it says that
filler is "as shown".

There is no inconsitency.  Look to Q.713 for the coding of address signals
only as specified in the text.  For use of filler, look to the diagram.

The text is clear as it stands.

--brian

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

---

From: Vince Deters <[email-masked]>
Date: Mon, 19 Aug 2002 11:21:59 -0400

>         "Address signals to be coded as defined in ITU-T Q.713 Section

Huh? What kind of half-assed reference is that??

If Q.713 is to be honored for address signals but ignored for filler, then just remove the reference entirely and
simply copy the following address signal description from Q.713:

"Each address signal is coded as follows:
0000 digit 0
0001 digit 1
0010 digit 2
0011 digit 3
0100 digit 4
0101 digit 5
0110 digit 6
0111 digit 7
1000 digit 8
1001 digit 9
1010 spare
1011 code 11
1100 code 12
1101 spare
1110 spare
1111 ST"

Done. Everything explicitly defined.

I can honestly say that this novel interpretation never occurred to me. I'm curious how many other sigtran readers
were able to infer that the filler description in Q.713 is to be ignored.

Vince

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 19 Aug 2002 09:33:46 -0600

Vince,

Vince Deters wrote:                                                                (Mon, 19 Aug 2002 11:21:59)
> Huh? What kind of half-assed reference is that??

It is what the text says.

> Done. Everything explicitly defined.

That would not be sufficient: address signals are dependent upon nature of
address; they are sometime BCD and somtimes not.  Q.713 details the form of
address signals dependent upon NAI.

> 
> I can honestly say that this novel interpretation never occurred to me. I'm
> curious how many other sigtran readers were able to infer that the filler
> description in Q.713 is to be ignored.

It is not novel: it is literal.

--brian

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

---

From: Vince Deters <[email-masked]>
Date: Mon, 19 Aug 2002 12:00:44 -0400

> address signals dependent upon NAI.

That would not be sufficient? That is the complete address signal description from Q.713 section 3.4.2.3.1, which is the
reference in the draft that you quoted above. You've just confirmed that the draft is deficient.

Vince

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 19 Aug 2002 10:09:21 -0600

Vince,

Vince Deters wrote:                                                                (Mon, 19 Aug 2002 12:00:44)
> 
> That would not be sufficient? That is the complete address signal
> description from Q.713 section 3.4.2.3.1, which is the reference in the
> draft that you quoted above. You've just confirmed that the draft is
> deficient.
> 

The entire Q.713 document is normative, so it is not deficient.

--brian

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

---

From: Vince Deters <[email-masked]>
Date: Mon, 19 Aug 2002 12:55:26 -0400

Ok, I'm going to graciously cease my participation in this futile discussion. You simply don't want to help when
help is needed. Thanks.
Vince

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 19 Aug 2002 11:23:07 -0600

Vince,

Your welcome.

--brian

Vince Deters wrote:                                                                (Mon, 19 Aug 2002 12:55:26)

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