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

From: "Bep Verberk"<[email-masked]>
Date: Fri, 17 May 2002 12:10:51 -0400

Jeffrey,
I believe the m2pa mode of operation is intended to mimick
an MTP2 based link in which the NA is fixed and defined by the
m2pa association itself. That is, it does not vary for messages
within the m2pa association.

In an gateway application where translation is done from one network
to another, messages would netr the system on an m2pa association
(NA=X) be translated/converted at a higher layer in the ss7 protocol
and sent out a different m2pa association (NA=Y).

So I don't see why the NA info is required in the m2pa message.

Bep

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, May 17, 2002 11:47 AM
> To: [email-masked]
> Subject: [Sigtran] (M2PA) Please add a Network Appearance parameter to
> the M2PA protocol
> 
> 
> 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: [email-masked]
Date: Fri, 17 May 2002 16:40:11 -0400

Hello Bep,

There is a real world problem that I am trying to solve, and I believe
Network Appearance
is the answer. Here follows an example that I hope will explain.

Example ITU-N Network to discuss M2PA and Network Appearance.

'FR' is France
'GB' is Great Britain
'GE' is Germany

ITU-N Network Implementation with M2PA lacking Network Appearance.
Nodes reside in different nations having identical ITU-N point codes.

The SGs must support multiple self-identities in order to host multiple
linksets, each linkset is assigned to a particular national group.

This configuration has inefficient B-link utilization.
This configuration requires more point codes.

+--------+                                                    +--------+
|  SP    |                                                    |  SP    |
|        |                                                    |        |
| 200-GE +---+                                            +---+ 200-GB |
|        |   |                                            |   |        |
+--------+   |                  B-links                   |   +--------+
             | ITU-N+--------+            +--------+ITU-N |
             +------+   SG1  | linkset X  |   SG2  +------+
                    | 100-FR +------------+ 110-FR |
                    |        | linkset Y  |        |
                    | 101-GB +------------+ 111-GB |
                    |        | linkset Z  |        |
                    | 102-GE +------------+ 112-GE |
               ITU-N|        |            |        |ITU-N
             +------+        |  (M2PA)    |        +------+
+--------+   |      +--------+            +--------+      |   +--------+
|  SP    |   |                                            |   |  SP    |
|        |   |                                            |   |        |
+ 201-GE +---+                                            +---+ 200-FR |
|        |                                                    |        |
+--------+                                                    +--------+

ITU-N Network Implementation with M2PA having Network Appearance.
Nodes reside in different nations having identical ITU-N point codes.

M2PA Network Appearance allows SG1 to convey national network group
information to SG2 and vice versa, thereby providing for identical
ITU-N point codes to be uniquely identified without the need for
multiple linksets between SG1 and SG2.

This configuration provides efficient B-link utilization.
This configuration requires fewer point codes.

+--------+                                                    +--------+
|  SP    |                                                    |  SP    |
|        |                                                    |        |
| 200-GR +---+                                            +---+ 200-GB |
|        |   |                                            |   |        |
+--------+   |                                            |   +--------+
             | ITU-N+--------+            +--------+ITU-N |
             +------+   SG1  | linkset X  |   SG2  +------+
                    |        +------------+        |
               ITU-N| 100-FR |  B-links   | 110-FR |ITU-N
             +------+        |  (M2PA)    |        +------+
+--------+   |      +--------+            +--------+      |   +--------+
|  SP    |   |                                            |   |  SP    |
|        |   |                                            |   |        |
+ 201-GR +---+                                            +---+ 200-FR |
|        |                                                    |        |
+--------+                                                    +--------+

Regards,

Jeff

"Bep Verberk"<[email-masked]>@ietf.org on 05/17/2002 12:10:51
PM

Sent by:  [email-masked]

To:   "[email-masked]'" <[email-masked]>,
      [email-masked]
cc:
Subject:  RE: [Sigtran] (M2PA) Please add a Network Appearance parameter to
       the M2PA protocol

Jeffrey,

Bep

---

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

Jeffrey,

This scenario is already addressed today in SS7 by using an
internation gateway SP or STP.  M2PA is not intended to replace
any SP behavior whatsoever: it merely provides a way to move
SS7 MTP2 peer-to-peer over IP.  It is a signalling link and
nothing more.  M2PA does not "own" a point code.  Only the MTP3
layer above it does.

