Subject: AW: [Sigtran] (M2PA) Comments on M2PA v8 - Last Call

From: Schwarzbauer Hanns Juergen <[email-masked]>
Date: Wed, 7 May 2003 10:25:29 +0200

Tom,

see my comments below

greetings

HannsJuergen

> -----Ursprüngliche Nachricht-----
> Von: Tom George [mailto:[email-masked]]
> Gesendet: Dienstag, 6. Mai 2003 23:54
> An: SIGTRAN e-mail list
> Betreff: Re: [Sigtran] (M2PA) Comments on M2PA v8 - Last Call
> 
> 
> Hanns, Brian, and others,
> 
> Here is the definition of Signaling Gateway from RFC 2719 section 1.2.
> 
>    Signaling Gateway (SG):
> 
>    An SG is a signaling agent that receives/sends SCN native signaling
>    at the edge of the IP network. The SG function may relay, translate
>    or terminate SS7 signaling in an SS7-Internet Gateway. The SG
>    function may also be co-resident with the MG function to 
> process SCN
>    signaling associated with line or trunk terminations controlled by
>    the MG (e.g., signaling backhaul).
> 
> As I read this, an agent does not have to transfer messages 
> between the
> SCN and IP networks to be called an SG. That may seem a bit odd for
> something called a "gateway", but that is what it says. 
> 
> So when I used this term in the M2PA draft, I just said that 
> an SG is an
> SP with both traditional and IP links. If such an SG transfers SS7
> messages between a node on the TDM network and a node on the 
> IP network,
> it is an STP. 

[HJS] that's excatly what I'm saying

> But then, if it transfers messages between two nodes on
> the IP network, it is an STP.

[HJS] Regarding the transfer between two nodes in the IP network I see no SG functionality in the IPSP.
However, if you want to avoid provisioning a fully meshed SS7 network between your IPSP's by introducing a purely IP based STP, this STP is no SG, because you are not changing layer below MTP3.

> 
> But I don't see the significance of this issue. 
> 
> tomG.
> 
> "Brian F. G. Bidulock" wrote:
>   [...]
> > > > > Comment on section 1.2:
> > > > >
> > > > > definition of "Signaling Gateway": current text is "SG is
> > > > an SS7 Signaling
> > > > > Point". It should be clarified to read "SG is an SS7
> > > > Signaling Transfer
> > > > > Point". See e.g. the text below figure 1.
> > > >
> > > > The SG in Figure 2 is not necessarily an STP.  It could be an
> > > > SEP connected
> > > > directly to the SEP and IPSP via F-links and the SG does not
> > > > need to have
> > > > the transfer function to satisfy the configuration shown in
> > > > the diagram.
> > > > Usage of the general term SP (which includes SEP and STP) is
> > > > appropriate.
> > >
> > > [HJS] It could not be called an SEP, because the messages 
> the SG receives
> > > are not addressed to its point code, but to the IpS'P's 
> point code, so it's
> > > an STP. Even the required transfer functionality is small.
> > 
> > The diagram does not show the IPSP's communicating with each other
> > via the SG at the MTP level.  It is therefore not necessary that the
> > SG relay at MTP level 3 and it is not necessarily an STP.  It could
> > be an SS7 mediation box peforming relay above MTP3 only, or it could
> > simply be a switch which does not permit SS7 message to pass between
> > another switch and the MGC.  It could be a G-MSC connected to an MSC
> > and an MGC.  It does not need the transfer function in any of these
> > circumstances.  Therefore it could be an SEP and not an STP and the
> > term SP is appropriate in the draft.
>   [...]
> 
> -- 
> * Tom George       PB7-24001 (near B-21)      
> [email-masked]  *
> * 972-519-3168   Intranet:  
http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel;  3400 West Plano Pkwy,  MS PB7-SWPRO;  Plano, Texas 75075  *
* I actively disclaim speaking for Alcatel USA, Inc. I do not purport *
* to advertise or represent its position,  operations, or activities. *
_______________________________________________
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: Schwarzbauer Hanns Juergen <[email-masked]>
Date: Wed, 7 May 2003 13:09:01 +0200

