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

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

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

> -----Ursprüngliche Nachricht-----
> Von: Brian F. G. Bidulock [mailto:[email-masked]]
> Gesendet: Dienstag, 6. Mai 2003 22:22
> An: Schwarzbauer Hanns Juergen
> Cc: List: IETF sigtran (E-Mail)
> Betreff: Re: [Sigtran] (M2PA) Comments on M2PA v8 - Last Call
> 
> 
> Schwarzbauer,
> 
> Please see comments below...
> 
> Schwarzbauer Hanns Juergen wrote:                             
>                 (Tue, 06 May 2003 17:49:40)
> > Bidulock,
> > 
> > see my comments below. 
> > 
> > greetings
> > 
> > HannsJuergen
> > 
> > > -----Ursprüngliche Nachricht-----
> > > Von: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Gesendet: Dienstag, 6. Mai 2003 13:03
> > > An: Schwarzbauer Hanns Juergen
> > > Cc: List: IETF sigtran (E-Mail)
> > > Betreff: Re: [Sigtran] (M2PA) Comments on M2PA v8 - Last Call
> > > 
> > > 
> > > Schwarzbauer,
> > > 
> > > Schwarzbauer Hanns Juergen wrote:                             
> > >                 (Tue, 06 May 2003 12:12:11)
> > > > Dear all,
> > > > Tom, Bidulock
> > > > 
> > > > 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.
> 
> > 
> > > 
> > > > 
> > > > 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.
> 
> Figure 10 does not mention M2UA.  Also, figure 10 show an example
> of the more general SG to SG scenario discussed in section 3.5.
> M2PA falls under this scenario.  Also, RFC2719 is the architectural
> output of this WG prior to starting work in earnest on UAs.  You
> will not find M2UA, M3UA or SUA mentioned there by name either.
> It is an applicable and valid reference.
> 
> > 
> > > 
> > > > 
> > > > Beleow Figure 2: I'm wondering why only Figure 2 is 
> > > mentionned to be an "example".
> > > > The text should read "Figures 1 and 2 are only examples"
> > > 
> > > Figure 1 shows (and the text speaks to) architecture.  Figure 
> > > 2 shows a
> > > configuration example.
> > 
> > [HJS] I consider both figures as architectural, because the 
> pure IPSP-IPSP
> > case has no necessity to address issues related to MTP routing.
> 
> IMO no change is necessary.
> 
> >  
> > > 
> > > > 
> > > > Comment on section 1.6.1
> > > > 
> > > > As M2PA requires the usage of XCO and XCA based on MTP3b 
> > > [Q.2210] caution
> > > > has to be taken in case of changeover between M2PA and 
> > > conventional MTP2
> > > > links. Sending these messages back to the TDM based SS7 
> > > network must be
> > > > prohibited as long as no MTP3b functionality supported 
> > > (nevertheless I doubt
> > > > that it will be supported in the future) .
> > > 
> > > What caution?  Q.704 has no problems changing over 
> between MTP3b and
> > > convetional links.  The extended changeover procedure 
> (larger sequence
> > > numbers) only applies to the link from which traffic is being 
> > > diverted and
> > > there is no difficulty in changing over between MTP3b and 
> > > conventional links.
> > > In the same manner there is no difficultin in changing over 
> > > between M2PA
> > > and conventional links.
> > 
> > [HJS] disagree, read Q.2210
> 
> Please cite the section that you think will cause changeover problems
> for M2PA.  (By-the-by M2PA does not perform changeover, Q.704 does.)
> 
> > 
> > > 
> > > > 
> > > > last sentence: "FSNC" seems to be a typo and should read "FSNT"
> > > 
> > > FSNC is correct.
> > > 
> > > Q.703 call this Retrieval_Request_and_FSNC signal as shown in the
> > > SDLs.  Q.2210 calls it AAL-RETRIEVAL_REQUEST_AND_FSNC.  
> > > M2PA-08 properly
> > > refers to this as "Retrieval Request and FSNC".
> > > 
> > > > 
> > > > Comment on section 1.6.2
> > > > 
> > > > sending of "empty User DAta messages" contradicts with the 
> > > other adaptation
> > > > layer specifications.
> > > 
> > > Because this is not a TLV field, empty and missing are the 
> > > same thing.  SUA
> > > provides for optional data in messages (permits missing data 
> > > field).  There
> > > is no contradiction.
> > > 
> > > > 
> > > > Comment on Section 2.3
> > > > 
> > > > The M2PA message layout shows a field "Message Data". 
> > > According to section
> > > > 2.3.1 this should be renamed to "User Data".
> > > 
> > > In 2.3 it is illustrated that the message consists of three 
> > > components:
> > > Common Message Header, M2PA-specific Message Header and 
> Message Data.
> > > The Message Data component contains User Data.  "Message 
> > > Data" describes
> > > the component which contains "User Data" which contains the 
> > > "Data" field.
> > 
> > [HJS] that's nowhere stated explicitly, again clarity 
> should be added.
> 
>  2.3 M2PA Messages
> 
>  The following section defines the messages and parameter 
> contents.  An
>  M2PA message consists of a Common Message Header and M2PA Header
>  followed by the data appropriate to the message.
> 
> 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    \                                                               \
>    /                     Common Message Header                     /
>    \                                                               \
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    \                                                               \
>    /                  M2PA-specific Message Header                 /
>    \                                                               \
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    \                                                               \
>    /                         Message Data                          /
>    \                                                               \
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>  2.3.1 User Data 
> 
>  The User Data is the data sent from MTP3. The User Data is 
> an optional
>  field. It need not be included in an acknowlegement-only message.
> 
>  The format for the User Data message is as follows:
> 
> 
>     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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    \                                                               \
>    /                            Data                               /
>    \                                                               \
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> It is explicity stated above.
> 
> > 
> > > 
> > > > 
> > > > Comment on section 2.3.2.1
> > > > 
> > > > The justification for usin the "filler" field is strange. 
> > > SCTP checksum also
> > > > performs well in case of small messages.
> > > 
> > > The statements in 2.3.2.1 are not justification, they are 
> > > recomendations.
> > > The recommendation states that the content of the field 
> > > (number pattern)
> > > should be varied from message to message to ensure checksum 
> > > coverage.  It
> > > says nothing about the length of the message.  The 
> > > recommendation is valid.
> > > 
> > > > Furthermore, as M2PA SHALL not add padding, is it 
> > > acceptable to use a filler
> > > > field that is not an integral number of words?
> > > 
> > > Yes.
> > > 
> > > > 
> > > > Comment on section 4.1.2 fifth para
> > > > 
> > > > It should be made clear that the usage of the M2PA 
> > > registered Port number in
> > > > case of multiple M2PA should be on the same end of the 
> association.
> > > 
> > > It is not necessary that they be on the same end.  In 
> fact, for two
> > > associations the registered port number could be on both 
> ends of one
> > > association and one end of the other.
> > > 
> > > > 
> > > > text below figure 8 and table 1 last sentence:
> > > > It should be clarified that SLC is referred here.Tthe 
> > > sentence should read:
> > > > "Therefore, it is possible that the SLC values a and b 
> MAY be equal"
> > > 
> > > The values 'a' and 'b' in Table 1 are shown in the SLC 
> > > column.  That is
> > > sufficient.
> > [HJS] disagree, test should be readable without reference 
> to figures.
> > > 
> > > 
> > > IMO no changes are required as a result of these comments.
> > > 
> > > --brian
> > > 
> > > > 
> > > > 
> > > > HannsJuergen
> > > > _______________________________________________
> > > > Sigtran mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > 
> > > -- 
> > > Brian F. G. Bidulock
> > > [email-masked]
> > > http://www.openss7.org/
> > > 
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 7 May 2003 10:09:31 -0600

Schwarzbauer,

IMO "SP" is adequate and your insistence is unfounded.

--brian

Schwarzbauer Hanns Juergen wrote:                                             (Wed, 07 May 2003 10:17:56)

---

From: Tom George <[email-masked]>
Date: Wed, 07 May 2003 17:38:54 -0500

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.

> consequently I insist on having this clarification included in the definition of an SG
  [...]
> > 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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 7 May 2003 17:10:09 -0600

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:

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

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