Subject: Re: [Sigtran] M2PA Comment: Multi-homing

From: [email-masked]
Date: Wed, 19 Jun 2002 17:23:03 +0100

Brian,

In that case, in my dual-homed example, when path A fails a co procedure takes
place. Once SCTP of the affected hosts has detected the path failure a cb can
take place whereby the affected hosts will now use path B. So in this case the
affected hosts will only be idle for a brief moment. When path A is again
available SCTP will reroute the messages.

Amish

"Brian F. G. Bidulock" <[email-masked]> on 19/06/2002 17:04:20

Please respond to [email-masked]

To:   Amish CHANA/EN/HTLUK@HTLUK
cc:   Tolga Asveren <[email-masked]>
      [email-masked]

Subject:  Re: [Sigtran] M2PA Comment: Multi-homing

Amish,

MTP3 changes over faster than SCTP can retransmit.

--brian

[email-masked] wrote:                       (Wed, 19 Jun 2002
16:59:41)
>
> Tolga,
>
> Consider the following scenario:
> - I have 4 associations between two signalling points.
> - Each association terminates on a different M2PA host.
> - I need 4 associations due to processing/throughput limitations on each M2PA
> host.
>
> If all the associations are single-homed, then 2 associations are routed via
> path A and 2 associations are routed via path B.
> Now if path A fails the co procedure will route all the messages on to the 2
> associations handling path B.
> The first 2 hosts now try re-establish the associations while the second two
> hosts carry twice their load.
>
> If all the associations are dual-homed, then 2 associations use path A as the
> primary and 2 associations use path B as the primary.
> Now if path A fails, SCTP will use path B to transmit the messages for the
first
> 2 hosts.
> In this case all the hosts carry traffic and also send heartbeat messages to
the
> IP addresses on path A.
>
> In the above architecture multi-homing seems better.
>
> If you have a single host at either end, I assume either option could be
> suitable.
>
> A.
>
>
>
>
>
>
>
> "Tolga Asveren" <[email-masked]> on 19/06/2002 16:23:07
>
>
>
>
> To:   [email-masked]
> cc:    (bcc: Amish CHANA/EN/HTLUK)
>
>
> Subject:  RE: [Sigtran] M2PA Comment: Multi-homing
>
>
>
> Javier,
>
> For the problem you mentioned, I would think that 2 non-multihomed SCTP
> associations instead of 1 multihomed one will work better. Even if one has
> Rto.Min less than 1 sec, in my opinion 2 association approach is better,
> because you can use both of them for data transfer, whereas with
> multihoming, for one path only heartbeat messages will be sent.
>
>     Tolga
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of
> > Javier Pastor-Balbas (ECE)
> > Sent: Wednesday, June 19, 2002 10:49 AM
> > To: [email-masked]'
> > Cc: [email-masked]
> > Subject: RE: [Sigtran] M2PA Comment: Multi-homing
> >
> >
> > Hi Brian,
> >
> > Do you mean that sending the message on a non-optimal route when
> > SCTP detects that a remote address does not work is faster than
> > retransmiting DATA towards the next remote IP address?
> >
> > Cheers // Javier.
> >
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Wednesday, June 19, 2002 3:44 PM
> > > To: Javier Pastor-Balbas (ECE)
> > > Cc: [email-masked]'; [email-masked];
> > > [email-masked]; [email-masked]
> > > Subject: Re: [Sigtran] M2PA Comment: Multi-homing
> > >
> > >
> > > Javier,
> > >
> > > I highly doubt that SCTP with an Rto.Min of 1 second will
> > > have anywhere
> > > near the performance of MTP3 in detecting even remote NIC
> > > failures.  MTP3
> > > will fail the link in 1 second whereas SCTP will only start its first
> > > retransmission in 1 second with an Rto.Min of 1 second in the
> > > case of a
> > > remote NIC failure.  Any use of SCTP multihoming for M2PA is
> > > marginal at
> > > best, given the current recommended and required protocol
> > > parameters for SCTP.
> > > IMO it would be foolish to accent SCTP mutlihoming in the
> > > draft as it is
> > > rather useless for M2PA.  Because it is not forbidden, however, it is
> > > permitted.  We have arlready exchanged more text that the
> > > subject deserves.
> > >
> > > --brian
> > >
> > >
> > > Javier Pastor-Balbas (ECE) wrote:
> > > (Wed, 19 Jun 2002 10:08:33)
> > > > Hi,
> > > >
> > > > Although the well-known MTP3 procedures such as changeover,
> > > changeback,
> > > > forced and controlled rerouting can give a certain degree
> > > of reliability I
> > > > would support to include the multihoming host. Upon the
> > > failure of a remote
> > > > NIC, it will be a faster procedure to change the remote IP
> > > address inside
> > > > the association that triggering the MTP3 procedures.
> > > Multihoming hosts would
> > > > certainly improve the performance in those cases. It would be then a
> > > > desirable feature IMHO.
> > > >
> > > > Cheers // Javier.
> > > >
> > >
> > > --
> > > 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
>
>
>
>
>
>
*******************************************************************************
> Important.
> Confidentiality: This communication is intended for the above-named person and
> may be confidential and/or legally privileged. Any opinions expressed in this
> communication are not necessarily those of the company. If it has come to you
> in error you must take no action based on it, nor must you copy or show it to
> anyone; please delete/destroy and inform the sender immediately.
>
> Monitoring/Viruses
> Orange may monitor all incoming and outgoing emails in line with current
> legislation.  Although we have taken steps to ensure that this email and
> attachments are free from any virus, we advise that in keeping with good
> computing practice the recipient should ensure they are actually virus free.
>
> Orange PCS Limited is a subsidiary of Orange SA and is registered in England
No
> 2178917, with its address at St James Court, Great Park Road, Almondsbury
Park,
> Bradley Stoke, Bristol BS32 4QJ.
>
*******************************************************************************
>
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

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

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

*******************************************************************************
Important.
Confidentiality: This communication is intended for the above-named person and
may be confidential and/or legally privileged. Any opinions expressed in this
communication are not necessarily those of the company. If it has come to you
in error you must take no action based on it, nor must you copy or show it to
anyone; please delete/destroy and inform the sender immediately.

Monitoring/Viruses
Orange may monitor all incoming and outgoing emails in line with current
legislation.  Although we have taken steps to ensure that this email and
attachments are free from any virus, we advise that in keeping with good
computing practice the recipient should ensure they are actually virus free.

Orange PCS Limited is a subsidiary of Orange SA and is registered in England No
2178917, with its address at St James Court, Great Park Road, Almondsbury Park,
Bradley Stoke, Bristol BS32 4QJ.
*******************************************************************************

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 19 Jun 2002 13:12:38 -0500

Amish,

MTP3 will reroute messsages as well: as fast or, in the case of
retransmission, faster.

--brian

[email-masked] wrote:                       (Wed, 19 Jun 2002 17:23:03)

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