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

From: Schwarzbauer Hanns Juergen <[email-masked]>
Date: Tue, 6 May 2003 17:49:40 +0200

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.

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

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

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

> 
> > 
> > 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/
> 
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Tom George <[email-masked]>
Date: Tue, 06 May 2003 14:27:57 -0500

Brian and Hanns,

I think the SG in RFC2719 Figure 7 also qualifies.

tomG.

> HannsJuergen
  [...]
> The MGC is not shown having MTP3 functionality as required by M2PA.
  [...]

-- 
* 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: Tom George <[email-masked]>
Date: Tue, 06 May 2003 14:34:58 -0500

Hanns,

In Q.2210 clause 9.8.1, the XCO/XCA message has the same heading code
(H0) as the Q.704 changeover message. If I understand it correctly, the
point of this is to make the MTP3 and MTP3b work together. So it looks
to me like this problem is solved at the MTP3 level.

Of course, the links have to be set up so that in changing over from the
M2PA link to a traditional TDM link, you don't overwhelm the traditional
link. But as far as exchanging the sequence numbers in the changeover
messages, it looks to me like it will work.

Let me know if I am missing something. 

tomG.

  [...]

---

From: Ken Morneault <[email-masked]>
Date: Tue, 06 May 2003 16:10:19 -0400

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

---

From: Tom George <[email-masked]>
Date: Tue, 06 May 2003 15:10:33 -0500

Hanns and Brian,

The format in section 2.3 applies to all M2PA messages. The field called
"Message Data" can either be:

   - the Data part of the User Data message (section 2.3.1), or 

   - the State part (including the optional filler) of the Link Status
message (section 2.3.2).

The Message Data in 2.3 definitely should not be renamed User Data. But
if this is not clear, I am open to suggestions on how to clarify it.

tomG.

  [...]

---

From: Tom George <[email-masked]>
Date: Tue, 06 May 2003 15:15:17 -0500

Hanns and Brian,

I don't have any problem with making this change to improve readability.

tomG.

  [...]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 May 2003 14:22:03 -0600

Schwarzbauer,

Please see comments below...

Schwarzbauer Hanns Juergen wrote:                                             (Tue, 06 May 2003 17:49:40)
> [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.

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

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

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

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

---

From: Tom George <[email-masked]>
Date: Tue, 06 May 2003 16:53:50 -0500

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. But then, if it transfers messages between two nodes on
the IP network, it is an STP.

But I don't see the significance of this issue. 

tomG.

"Brian F. G. Bidulock" wrote:
  [...]
  [...]