Subject: Re: [Sigtran] Repost - More M2PA 7 questions]

From: "TOLGA ASVEREN" <[email-masked]>
Date: Fri, 21 Feb 2003 12:44:30 +0200

Brian,
--- "Brian F. G. Bidulock" <[email-masked]> wrote:
> TOLGA,
>
> TOLGA ASVEREN wrote:
>                                 (Fri, 21 Feb 2003
> 09:43:22)
> >
> > Thanks , now it is clear, so that thread was
> concluded(sometimes hard to
> > decide for this) and we will have a slightly
> modified version of Tom's
> > initial interpretation, where data is not
> discarded but not acknowledged
> > either. Then I also would think stopping T7 is
> fine.
> >
> > One more question:
> > During changeover, will data received during RPO
> but not acknowledged,
> > considered as received successfully or not, i.e.
> in case of changeover,
> > will they be delivered to MTP3 or not?
>
> Unacknowledged messages must never be delivered to
> MTP3 or duplication
> will result on changeover.  This is true for Q.703
> as well as M2PA.
[TOLGA]Why so? I would think, when Retrieve BSTN is received, it might be
good to deliver data received successfully but not delivered to MTP3
because of RPO, and then reply to Retrieve BSTN request. This migth save us
to retranmit them on another link (I am not sure though, whether this will
create a problem for MTP3, Q.704 Figure30 Sheet 2 of 6 does not show what
to do in such a case, but I would think this should be fine, I assume it is
possible that MTP2 is delivering a message to MTP3, while MTP3 is sending
Retrieve BSTN. So, MTP3 should be prepared to get something different than
BSTN after sending Retrive BSTN (?) )

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 21 Feb 2003 04:27:55 -0700

TOLGA,

TOLGA ASVEREN wrote:                                                                 (Fri, 21 Feb 2003 12:44:30)
> BSTN after sending Retrive BSTN (?) )

Bad idea.

--brian

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

---

From: "Subhashini" <[email-masked]>
Date: Thu, 27 Feb 2003 17:12:54 -0600

The following text in section 4.1.3 and the diagram in section 3 are
contradicting to each other.

Note: Between the time M2PA sends Link Status Alignment to its peer
and receives Link Status Alignment from its peer, M2PA may receive
Link Status Out of Service from its peer. This message is
ignored.
As per diagram, on getting LS OOS (while waiting for LS Alignment), instead
of ignoring the message, the state is changed to OOS.

Which one is correct? Please clarify.

 thanks,

Subhashini ...

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "TOLGA ASVEREN" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, February 21, 2003 5:27 AM
Subject: Re: [Sigtran] Repost - More M2PA 7 questions]

> TOLGA ASVEREN wrote:
(Fri, 21 Feb 2003 12:44:30)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 27 Feb 2003 04:50:25 -0700

Subhashini,

The text is correct, the diagram is not.

--brian

Subhashini wrote:                                                               (Thu, 27 Feb 2003 17:12:54)

---

From: "Subhashini" <[email-masked]>
Date: Thu, 27 Feb 2003 17:37:47 -0600

In section 4.1.3, the text "M2PA MAY send additional Link Status Ready
messages while timer T1 is running" is not clear. At what interval this LS
Ready message is to be sent?

thanks,
Subhashini ...

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "Subhashini" <[email-masked]>
Cc: "TOLGA ASVEREN" <[email-masked]>; <[email-masked]>
Sent: Thursday, February 27, 2003 5:50 AM
Subject: Re: [Sigtran] Repost - More M2PA 7 questions] - LS OOS during
alignment.

> > > > [TOLGA]Why so? I would think, when Retrieve BSTN is received, it
might
> > be
> > > > because of RPO, and then reply to Retrieve BSTN request. This migth
save
> > us
> > > > to retranmit them on another link (I am not sure though, whether
this
> > will
> > > > to do in such a case, but I would think this should be fine, I
assume it
> > is
> > > > Retrieve BSTN. So, MTP3 should be prepared to get something
different
> > than