Subject: RE: [Sigtran] M2PA Alignment Clarification

From: "Davidson, Mark" <[email-masked]>
Date: Wed, 4 Oct 2006 07:21:45 -0500

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-masked]] 
Sent: Tuesday, October 03, 2006 7:06 PM
To: Newman, Catherine J
Cc: [email-masked]; 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-masked]
http://www.openss7.org/

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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 4 Oct 2006 06:50:08 -0600

Mark,

Well, if the implementation does not follow the recommendations
of RFC 4165 section 4.1.8, then there will be a problem.

If, at the receiver, you should wait until it can be determined
that no messages are outstanding for stream 0 before reading data
messages on stream 1, per section 4.1.8.  When you read an SLTM
and have a missing TSN, as all M2PA messages are sent ordered,
you can easily detect that there is a missing message from stream 0.

Per 4.1.8, your receiver should wait until the link status stream
messages are read before processing messages read from stream 1.

Therefore, if you make your receiving implementation follow 4.1.8
to the letter, then you will not have a problem: it will wait until
all proving messages have been received before processing the SLTM.

--brian

Davidson, Mark wrote:                    (Wed, 04 Oct 2006 07:21:45)

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

---

From: Brian Tatum <[email-masked]>
Date: Thu, 05 Oct 2006 09:53:12 -0500

I agree with Mark in that this sounds implementation dependent and does 
not guarantee interworking between different implementations of m2pa stacks.

Brian Bidulock stated 4.1.8 "M2PA SHOULD give higher priority to reading 
the Link Status stream than to reading the User Data stream.".  If this 
is required to guarantee interworking then this must be stated as a 
requirement and not as a recommedation as it is here.

At one time (draft version 3), the proving messages were sent on the 
data stream.  I do not remember the reason that the proving messages 
were moved from the data stream to the link status stream.  If the 
proving messages were on the data stream, there would not be the 
missequencing of the SLTM and proving messages received.

-- 
Brian Tatum       (972)519-2781          E-mail: [email-masked]
Alcatel USA, Inc.  3400 West Plano Parkway, MS SWPRO, Plano, Texas 75075
******* Alcatel is not responsible for any opinions stated here. *******

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 5 Oct 2006 13:45:22 -0600

Brian,

Brian Tatum wrote:                             (Thu, 05 Oct 2006 09:53:12)
> 
>    Brian  Bidulock  stated  4.1.8  "M2PA  SHOULD  give higher priority to
>    reading  the  Link  Status  stream  than  to  reading  the  User  Data
>    stream.".   If  this  is  required to guarantee interworking then this
>    must  be  stated  as a requirement and not as a recommedation as it is
>    here.

The reason it is SHOULD and not MUST in 4.1.8 is because there
are some circumstances in which it is not necessary.  The case
in point is just not one oce them.

>    missequencing of the SLTM and proving messages received.

Then then would be a possible missequence between proving
messages and LSR and LSA.  If you put LSR on the data stream
too, there is a possible missequence between proving or LSR and
LSA.  The only way to avoid missequencing between streams is to
follow the priority of 4.1.8 or to put everything on one stream.

This was suggested.  However, the disadvantage of putting
everything on one stream was that an implementation could not
expedite LS messages when that single stream is blocked up with
data.  So, we have the priority of 4.1.8.

--brian

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