The M3UA SG-SG draft, on the other hand, permits the SG to
exhibit the transfer function.  In which case you have:

 +--------+                                                    +--------+
 |  SP    |                                                    |  SP    |
 |        |                                                    |        |
 | 200-GE +---+                                            +---+ 200-GB |
 |        |   |                                            |   |        |
 +--------+   |                                            |   +--------+
              | ITU-N+--------+            +--------+ITU-N |
              +------+   SG1  |            |   SG2  +------+
                     | 100-FR |            | 110-FR |
                     |        | association|        |
                     | 101-GB +------------+ 111-GB |
                     |        |  (M3PA)    |        |
                     | 102-GE | M3UA SG-SG | 112-GE |
                ITU-N|        |            |        |ITU-N
              +------+        |            |        +------+
 +--------+   |      +--------+            +--------+      |   +--------+
 |  SP    |   |                                            |   |  SP    |
 |        |   |                                            |   |        |
 + 201-GE +---+                                            +---+ 200-FR |
 |        |                                                    |        |
 +--------+                                                    +--------+

I suggest that you consider the M3UA SG-SG (M3PA) draft instead
of expecting M2PA to be expanded to meet your needs here.

--brian

On Fri, 17 May 2002, [email-masked] wrote:

> Hello Brian,

> "Brian F. G. Bidulock" <[email-masked]>@ietf.org on 05/17/2002
> 03:14:55 PM
> 
> Please respond to [email-masked]
> 
> To:   [email-masked]
> cc:   [email-masked]
> Subject:  Re: [Sigtran] (M2PA) Please add a Network Appearance parameter to
>       the M2PA protocol
> 
> 
> 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)
> > Hello All,
> >
> > 2) Add it as an optional parameter to User Data messages, meaning that
> the
> > user data
> > 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
> > 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
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/

-- 
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: [email-masked]
Date: Tue, 28 May 2002 15:05:24 -0400

Hello Brian,

>M3UA SG-SG has Network Appearance.
>Use it instead of mangling M2PA.

Bummer of an answer. 'mangling'?

So the goal of M2PA is to offer nothing more, or less, than that provided
by MTP2?

I know this discussion is not going anywhere, but.....

I happen to have a MTP3 layer that is aware of multiple ITU-N networks.
I need a means to convey that information across B,C,D SS7-over-IP links.
You argue that this functionality is L3-based and does not belong in L2
(M2PA).
Unfortunately, the MTP3 message payload is fixed. The M2PA message
payload is not yet fixed, but strictly defines the mapping of MSUs. The
M2PA protocol is not very extensible, except in terms of new message types.

M3UA SG-SG is not a good choice for my implementation:
1) I have no need for routing key registration or of application servers.
2) I have no need for elaborate conversions of SS7 SNMs and MSUs.
3) I have no need to use multiple SCTP streams for user data.

So I am left with adding a custom message type to M2PA or using reserved
bits.
Okee dokee.

Regards,

Jeff

"Brian F. G. Bidulock" <[email-masked]> on 05/20/2002 08:49:18 AM

Jeffrey,

M3UA SG-SG has Network Appearance.

Use it instead of mangling M2PA.

--brian

[email-masked] wrote:                    (Mon, 20 May 2002
08:40:18)
>
> Hello Brian,
>
> The scenario is addressed inefficiently by international gateway SP or
STP.
>
> I need to solve the problem using M2PA.
>
> The MTP3 payload is strictly defined and does not provide for a solution.
> M2PA is extending the MTP3 weakness by also not providing for a solution.
>
> Perhaps the reserved bits of the M2PA FSN and BSN fields can be used
> as Network Appearance.
>
> Regards,
>
> Jeff
>
>
>
>
> "Brian F. G. Bidulock" <[email-masked]> on 05/17/2002 05:01:27 PM
>
> nothing more.
> > +--------+
+--------+
> > |  SP    |                                                    |  SP
|
> > |        |                                                    |
|
> > |        |   |                                            |   |
|
> > +--------+   |                                            |
+--------+
> > |  SP    |   |                                            |   |  SP
|
> > |        |   |                                            |   |
|
> > |        |                                                    |
|
> > +--------+
+--------+
> >
>
> I think you should consider the M3UA SG-SG (M3PA) draft instead
> of expecting M2PA to meet you needs.
>
> --brian
>
>
> > +--------+
+--------+
> > |  SP    |                                                    |  SP
|
> > |        |                                                    |
|
> > |        |   |                                            |   |
|
> > |  SP    |   |                                            |   |  SP
|
> > |        |   |                                            |   |
|
> > |        |                                                    |
|
> > +--------+
+--------+
> > +--------+
+--------+
> > |  SP    |                                                    |  SP
|
> > |        |                                                    |
|
> > |        |   |                                            |   |
|
> > +--------+   |                                            |
+--------+
> > |  SP    |   |                                            |   |  SP
|
> > |        |   |                                            |   |
|
> > |        |                                                    |
|
> > +--------+
+--------+
> > Subject:  Re: [Sigtran] (M2PA) Please add a Network Appearance
parameter
> to

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