Hi Tolga,

so we should rise the question what is shown in figure 11 in RFC2719 at all?
In case we include MTP3 in both SG's we definitly have the M2PA scenario.

greetings

HannsJuergen

> Von: Tolga Asveren [mailto:[email-masked]]
> Gesendet: Mittwoch, 7. Mai 2003 12:35
> An: [email-masked]
> Betreff: Re: AW: AW: [Sigtran] (M2PA) Comments on M2PA v8 - Last Call
> 
> 
> Hi HannsJuergen and all,
> 
> Although not directly related with the main
> discussions of this thread, still just my
> opinion/question about Figure11 in RFC2719:
> I don't know, whether it is really possible to make
> work what it stands in that figure. Terminating Layer2
> on a node with no corresponding Layer3 logic sounds
> strange to me. In Figure11, there are two MTP2s with
> no corresponding MTP3. For example how can one be sure
> that a message sent by MTP3 of a SEP is delivered to
> the MTP3 of the other SEP? Based on figure11, I would
> expect the closest MTP2 acknowledge MTP2 of the sender
> SEP as soon as it receives the message successfully.
> So, I wouldn't think figure11 represents a layer2
> tunneling solution.
> 
>     Tolga
> --- Schwarzbauer Hanns Juergen
> <[email-masked]> wrote:
> > Ken, Tom
> > 
> > taking figure 11 literally, you have no need at all
> > to assign SS7 point codes to the SG's. An other
> > consequence is that this SG does not act as an STP,
> > as there is a strict 1-to-1 relation between TDM and
> > "IP" link.
> > 
> > I think that there is no protocol at all currently
> > defined by SIGTRAN dealing with exactly that
> > scenario.
> > 
> > However, I know that there are some proprietary
> > "MTP2 Tunneling" protocols deployed. It's nothing
> > but a clever "layer two tunneling" with removal of
> > redundant FISUs.
> > 
> > greetings
> > 
> > HannsJuergen
> > 
> > 
> > > Von: Ken Morneault [mailto:[email-masked]]
> > > Gesendet: Dienstag, 6. Mai 2003 22:10
> > > An: Tom George; SIGTRAN e-mail list
> > > Betreff: Re: AW: [Sigtran] (M2PA) Comments on M2PA
> > v8 - Last Call
> > > 
> > > 
> > > 
> > > 
> > > Though incorrectly drawn for M2PA, I believe
> > Figure 11 shows 
> > > the intent to
> > > create a protocol like M2PA so it would be ok to
> > reference RFC2719.
> > > 
> > > Ken
> > > 
> > > At 02:27 PM 5/6/2003 -0500, Tom George wrote:
> > > >Brian and Hanns,
> > > >
> > > >I think the SG in RFC2719 Figure 7 also
> > qualifies.
> > > >
> > > >tomG.
> > > >
> > > >
> > > >Schwarzbauer Hanns Juergen wrote:
> > > >> 
> > > >> Bidulock,
> > > >> 
> > > >> see my comments below.
> > > >> 
> > > >> greetings
> > > >> 
> > > >> HannsJuergen
> > > >  [...]
> > > >> > > Comment on section 1.5:
> > > >> > >
> > > >> > > RFC2719 does NOT show a scenario related to
> > M2PA. At the
> > > >> > time this RFC was
> > > >> > > written, M2PA wasn't a Sigtran WI.
> > Therefore I doubt the
> > > >> > usefulness of this
> > > >> > > reference.
> > > >> >
> > > >> > RFC2719 Figure 10 in Section 3.5 shows just
> > such a scenario
> > > >> > and the reference
> > > >> > is valid.
> > > >> 
> > > >> (HJS] disagree, figure 10 shows a scenario
> > using first 
> > > M2UA towards SG2 and M3ua to the MGC
> > > >> The MGC is not shown having MTP3 functionality
> > as required by M2PA.
> > > >  [...]
> > > >
> > > >-- 
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo.
> http://search.yahoo.com

