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

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

Bidulock,

in case it's your opinion, I can't change it, but there are other views already in the document.

Section 1.5
"Figure 2 shows an example of M2PA used in a Signaling Gateway
(SG). The SG is an IPSP equipped with both traditional SS7 and IP
network connections.  Any of the nodes in the diagram could have SCCP
or other SS7 layers above MTP3. The Signaling Gateway acts as a Signal
Transfer Point (STP).  Other STPs MAY be present in the SS7 path
between the SEP and the SG."

So please give me an example where an SG does not act as an STP.

greetings

HannsJuergen

> -----Ursprüngliche Nachricht-----
> Von: Brian F. G. Bidulock [mailto:[email-masked]]
> Gesendet: Mittwoch, 7. Mai 2003 18:10
> An: Schwarzbauer Hanns Juergen
> Cc: List: IETF sigtran (E-Mail)
> Betreff: Re: [Sigtran] (M2PA) Comments on M2PA v8 - Last Call
> 
> 
> Schwarzbauer,
> 
> IMO "SP" is adequate and your insistence is unfounded.
> 
> --brian
> 
> Schwarzbauer Hanns Juergen wrote:                             
>                 (Wed, 07 May 2003 10:17:56)
> > 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/
> > > 
> 
> -- 
> 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: Thu, 8 May 2003 03:26:48 -0600

Schwarzbauer,

Look back a few messages, I gave several examples.

--brian

Schwarzbauer Hanns Juergen wrote:                                             (Thu, 08 May 2003 09:45:16)