Subject: Re: [Sigtran] M2PA draft comments and questions.

From: "John Li" <[email-masked]>
Date: Tue, 11 Feb 2003 21:41:07 -0500

Hi, Jeff, 
Thanks for the responses. Further comments are inline. 
Thanks, 
John 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, February 11, 2003 1:24 PM 
To: John Li 
Cc: [email-masked] 
Subject: Re: [Sigtran] M2PA draft comments and questions. 

Hello John, 

Since no one else is responding, I'll answer. 

My responses are embedded below. 

Regards, 

Jeff 

On 02/11/2003 10:09:47 AM sigtran-admin wrote: 

>All, 
>I sent the following comments and questions to the group a while ago, and 
have 
>not got responses yet. here goes again. 
>thanks. 
>John 
> 
> 
>1.   In section 1.5: the following statement is somewhat confusing. 
>"The SG is an IPSP equipped with both traditional SS7 and IP 
>network connections. In effect, the Signaling Gateway acts as a 
>Signal Transfer Point (STP)" 
> 
>Perhaps we can say "The SG interconnects SS7 and IP networks by 
>converting signaling traffic" or just refer to the definition in 
>section 1.2 

I am not sure what defect this removes, and so I have no comment on this. 

> 
> 
>2.   Section 2.1.5 Message length 
>Should we specify the valid value range of the length? 
> 

No. Min/Max message length is dependent on message type, 
and in the case of user data is governed by MTP3. 

[John] the max payload MTP2 can carry is 272 octets. So by leaving that unspecified, it would be fine if M2PA used in a pure IP environment, but would have issues when used in a SG, who will be doing the segmentation and reassembling when receiving oversize(>272) messages from peer M2PA before it can be passed to the ss7 network?  

>3.   Section 2.3.1 User Data 
> 
>statement "M2PA does not add padding to the MTP3 message.". 
>I think we should make it a requirement: "M2PA should not add padding 
>to the MTP3 message." 
> 

Sounds good to me. 

> 
>4.   In section 4.1.3 Link alignment 
> 
>perhaps we can specify the recommended practice for choosing 
>emergency proving vs. normal proving during alignment procedure. 
> 

This is governed by MTP3 procedures and is outside the scope 
of the M2PA draft. 

[John] I thought about the scope issue as well. But since the draft covers MTP3 changeover in 2.4.6, by the same token, it would be very useful to add a paragraph to explain the two different alignment procedures in section 2.4: Procedures to Support the MTP3/MTP2 Interface.

> 
>5.   Section 4.1.8: 
>"If a Link Status Alignment message with an unsupported 
>received by the newer version, the receiving end's M2PA 
>SHALL NOT complete the alignment procedure." 
> 
>can we clearly define the behavior of not completing the alignment 
>procedure? 

I believe that you are suggesting that the text be reworded to state 
the following: 

"If a Link Status Alignment message with an unsupported version 
is received by the newer version, the receiving end's M2PA 
SHOULD fail the link." 

I think this was already understood, but the change improves clarity. 

[John] Further, I am thinking in this case, what is the procedure to prevent further alignment when the M2PA knows the incompatible versions: for example, should M2PA notify its upper user about the incompatible so that the upper layer will not initiate alignment again. what is the status to the M2PA user to indicate it should not try to re-align if so, etc.

> 
>6.   section 4.2.1 sending and receiving messages 
>When M2PA receives a User Data message with Backward Sequence Number 
>equal to 'n', it may remove all messages with Forward Sequence Number 
><= n from its queue. 
> 
>This is incorrect. Consider at the time SN is cycled to 0 from 127 
>(assume 128 buffers), there are 127, 126, etc are waiting for 
>acknowledgement. We should replace it with "The message n and all 
>outstanding (not yet acknowledged) messages sent before the message n 
>may be removed from its queue. 

I agree with the change. 

> 
>7.   section 4.2.1 
>If M2PA receives an empty User Data message, it SHALL NOT send an 
>acknowledgement of that message. 
> 
>What is empty User Data message? FISUs? 
> 

It is a M2PA user data message containing only the common header. 
An 'empty'  User Data message is an M2PA receipt acknowledgement. 
The statement in the draft is saying don't ACK an ACK. 

>-- 
>__________________________________________________________ 
>Sign-up for your own FREE Personalized E-mail at Mail.com 
>http://www.mail.com/?sr=signup 
> 
>_______________________________________________ 
>Sigtran mailing list 
>[email-masked] 
>https://www1.ietf.org/mailman/listinfo/sigtran 

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

-- 
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 Feb 2003 20:33:11 -0700

John,

John Li wrote:                                                                        (Tue, 11 Feb 2003 21:41:07)
> [John] the max payload MTP2 can carry is 272 octets. So by leaving that
> unspecified, it would be fine if M2PA used in a pure IP environment, but
> would have issues when used in a SG, who will be doing the segmentation and
> reassembling when receiving oversize(>272) messages from peer M2PA before it
> can be passed to the ss7 network?  

MTP3b does not limit to 272 octets.  Neither does Q.703 Annex A.

This is a network restriction understood by MTP3.  M2PA imposes no
restriction on message size.

> >I think we should make it a requirement: "M2PA should not add padding 

It is necessary to say MUST rather than SHOULD.

> [John] I thought about the scope issue as well. But since the draft covers
> MTP3 changeover in 2.4.6, by the same token, it would be very useful to add
> a paragraph to explain the two different alignment procedures in section
> 2.4: Procedures to Support the MTP3/MTP2 Interface.

Changeover is discussed because the chnageover message contains
the MTP2 sequence number.  XCO/XCA need to be used due to M2PA's
larger sequence number.

Emergency vs. Normal proving is adequately addressed by MTP3 which
is cited as a reference.

> [John] Further, I am thinking in this case, what is the procedure to prevent
> further alignment when the M2PA knows the incompatible versions: for
> example, should M2PA notify its upper user about the incompatible so that
> the upper layer will not initiate alignment again. what is the status to the
> M2PA user to indicate it should not try to re-align if so, etc.

Management procedures are implementation dependent.

--brian

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