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

From: [email-masked]
Date: Fri, 16 Aug 2002 07:19:20 -0500

Hi,

I concur with Brian's summary.  I am curreently on vacation with only an Internet enabled phone, so a further comment will have to wait until I get back.

John

_____________Original message ____________
Subject:	Re: [Sigtran] SUA: Filler in Global Title Address
Sender:	ext Brian F. G. Bidulock <[email-masked]>
Date:		Fri, 16 Aug 2002 07:02:42 -0500

Sandeep,

This is no different than SCCP: the filler nibble is never accounted for
in the length of the parameter (the length is only an integer number of
full octets).  See the SCCP specifications (e.g., the referenced Q.713
section) for how this is addressed in SCCP and it might be clearer for
you.  I don't think that there is a problem with the specificiation: if
one understands how GTs are coded for SCCP, how they are coded for SUA
becomes obvious.

--brian

[email-masked] wrote:                                                   (Fri, 16 Aug 2002 09:46:54)
> 
> 
> 
> Hi John,
> 
> Can you please clarify this. Clarification on this will help avoid
> inter-operability issues when Global Title is being used as Address parameter.
> 
> Best Regards,
> -Sandeep
> 
> 
> 
> 
> 
> Asif Patel <[email-masked]> on 08/05/2002 08:57:17 PM
> 
> To:   [email-masked]
> cc:    (bcc: Sandeep Mahajan/HSS)
> 
> Subject:  [Sigtran] SUA: Filler in Global Title Address
> 
> 
> 
> 
> Hi All,
> 
> Could someone please clarify on the text below concerning filler in the
> SUA global title address? Should 'filler', which is added to the end of
> the SUA global title parameter to pad the parameter to a 4-byte
> boundary, be included in the parameter length?
> 
> For example, let's say I have a 9 digit global title address (e.g.
> 123456789). As per the text below, the SUA global title address would be
> coded as follows:
> 
> 21436587
> 09000000
>   ^^^^^^
>   Filler
> 
> So, my question is should this "filler" be included in the length of the
> global title parameter, or is this considered "padding"?
> 
> Thanks in advance for your help.
> 
> Best Regards,
> Asif
> 
> 
> >From section 3.10.2.3,
> 
> Global Title:
> 
>     Octets contain a number of address signals and possibly filler as
>     shown:
> 
>       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
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |2 addr.|1 addr.|4 addr.|3 addr.|6 addr.|5 addr.|8 addr.|7 addr.|
>      |  sig. | sig.  |  sig. | sig.  |  sig. | sig.  |  sig. | sig.  |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |        .............          |filler |N addr.|   filler      |
>      |                               |if req | sig.  |               |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    All filler bits SHOULD be set to 0.
> 
>    Address signals to be coded as defined in ITU-T Q.713 Section
>    3.4.2.3.1.
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 
> 
> 
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

-- 
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: Vince Deters <[email-masked]>
Date: Fri, 16 Aug 2002 08:52:54 -0400

It would seem therefore that the last byte in the Global Title figure in 3.10.2.3 should be labeled "padding" (or at least something besides "filler"). Since
we seem to be in agreement that these byte(s) are not included in the subparameter length, "padding" seems like an appropriate term. The actual filler nibble
is already correctly shown in the figure.

Vince

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 16 Aug 2002 15:57:42 -0600

Vince,

Well no, cause they could actually be filler bits and not padding.
Also, the padding rules in 3.1.5 apply to all parameters and no
exception is made here.  IMO no change is required.

--brian

Vince Deters wrote:                                                                (Fri, 16 Aug 2002 08:52:54)
> It would seem therefore that the last byte in the Global Title figure in
> 3.10.2.3 should be labeled "padding" (or at least something besides
> "filler"). Since we seem to be in agreement that these byte(s) are not
> included in the subparameter length, "padding" seems like an appropriate
> term. The actual filler nibble is already correctly shown in the figure.
> 
> Vince
> 

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

---

From: Vince Deters <[email-masked]>
Date: Fri, 16 Aug 2002 18:13:59 -0400

How could they be filler bits if there is at most one nibble of filler which is already shown in the figure?? Or am I wrong in assuming that there will never be
more than one nibble of filler?
Vince

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 16 Aug 2002 16:22:05 -0600

