Subject: RE: M3UA and SUA: Point Code formats

From: "Greg Sidebottom" <[email-masked]>
Date: Fri, 9 Mar 2001 14:55:36 -0500

Hi Joyce,

I'll put my two cents together with Brian to make four cents  2:^)

My reading of the proposal (tell me if I missed the point though!) is this
really only identifies the length of the point codes (14- or 24-bits) in the
SSNM messages and how they are broken down into sub-fields for display on
the analyzer.   It doesn't really tell you the SS7 protocol version/variant
used, which the analyzer (and end-points) have to know anyway to understand
the format of the Data message payload.  But once you know the SS7 protocol
version/variant used, I think you will then know both the Point Code format
in the Routing Label and the Point Code format in the SSNM messages. 

Also, the example you provided shows only 8-8-8 ANSI and 3-8-3 ITU
breakdowns.  I think there are some other national breakdowns possible
besides 3-8-3 and there is also a 16-bit Point Code (Japan?) that is not
covered.  The part on ANSI Cluster PC is already covered by the Mask field
so is not necessary.  As for "raw 14-bit" I guess this is really just a
default display if you don't know the point code breakdown.

Five cents can probably beat the four cents on the table - other views?

Regards,

      Greg 

 -----Original Message-----
From: 	Brian F. G. Bidulock [mailto:[email-masked]] 
Sent:	Thursday, March 08, 2001 6:12 PM
To:	Joyce Archibald
Cc:	[email-masked]
Subject:	Re: M3UA and SUA: Point Code formats

Joyce,

How does an SS7 network analyzer know the format of the point code?
(Only by the protocol running on the link, which is not part of the
SS7 message).

I don't see any need to make M3UA and SUA more monitorable than SS7
itself by placing redundant information into every packet.

Just my two cents...

--Brian

Joyce Archibald wrote:                       (Thu, 08 Mar 2001 08:22:43)
> Hi All,
> 
> >From the point of view of a Protocol Analyser/Link Monitoring System,
> when decoding point codes from any of the adaption layers, it is
> necessary to know which format is being used.
> 
> In the case of M3UA and SUA, a number of messages contain point codes of
> the form:
> 
>     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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |               Tag             |           Length              |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   Mask        |         Point code                            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> There is no way to tell what the format of the point code is, since the
> Network Appearance parameter is defined locally and is only optionally
> present.
> 
> In the TALI specification (<draft-benedyk-sigtran-tali-01.txt>) this
> problem was solved by attaching a type field to each pointcode, as
> follows:
> 
>    +-----------+------------------------------------------------------+
>    |Field Type | Implementation Notes for that Type                   |
>    +------------------------------------------------------------------+
>    |SS7 Point  | Used to transmit point code information for ANSI or  |
>    |Code       | ITU variants of point codes across the TALI interface|
>    |           | * The point code structure is 4 bytes. Byte 3 is used|
>    |           |   to identify the TYPE of point code. The actual     |
>    |           |   point code is then encoded in bytes 0-2 (w/byte 0  |
>    |           |   being the least significant byte and the first byte|
>    |           |   transmitted across the wire)                       |
>    |           | * Byte 3: encoding of the type of point code (PC)    |
>    |           |   0 = an ANSI Full PC                                |
>    |           |   1 = an ITU International Full PC w/ a 3/8/3 coding |
>    |           |       scheme for zone/area/identifier                |
>    |           |   2 = an ITU National Full PC w/ a raw 14 bit PC     |
>    |           |   3 = unused                                         |
>    |           |   4 = an ANSI Cluster PC                             |
>    |           | * For ANSI Full PC w/byte 3=0.  These point codes are|
>    |           |   24 bit point codes as follows:                     |
>    |           |   Byte 2 = Network                                   |
>    |           |   Byte 1 = Cluster                                   |
>    |           |   Byte 0 = Member                                    |
>    |           | * For ITU International Full PC (3/8/3) w/byte 3=1.  |
>    |           |   These point codes use 14 bits (stored in the 14    |
>    |           |   least significant bits in bytes 0&1).  Byte 2 is   |
>    |           |   unused.  The 14 bits should be interpreted as 3    |
>    |           |   bits of zone, 8 bits of area and 3 bits of         |
>    |           |   signaling point identifier.  The 3 bits of         |
>    |           |   signaling point identifier are the 3 least         |
>    |           |   significant bits.                                  |
>    |           | * For ITU National Full PC w/byte 3=2. These point   |
>    |           |   codes use 14 bits (stored in the 14 least          |
>    |           |   significant bits in bytes 0&1).  Byte 2 is unused. |
>    |           |   The 14 bits represent a single 14-bit quantity that|
>    |           |   constitutes the point code.                        |
>    |           | * For unused w/byte 3=3.  Bytes 0 through 2 are      |
>    |           |   undefined.                                         |
>    |           | * For ANSI Cluster PC, w/byte 3=4.  These point codes|
>    |           |   are 24 bit point codes as follows:                 |
>    |           |   Byte 2 = Network                                   |
>    |           |   Byte 1 = Cluster                                   |
>    |           |   Byte 0 = 0. This field is ignored and should be    |
>    |           |   coded as 0...all members of the cluster are implied|
>    |           | * Byte 0 is the first byte that is transmitted across|
>    |           |   the wire, followed by byte 1, byte 2, then byte 3. |
>    +------------------------------------------------------------------+
> 
>    Note: Byte numbering is:
> 
>     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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |    Byte 3     |    Byte 2     |     Byte 1    |    Byte 0     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
> For M3UA and SUA, the first octet of the Point Code parameters could
> include a PC Type field (encoded as in the TALI spec) as well as the
> Mask field. Only 5 bits are actually needed for the mask.
> 
>     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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |               Tag             |           Length              |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | PC  |  Mask   |         Point code                            |
>    |Type |         |                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Regards,
> 
> Joyce

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---

From: Joyce Archibald <[email-masked]>
Date: Mon, 12 Mar 2001 09:26:58 +0000

Subject: Re: M3UA and SUA: Point Code formats
From: Joyce Archibald <[email-masked]>
To: Greg Sidebottom <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, [email-masked]
Date: Mon, 12 Mar 2001 09:23:05 +0000

Hi Greg & Brian,

It would be good if M3UA and SUA were AS monitorable as SS7 (not more).
SS7 only uses one protocol stack on each link, so a network monitor can
'know' what formats to use. However, (if I understand correctly) in M3UA
and SUA it is possible to merge a number of SS7 links, using different
protocols, onto one SCTP association, hence the need for a Network
Appearance parameter since each message could be different.

Could there ever be a scenario in which a single message could contain
different point code formats, whether in Routing Label, Affected PCs or
Source/Destination addresses? If not, then I guess my problem does
reduce to knowing how to interpret the Network Appearance parameter.

By the by, it is not necessary to use the same PC type encoding as TALI.
By all means, remove the ANSI Cluster PC and add a 16-bit Point Code.

Cheers,

Joyce
------------------------------------------------------

Greg Sidebottom wrote:
Hi Joyce,

My reading of the proposal (tell me if I missed the point though!) is
this
really only identifies the length of the point codes (14- or 24-bits) in
the
SSNM messages and how they are broken down into sub-fields for display
on
the analyzer.   It doesn't really tell you the SS7 protocol
version/variant
used, which the analyzer (and end-points) have to know anyway to
understand
the format of the Data message payload.  But once you know the SS7
protocol
version/variant used, I think you will then know both the Point Code
format
in the Routing Label and the Point Code format in the SSNM messages. 

covered.  The part on ANSI Cluster PC is already covered by the Mask
field

Regards,

      Greg