---

From: Schwarzbauer Hanns Juergen <[email-masked]>
Date: Thu, 8 May 2003 12:10:41 +0200

Brian,

as this is an architectural discussion issue, I would like to see the views of other SIGTRANers...
(assuming that there are some left)

HannsJuergen
> Von: Brian F. G. Bidulock [mailto:[email-masked]]
> Gesendet: Donnerstag, 8. Mai 2003 11:45
> An: Schwarzbauer Hanns Juergen
> Cc: Tom George; SIGTRAN e-mail list
> Hanns,
> On Thu, 08 May 2003, Schwarzbauer Hanns Juergen wrote:
> 
> > Bidulock,
> > 
> > I disagree with your explanations below.
> > Right from the start M2PA was intented to be a replacement 
> for conventional MTP2 and nothing else.
> > 
> > The functionality of an SG of course differs between the 
> various adaptation layers.
> > 
> > An M2PA link could NEVER be attached to an SG providing 
> only the M2UA functionality as you state below.
> > M2PA ALWAYS requires MTP3 on top of it.
> 
> Wrong.
> 
> --brian
> 
> > 
> > greetings
> > 
> > HannsJuergen
> > 
> > > Von: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Gesendet: Donnerstag, 8. Mai 2003 01:10
> > > An: Tom George
> > > Cc: SIGTRAN e-mail list
> > > The main reason for not saying so is that being able to 
> > > transfer messages
> > > does not make the SG and STP.  You would have to make 
> reference to the
> > > "transfer function" of Q.704.  Which of course is outside the 
> > > scope of M2PA
> > > anyways, but is implied by "Signalling Point".  A signalling 
> > > point with the
> > > transfer function is an STP, a signalling point without the 
> > > transfer function
> > > is an SEP.  To be able to transfer message does not even 
> > > require an MTP3
> > > to be present, far less requiring the transfer function to be 
> > > present in an
> > > MTP3.  Refer to Figure 1/Q.700.  A signalling point can have 
> > > a user function,
> > > a transfer function, or both or might be just a signalling 
> > > point where it is
> > > irrelevant whether a user or transfer function is present.
> > > 
> > > In the case of an SG, not only is it irrelevant whether a 
> > > user or transfer
> > > function is present, but it is irrelevant whether it is even 
> > > a signalling
> > > point. (To be a signalling point which is an MTP3 entity, it 
> > > must have a
> > > signalling point code and contain an MTP3.)  It has always 
> > > been clear in
> > > the architecture that an M2PA could be attached to an M2UA SG 
> > > which then
> > > communicates with an MGC, similar to that shown in RFC 
> 2719 Figure 11.
> > > And--case in point---the M2UA SG has no point code, is not a 
> > > signalling point,
> > > and has neither user nor transfer function; yet it is 
> called an SG.
> > > 
> > > So, no, I would disagree with adding such statement, because 
> > > it confuses
> > > the matter with redundant statements rather than adding 
> any clarity.
> > > 
> > > --brian
> > > 
> > > On Wed, 07 May 2003, Tom George wrote:
> > > 
> > > > Hanns and Brian,
> > > > 
> > > > May I propose the following addition to the definition 
> of SG in 1.2?
> > > > 
> > > > Signaling Gateway (SG) - A signaling agent that 
> receives/sends SCN
> > > > native signaling at the edge of the IP network 
> [RFC2719]. In this
> > > > context, an SG is an SS7 Signaling Point that has both 
> an IP network
> > > > connection used for SS7 over IP, and a traditional (non-IP) 
> > > link to an
> > > > SS7 network. ***If the SG is able to transfer messages 
> > > between nodes on
> > > > the SCN and nodes on the IP network, the SG is also an STP.***
> > > > 
> > > > tomG.
> > > > 
> > > > 
> > > > > if you are sending an SS7 message destined to an SS7 node 
> > > having point
> > > > > code 2 via a node having point code 1, this node is to be 
> > > called an STP
> > > > > and not an SEP. Therefore using the generic term SP hides 
> > > the consequences
> > > > > for e.g. an node inbetween the SEP and the SG.
> > > > > 
> > > > > Doing the magic you are talking about needs to tell the 
> > > STP in front of
> > > > > the SG that the SG is e.g. an A-link consolidator, 
> > > capable receiving
> > > > > messages having point codes other than his own.
> > > > > 
> > > > > consequently I insist on having this clarification 
> included in the
> > > > > definition of an SG
> > > > > 
> > > > > greetings
> > > > > 
> > > > > HannsJuergen
> > > > > 
> > > >   [...]
> > > > > > > > > Comment on section 1.2:
> > > > > > > > >
> > 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 ¦
> 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: "TOLGA ASVEREN" <[email-masked]>
Date: Thu, 8 May 2003 17:43:33 +0300