---

From: "Bep Verberk" <[email-masked]>
Date: Tue, 28 May 2002 15:20:33 -0400

This is getting at the heart of my question to Brian about the
value of using M3UA for SG-SG versus just m2pa.

This a valid plus for M3UA, that is you can send traffic
for more than one network over the same association.

Of course Jeff points out that he doesn't like/need some
of the other aspects of m3ua for SG-SG.

So it becomes a trade off Jeff.
You need to either 
1. use muliple m2pa associations -  each
carrying traffic for different networks
(I don't think this is so bad)

2. Use m3ua 

3. Do something proprietary like you are proposing. If you
do this please share your ideas with us :)

Bep 

> Sent: Tuesday, May 28, 2002 3:05 PM
> To: [email-masked]
> Cc: [email-masked]
> to the M2PA protocol
> > Subject:  Re: [Sigtran] (M2PA) Please add a Network 
> Appearance parameter
> to
> >       the M2PA protocol
> >
> >
> > Jeffrey,
> >
> > > |  SP    |                                                
>     |  SP
> > > | 200-GE +---+                                            
> +---+ 200-GB
> > > |  SP    |   |                                            
> |   |  SP
> > > + 201-GE +---+                                            
> +---+ 200-FR
> > > |  SP    |                                                
>     |  SP
> > > | 200-GE +---+                                            
> +---+ 200-GB
> > > |  SP    |   |                                            
> |   |  SP
> > > + 201-GE +---+                                            
> +---+ 200-FR
> > > |  SP    |                                                
>     |  SP
> > > | 200-GR +---+                                            
> +---+ 200-GB
> > > |  SP    |   |                                            
> |   |  SP
> > > + 201-GR +---+                                            
> +---+ 200-FR
> > > > 2) Add it as an optional parameter to User Data 
> messages, meaning
> that
> > > the
> > > > user data
> > > > per message, even if network appearance is not 
> required. This option
> is
> > > > simple to encode/decode.
> > > >
> > > > Option #1:
> > > >
> > > >     0                   1                   2           
>         3
> > > >    |                        Message Length              
> > > >    |    Spare      |                     BSN            
> > > >    |    Spare      |                     FSN            
> > > >    |                       Network Appearance           
> > > >    \                               :                    
>            \
> > > >    /   SIF...                      :                    
>            /
> > > >    \                               :                    
>            \
> > > > It also adds complexity to the encode/decode for User 
> Data messages,
> > and
> > > > adds overhead
> > > >     0                   1                   2           
>         3
> > > >    |                        Message Length              
> > > >    |    Spare      |                     BSN            
> > > >    |    Spare      |                     FSN            
> > > >    |         Tag = NA              |          Length = 
> 8           |
> > > >    |                       Network Appearance           
> > > >    \                               :                    
>            \
> > > >    /   SIF...                      :                    
>            /
> > > >    \                               :                    
>            \

---

From: "Bep Verberk" <[email-masked]>
Date: Wed, 29 May 2002 12:14:18 -0400

snip...

>> I don't think they really want m3ua either, nor should they 
>> use a SGP-ASP protocol. They need a point to point 
>> IPSP - IPSP protocol based on SUA or TUA.  

>[TOLGA] Why do you think, a properly defined M3UA IPSP won't serve the same

>purpose? 

[BEP]It will, but it requires the nodes to also implement SCCP.
SUA would allow the elimination of SCCP on the IP nodes.