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

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

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.

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.

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"

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

last sentence: "FSNC" seems to be a typo and should read "FSNT"

Comment on section 1.6.2

sending of "empty User DAta messages" contradicts with the other adaptation layer specifications.

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

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. Furthermore, as M2PA SHALL not add padding, is it acceptable to use a filler field that is not an integral number of words?

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.

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"

HannsJuergen
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

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

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.

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

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

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

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

> sending of "empty User DAta messages" contradicts with the other adaptation

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.

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

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

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

IMO no changes are required as a result of these comments.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/