I fully agree that each M2PA (or MTP2) needs a corresponding MTP3 entity.
But I think what Brian was referring to when he said that an SG can have a
M2PA and no MTP3 was to use M2UA on that SG so that M2PA and the
corresponding MTP3 are on different nodes (IMO which is similar to the
relationship between SG and MGC in Figure1 of RFC3331 -just replace MTP2
with M2PA- rather than Figure11 of RFC2719)

     Tolga

Brian,

as this is an architectural discussion issue, I would like to see the views
of other SIGTRANers...
(assuming that there are some left)

HannsJuergen

---

From: Schwarzbauer Hanns Juergen <[email-masked]>
Date: Thu, 8 May 2003 16:53:59 +0200

Jeff,

the problem seems to be "what's an STP"

in my understanding, an STP is a node having a unique SS7 point code with the ability to pass on received SS7 messages sent to an SS7 point code not matching his SS7 point code.

If you say that tha SG in Figure 2 has no STP functionality, then the SG and the IPSP would have to have the same SS7 point code. But in this case there must be no MTP3 on the SG and you would end up with the M2UA scenario.

Right from the definition of M2PA as a replacement for MTP2 I always assume that an SG using M2PA has a point code of its own. This is the reason why I insist on the fact that for M2PA an SG is an STP.

BTW, also in case of Figure 9 I consider IPSP X to be an STP for reasons described above.

greetings

HannsJuergen

> Von: [email-masked] [mailto:[email-masked]]
> Gesendet: Donnerstag, 8. Mai 2003 13:54
> Cc: [email-masked]'; SIGTRAN e-mail list; Tom George
> Betreff: Re: AW: [Sigtran] (M2PA) Comments on M2PA v8 - Last Call
> 
> 
> 
> Hello Hanns,
> 
> Quoting from the thread:
> "The SG in Figure 2 is not necessarily an STP.  It
> could be a SEP connected directly to the SEP and
> IPSP via F-links and the SG does not need to have
> the transfer function to satisfy the configuration
> shown in the diagram."
> 
> I agree with Brian in this case.
> 
> The term 'signaling point' is appropriate in the context
> of the discussion. Perhaps you can better explain why
> you see the use of 'STP' vs. 'SP' in the examples as a
> significant interoperability issue.
> 
> Regards,
> 
> Jeff
> 
> 
> 
>                                                               
>                                                               
>                   
>                       Schwarzbauer Hanns Juergen              
>                                                               
>                   
>                       <hannsjuergen.schwarzbauer@s         
> To:      "[email-masked]'" <[email-masked]>      
>                      
>                       iemens.com>                          
> cc:      Tom George <[email-masked]>, SIGTRAN e-mail 
> list                  
>                       Sent by:                             
> <[email-masked]>                                            
>                      
>                       [email-masked]               
> Subject: AW: [Sigtran] (M2PA) Comments on M2PA v8 - Last Call 
>                      
>                                                               
>                                                               
>                   
>                                                               
>                                                               
>                   
>                       05/08/03 06:10 AM                       
>                                                               
>                   
>                                                               
>                                                               
>                   
>                                                               
>                                                               
>                   
> 
> 
> 
> 
> Brian,
>

