Subject: Re: [Sigtran] M2PA draft 7 question -- alignment conclusion

From: [email-masked]
Date: Thu, 13 Feb 2003 10:51:52 -0500

Hello Brian,

>Q.703 ignores receipt of SIOS after sending SIO and while
>running T2.  M2PA should as well ignore LSO after sending LSA
>while running T2.  Then there is no problem.

Yep, my figure was wrong.

As far as the repeated SIN/SIE during T3 goes, it seems to me
that M2PA statisfies this (figure below).

> > ----------
> > Figure 7 is updated to show a transition from INITIAL_ALIGNMENT
> > to PROVING upon reception of either a Link Status Alignment or
> > Link Status Proving Normal or Link Status Proving Emergency
> > message. (Q.703 figure 4, figure 9 sheet 2)
> >
> >

----------
OLD TEXT 4.1.3
After the association is established, M2PA SHALL send a Link Status
Out of Service message to its peer.

NEW TEXT 4.1.3 (revision #3)
After the association is established, M2PA SHALL send a Link Status
Out of Service message to its peer and, prior to receiving a Start
Request from MTP3, MAY periodically send Link Status Out of
Service messages. During the Out of Service State M2PA SHOULD
ignore received Link Status Out of Service messages and
SHOULD respond to all other received messages by sending a Link
Status Out of Service message.

> >
> > ----------
> > OLD TEXT 4.1.3
> > M2PA stops timer T2 when it has received the Link Status Alignment
> > message from its peer.
> >
> > NEW TEXT 4.1.3
> > M2PA stops timer T2 when it has received a Link Status Alignment
> > message or Link Status Proving Normal or Link Status Emergency
> > message from its peer.
> >
> >
> > ----------
> > OLD TEXT 4.1.3
> > 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. After receiving Link Status Alignment from the peer, receipt
> > of a Link Status Out of Service message causes M2PA to send Out of
> > Service to MTP3 and return to the Out of Service state.
> >
> > NEW TEXT 4.1.3
> > Note: Between the time M2PA sends Link Status Alignment to its peer
> > and receives either Link Status Alignment or Link Status Proving
> > Normal or Link Status Proving Emergency from its peer, M2PA may
> > receive Link Status Out of Service from its peer. This message is
> > ignored. After receiving Link Status Alignment or Link Status
> > Proving Normal or Link Status Proving Emergency from its peer,
> > receipt of a Link Status Out of Service message causes M2PA to
> > send Out of Service to MTP3 and return to the Out of Service state.
> >
> > ----------
> > OLD TEXT 4.1.3
> >
> > When M2PA has both sent and received the Link Status Alignment
> > message, it has completed alignment.  M2PA starts the aligned timer
> > T3 and moves to the proving state.
> >
> > M2PA stops timer T3 when it receives a Proving Normal or Proving
> > Emergency message and starts proving period timer T4.
> >
> > NEW TEXT 4.1.3
> >
> > When M2PA has sent Link Status Alignment and received either a Link
> > Status Alignment or a Link Status Proving Normal or a Link Status
> > Proving Emergency message, it has completed alignment. M2PA starts
> > the aligned timer T3 and moves to the proving state. Note that
> > timer T3 is started even if reception of a proving message caused
> > the transition to the proving state.
> >
> > M2PA stops timer T3 when it receives a Link Status Proving Normal
> > or Link Status Proving Emergency message and starts proving period
> > timer T4.
> >

MTP3     |    M2PA     |    M2PA     |   MTP3
         |             |             |
         | (clear LSA) | (clear LSA) |
         | (clear LSPx)| (clear LSPx)|
         | OOS/Estab   | OOS/Estab   |
         |             |             |
         |      LSO -->+             |
         |             |  (Discard)  |
         |             |             |
         |             +<-- LSO      |
         |  (Discard)  |             |
         |             |             |
start -->+             |             |
         | INIT ALIGN  |             |
         |      LSA -->+             |
         | T2 Start    |             |
         |             |  (Discard)  |
         |             +<-- LSO      |
         |  (Discard)  |             |
         |             |             |
         |             |             +<-- start
         |             | INIT ALIGN  |
         |             +<-- LSA      |
         |             | T2 Start    |
         |             |             |
         | (mark LSA)  |             |
         | T2 Stop     |             |
         | PROVING     |             |
         | T3 Start    |             |
         |     LSPx -->+             |
         |             |             |
         |             | (mark LSA*) |
         |             | T2 Stop     |
         |             | PROVING     |
         |             | T3 Start    |
         |             +<-- LSPx     |
         |             |             |
         | (mark LSPx) |             |
         | T3 Stop     |             |
         | T4 Start    |             |
         |     LSPx -->|             |
         |             | (mark LSPx) |
         |             | T3 Stop     |
         |             | T4 Start    |
         |             +<-- LSPx     |
         /             /              /

Regards,

Jeff

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 13 Feb 2003 08:59:12 -0700

Jeff,

That's it.

--brian

[email-masked] wrote:                                             (Thu, 13 Feb 2003 10:51:52)

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

---

From: wayne n taylor <[email-masked]>
Date: Thu, 13 Feb 2003 14:13:19 -0500

Guys,
one comment about the flows in the figure....

<snip>

>          |     LSPx -->|             |
is it acceptable to bank on getting this LSPx within the T3 timer
duration (1-1.5 sec) ?. i reviewed the Q.703 SDLs and it was not clear
how both nodes transition from the "ALIGNED" state unless it does
something similar to what you show. obviously it is expected that T3
could timeout, but maybe T3 is little tight for IP networks. maybe the
T3 timer range should be expanded, say 1-5 seconds ??
>          |             +<-- LSPx     |

regards,

wayne

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 13 Feb 2003 12:49:43 -0700

wayne,

wayne n taylor wrote:                                                                (Thu, 13 Feb 2003 14:13:19)
> T3 timer range should be expanded, say 1-5 seconds ??

You will probably need a better network than that.

--brian

---

From: wayne n taylor <[email-masked]>
Date: Thu, 13 Feb 2003 15:59:43 -0500

Brian,
you are probably right !. but there are some folks who will want to run
this over satellite ...

wayne

---

From: Tom George <[email-masked]>
Date: Thu, 13 Feb 2003 16:52:27 -0600

If someone does want to use this over satellite, there will probably be
a number of changes that will be necessary. I would rather not try to
account for satellite transmission in this draft. What do the rest of
you think?

tomG.

> you are probably right !. but there are some folks who will want to run
  [...]

-- 
* Tom George       PB7-24001 (near B-21)      [email-masked]  *
* 972-519-3168   Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel;  3400 West Plano Pkwy,  MS PB7-SWPRO;  Plano, Texas 75075  *
* I actively disclaim speaking for Alcatel USA, Inc. I do not purport *
* to advertise or represent its position,  operations, or activities. *
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 13 Feb 2003 18:56:42 -0700

Tom,

As M2PA (and SCTP for that matter) have nothing close to Preventative
Cyclic Retransmission to reduce delays with forward error correction,
and because FEC is about the only approach that works for satellite
(high bandwidth, long delay), one would either need to reduce delay
with FEC beneath (or within) SCTP or give up on running M2PA over
satellite.

There is a way to get SCTP to perform FEC, that is to set RTO MAX
beneath RTT.  For fixed bandwidth channels, nother approach would
be that if there is no new DATA chunks to be transmitted, to fill
the remainder of the cwnd with retranmissions of already transmitted
TSNs.

It think this would be better addressed with a Satellite-SCTP or
a completely different transport than at M2PA.

--brian

Tom George wrote:                                  (Thu, 13 Feb 2003 16:52:27)