RE: M2PA Alignment Clarification
"Davidson, Mark" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <[email protected]> |
Brian, I agree that if ALL senders wait for the last LSP to be acked by SCTP before sending LSR/DATA then the problem is fixed (though I dislike munging the layers in this way). But the original problem is one for the receiver, not the sender. I.e., the receiver cannot guarantee that the far end follows this procedure. Changing what is sent, doesn't help guarantee what is received. We don't get to assume the same vendor on both ends. So the problem remains. -Mark Davidson -----Original Message----- From: Brian F. G. Bidulock [mailto:[email protected]] Sent: Tuesday, October 03, 2006 7:06 PM To: Newman, Catherine J Cc: [email protected]; Erickson, Mark Subject: Re: [Sigtran] M2PA Alignment Clarification Catherine, Newman, Catherine J wrote: (Tue, 03 Oct 2006 18:38:40) > Brian, > > I'm not sure I understand your suggestion... > There is no indication to M2PA of remote SCTP acknowledgment, and no > M2PA acknowledgement for LSSUs (even T7 does not apply). All implementations are capable of providing this indication. When proving messages are sent they are delivered to SCTP where they consume send buffer space. When they are acknowledged by the SCTP peer, their space is added back to the available send buffer space. The sending application can always check when they have all been acknowledged, by checking the available send buffer. This can be done most expediently when T4 expires. SS7 MTP2 does not presume an implementation. SCTP has only one physical wire (per interface) also. SCTP choses which messages are sent from which streams. So can an implementation of SS7. MTP2 provides guidance in this area: it says that LSSU take priority over DATA to the wire. Using the buffer technique above, you can restore MTP2 prioritization of messages to the wire by not sending the SLTM until the proving messages have been acknowledged. --brian -- Brian F. G. Bidulock [email protected] http://www.openss7.org/ _______________________________________________ Sigtran mailing list [email protected] https://www1.ietf.org/mailman/listinfo/sigtran