---

From: Schwarzbauer Hanns Juergen <[email-masked]>
Date: Fri, 9 May 2003 09:48:29 +0200

Tolga,

I don't see the possibility to have M2PA on an SG without an MTP3 directly on top of it (on the same SG)

The figure below shows a typical M2UA scenario
  SEP                     SG                        IPSP
+-------+                                        +-------+
|  ISUP |                                        |  ISUP |
|       |                                        |       |
+-------+                                        +-------+
|  MTP3 |          +---------------+             |  MTP3 |
|       |          |      NIF      |             |       |
+-------+          +-------+-------+             +-------+
|  MTP2 |          |  MTP2 |  M2UA |             |  M2UA |
|       |          |       |       |             |       |
+-------+          +-------+-------+             +-------+
|  MTP1 |          |  MTP1 |  SCTP |             |  SCTP |
|       |          |       |       |             |       |
+-------+          +-------+-------+             +-------+
                           |  IP   |             |  IP   |
                           |       |             |       |
                           +-------+             +-------+
Now I'm introducing M2PA at the SEP (so it has to be renamed to IPSP) and in the SG

  IPSP                    SG                        IPSP
+-------+                                        +-------+
|  ISUP |                                        |  ISUP |
|       |                                        |       |
+-------+                                        +-------+
|  MTP3 |          +---------------+             |  MTP3 |
|       |          |      NIF      |             |       |
+-------+          +-------+-------+             +-------+
|  M2PA |          |  M2PA |  M2UA |             |  M2UA |
|       |          |       |       |             |       |
+-------+          +-------+-------+             +-------+
|  SCTP |          |  SCTP |  SCTP |             |  SCTP |
|       |          |       |       |             |       |
+-------+          +-------+-------+             +-------+
|   IP  |          |    IP |  IP   |             |  IP   |
|       |          |       |       |             |       |
+-------+          +-------+-------+             +-------+

But I don't consider this as a supported configuration according to the current M2PA draft.

In my opinion such a scenario was not considered up to now, nor described in M2PA.
But nevertheless I'm open for discussion.

greetings

HannsJuergen

> Von: TOLGA ASVEREN [mailto:[email-masked]]
> Gesendet: Donnerstag, 8. Mai 2003 16:44
> An: [email-masked]

---

From: "TOLGA ASVEREN" <[email-masked]>
Date: Fri, 9 May 2003 13:48:34 +0300

HannsJuergen,

As far as I understand Figure2 in your message corresponds to what Brian
was thinking -or better said my understanding of what he was thinking based
on his message-. I don't know whether this is a usefull configuration from
operation point of view but given that MTP3/MTP2 interface is retained by
M2PA, IMO from pure protocol point of view, Figure2 is supported -or at
least is possible- by M2PA.

    Tolga

Tolga,

I don't see the possibility to have M2PA on an SG without an MTP3 directly
on top of it (on the same SG)

Now I'm introducing M2PA at the SEP (so it has to be renamed to IPSP) and
in the SG

  IPSP                    SG                        IPSP
+-------+                                        +-------+
|  ISUP |                                        |  ISUP |
|       |                                        |       |
+-------+                                        +-------+

But I don't consider this as a supported configuration according to the
current M2PA draft.

In my opinion such a scenario was not considered up to now, nor described
in M2PA.
But nevertheless I'm open for discussion.

greetings

HannsJuergen

---

From: Schwarzbauer Hanns Juergen <[email-masked]>
Date: Fri, 9 May 2003 14:27:09 +0200

Tolga,

indeed, it really depends on what functionality do you need to have in the "NIF".
Especially whether this "NIF" needs to have a unique SS7 point code and again converts into an MTP3, albeit with very rudimentary functionality.

