Subject: [Sigtran] (M2PA) Please add a Network Appearance parameter to the M2PA protocol

From: [email-masked]
Date: Fri, 17 May 2002 11:46:49 -0400

Hello All,

I propose that Network Appearance information be added to the M2PA
protocol for use in User Data messages. This data would have the same
function as described in the M3UA (v12) draft for Network Appearance:

   "The Network Appearance parameter identifies the SS7 network
   context for the message and implicitly identifies the SS7
   Point Code format used, the SS7 Network Indicator value, and the
   MTP3 and possibly the MTP3-User protocol type/variant/version used
   within the specific SS7 network.  Where an SG operates in the
   context of a single SS7 network, or individual SCTP associations
   are dedicated to each SS7 network context, the Network Appearance
   parameter is not required.  In other cases the parameter may be
   configured to be present for the use of the receiver."

This would allow M2PA to be used in international signaling gateway
deployments
involving multiple national networks.

Two options for adding Network Appearance are:
1) Add it as a new field in the M2PA header.
2) Add it as an optional parameter to User Data messages, meaning that the
user data
     must become another parameter.

The first option has the draw-back of using 4-bytes (or some other number)
of overhead
per message, even if network appearance is not required. This option is
simple to encode/decode.

Option #1:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    |     Spare     | Message Class | Message Type  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Message Length                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Spare      |                     BSN                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Spare      |                     FSN                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Network Appearance                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |PRI|   spare   |      SIO      |              SIF...           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                               :                               \
   /   SIF...                      :                               /
   \                               :                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The second option allows for Network Appearance to be optionally included
in the message.
It also adds complexity to the encode/decode for User Data messages, and
adds overhead
bytes by making the user data a parameter having a new header.

Option #2:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    |     Spare     | Message Class | Message Type  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Message Length                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Spare      |                     BSN                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Spare      |                     FSN                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag = NA              |          Length = 8           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Network Appearance                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag = User Data       |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |PRI|   spare   |      SIO      |              SIF...           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                               :                               \
   /   SIF...                      :                               /
   \                               :                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Regards,

Jeff

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 17 May 2002 14:14:55 -0500

Jeffrey,

Network context is already contained in the NI bits in the
Routing Label contained within the User Data in M2PA.  There
is no need for an NA parameter.  MTP3 has all the information
which is normally contained in an MSU from MTP2 and, as such
can completely support SS7 using M2PA without the addition of
an NA parameter.

In general M2PA is no different than SS7 MTP2: to support
multiple national networks requires multiple M2PA "links".
An M2PA association is not even able to support linksets
(it can only support one link).

You should take a look at Tolga's SG-SG draft.  This is probably
more what you are looking for in transport messages for multiple
networks.  An M3PA, if you will, is far better suited for
transporting peer-to-peer traffic for multiple networks at the
MTP3 level (which knows about network apprearances and such).

--brian

[email-masked] wrote:                    (Fri, 17 May 2002 11:46:49)

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