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

From: [email-masked]
Date: Thu, 8 May 2003 07:53:32 -0400

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,

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

HannsJuergen
> -----Ursprüngliche Nachricht-----
> 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
> Betreff: Re: [Sigtran] (M2PA) Comments on M2PA v8 - Last Call
>
>
> 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
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Gesendet: Donnerstag, 8. Mai 2003 01:10
> > > An: Tom George
> > > Cc: SIGTRAN e-mail list
> > > Betreff: Re: [Sigtran] (M2PA) Comments on M2PA v8 - Last Call
> > >
> > >
> > > Tom,
> > >
> > > 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.
> > > >
> > > >
> > > > Schwarzbauer Hanns Juergen wrote:
> > > > >
> > > > > Bidulock,
> > > > >
> > > > > 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:
> > > > > > > > >
> > > > > > > > > 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
> >
> > --
> > 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 ¦
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
>
> --
> 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 ¦
>
_______________________________________________
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: Tom George <[email-masked]>
Date: Thu, 08 May 2003 17:38:23 -0500

Given what has been said in this thread, I no longer want to add the
sentence to the definition of SG. 

tomG.

  [...]

-- 
* 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