I agree that the second figure needs more discussion.

greetings

HannsJuergen

> Gesendet: Freitag, 9. Mai 2003 12:49
> An: [email-masked]

---

From: Schwarzbauer Hanns Juergen <[email-masked]>
Date: Mon, 12 May 2003 09:49:57 +0200

Tom,

having the proving procedure as RECOMMENDED only, we have to think about interoperability issues:
We should clearly specify the procedures to be followed on the receiving side when proving is detected:
-	support the partner node in this procedure?
-	just ignore these messages?
and correspondingly what to do on the sending side if we opt to silently discard the proving messages at the receiving side.

greetings

HannsJuergen

> Gesendet: Freitag, 9. Mai 2003 23:25
> An: SIGTRAN e-mail list
> IMHO "RECOMMENDED" allows for that. 
> 
> tomG.
> 
> > Q.2210 permits proving to be skipped altogether under maintenance
> > directive.
> > 
> > Where the grade of service of the underlying transport is known
> > to be sufficient, proving can be foregone.
> > 
> > M2PA should also permit proving to be skipped altogether.
> > 
> > --brian
> > 
> > On Fri, 09 May 2003, Tom George wrote:
> > 
> > > Hanns,
> > >
> > > That makes sense. Let me try again, using your phraseology:
> > >
> > > During the proving period (i.e., after M2PA starts the 
> proving period
> > > timer T4), M2PA SHALL send Link Status Proving messages 
> to its peer at
> > > an interval defined by the protocol parameter 
> Proving_Interval. ***It is
> > > RECOMMENDED that Proving_Interval be set so that the traffic load
> > > generated with the Link Status Proving messages during the proving
> > > period is comparable to the normal traffic load expected 
> when the link
> > > is in service.***
> > >
> > >
> > >
> > > > I don't consider it a good idea to leave this value 
> implementation dependent.
> > > > That's because the original intention (that's at least 
> my understanding of Q.703) was to generate sufficient traffic 
> to see 1) whether the peer is able to handle the traffic and
> > > > 2) the number of transmission errors is sufficiently small.
> > > > Now assume the value of "Proving_Interval" set to the 
> value of the T4 timer: only a single message would be sent 
> out invalidating IMHO the whole proving procedure built into M2PA.
> > > >
> > > > My proposal is to state that the traffic load generated 
> with the Link Status Proving messages during the proving 
> period is comparable to the normal traffic load that is 
> expected when the M2PA link is in service.
> > > > Not doing this, but recommending that the size of this 
> messages is similiar to the size of the User Data messages is 
> stopping halfway towards a clean solution.
> > > > In my understanding this the only chance to learn about 
> the current QoS of the used IP network. It's of course no 
> garuantee for a long term QoS as in the TDM world.
> > > >
> > > > greetings
> > > >
> > > > HannsJuergen
> > > >
> > > > > Gesendet: Freitag, 9. Mai 2003 00:14
> > > > > Cc: SIGTRAN e-mail list
> > > > > I should be able to improve the wording. I want the messages
> > > > > to be sent
> > > > > periodically, but I do not want to specify the interval.
> > > > > Maybe I should
> > > > > add this:
> > > > >
> > > > > During the proving period (i.e., after M2PA starts 
> the proving period
> > > > > timer T4), M2PA SHALL send Link Status Proving 
> messages to its peer at
> > > > > an interval defined by the protocol parameter 
> Proving_Interval. ***The
> > > > > value of Proving_Interval is implementation dependent.***
> > > > >
> > > > > tomG.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > Dear all,
> > > > > > another finding in the draft 8:
> > > > > >
> > > > > > Section 4.1.3 last but one para refers to a protocol
> > > > > parameter called "Proving_Interval".
> > > > > >
> > > > > > But no value is assigned to it throughout the document.
> > > > > >
> > > > > > greetings
> > > > > >
> > > > > > HannsJuergen