Vince,

Where does it say that filler bits are limited to one nibble?  They
aren't in SCCP.  SCCP permits filling out the GT to a fixed size to
ease processing.

Again, there is no need for a change.

--briaN

Vince Deters wrote:                                                                (Fri, 16 Aug 2002 18:13:59)

> How could they be filler bits if there is at most one nibble of filler which
> is already shown in the figure?? Or am I wrong in assuming that there will
> never be more than one nibble of filler?
> Vince
> 

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

---

From: Vince Deters <[email-masked]>
Date: Sat, 17 Aug 2002 05:44:07 -0400

Brian,

ITU-T Q.713 Section 3.4.2.3.1. (referenced in the draft) shows only one nibble of filler in the figure, and the text states "In case of an odd number of address
signals, a filler code 0000 is inserted after the last address signal". How can this possibly be interpreted to allow for more than one nibble of filler?

Vince

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 17 Aug 2002 05:03:46 -0600

Vince,

See Q.715 where it is required that SSN=0 be included so that the GT can
be changed "in place".  The same is true for address digits which can be
shifted "in place" when digits are removed from the beginning of the GTAI.
Whether the remaning room in the AI is cut using the CDPA or CGPA parm
length or if fillers are stuffed it makes little difference.

BTW, what difference does it make if they are called "filler" or if they
are called "padding": they will still be coded 0.  So, there is still no
need for a change.

--brian

Vince Deters wrote:                                                                (Sat, 17 Aug 2002 05:44:07)
> Brian,
> 
> ITU-T Q.713 Section 3.4.2.3.1. (referenced in the draft) shows only one
> nibble of filler in the figure, and the text states "In case of an odd
> number of address signals, a filler code 0000 is inserted after the last
> address signal". How can this possibly be interpreted to allow for more than
> one nibble of filler?
> 
> Vince
> 

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

---

From: Vince Deters <[email-masked]>
Date: Sat, 17 Aug 2002 14:15:06 -0400

> are called "padding": they will still be coded 0.  So, there is still no

The issue is not whether they're coded to 0, the issue is whether they are included in the GTT subparameter length. This is unclear in the current draft because they are
called filler, and filler is not defined in the draft. 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: Sat, 17 Aug 2002 12:53:04 -0600

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.

--brian

Vince Deters wrote:                                                                  (Sat, 17 Aug 2002 14:15:06)
> The issue is not whether they're coded to 0, the issue is whether they are
> included in the GTT subparameter length. This is unclear in the current
> draft because they are called filler, and filler is not defined in the
> draft. 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
> 
> >
> >
> > --brian
> >

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

---

From: Vince Deters <[email-masked]>
Date: Sat, 17 Aug 2002 15:39:13 -0400

Brian,

> anyay.  The SCCP specs are normative.  I don't see a problem.  Leave

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?

This was enough of a problem to cause us to collectively throw up our hands and bring it up on the alias. Therefore there is a problem with the draft. Doesn't matter if you
don't see it from up there. Fix it.

Vince

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 17 Aug 2002 14:16:28 -0600

Vince,

Please suggest text for the implementor's guide.

--brian

Vince Deters wrote:                                                                  (Sat, 17 Aug 2002 15:39:13)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 17 Aug 2002 14:52:48 -0600

Vince,

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

> 
> This was enough of a problem to cause us to collectively throw up our hands
> and bring it up on the alias. Therefore there is a problem with the draft.
> Doesn't matter if you don't see it from up there. Fix it.

Could you describe what happened better...  What was sent by one end
and what was the confusion made by the other end?

--brian

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

---

From: Vince Deters <[email-masked]>
Date: Sun, 18 Aug 2002 23:34:47 -0400

Brian,

Responses inline....

> 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

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

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.

Vince

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 18 Aug 2002 23:22:13 -0600

Vince,

Vince Deters wrote:                                                                (Sun, 18 Aug 2002 23:34:47)
> 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:
> 

	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/

---

From: Andrew Booth <[email-masked]>
Date: Tue, 20 Aug 2002 08:58:52 -0400

Hey All,

Is this option of text in the implementor's guide of interest?

Andrew

>Vince Deters wrote:                                                                  (Sat, 17 Aug 2002 15:39:13)
[ snip ]