Subject: RE: [Sigtran] M3UA: IG: ASP IDs & a proposal to solve a network equipment failure scenario

From: "Schantz, John" <[email-masked]>
Date: Thu, 27 Jun 2002 15:42:22 -0500

Tolga, if the HUB or router that the NIC/Ethernet is connected to fails,
it will take ALL association with it.  SCTP multi-homing will not help
you!

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]] 
Sent: Thursday, June 27, 2002 3:48 PM
To: [email-masked]
Subject: RE: [Sigtran] M3UA: IG: ASP IDs & a proposal to solve a network
equipment failure scenario

John,

> We are pretty mush finished with our development of M3UA and we are in

> the process of trying to find ways to improve or fix some of the 
> holes.  I have a proposal below for fixing a network equipment failure

> scenario that I would like to get added to the IG.  It will also 
> clarify the use of ASP IDs.
> I also think the proposal could be extended to perform a
> "change-over" if we
> are willing to get some transmission info from SCTP, but that can
wait.
> The failure of IP network equipment (HUBs, routers, etc.) has a
> major impact
> on the performance of M3UA (and other UAs).  If the failure occurs at
an
> adjacent network interface, the connecting ASP or SGP can detect this
> failure immediately (association failure) and can move the traffic to
> another association.  The problem is that the non-adjacent ASP or SGP
can
> not detect the failure immediately since it must wait for missed
> SCTP SACKs
> or Heartbeat Acks.  Section 4.3.4.6 states that if a Heartbeat Ack (or
any
> other message) is not received within 2*T(beat), then the remote M3UA
is
> considered unavailable.  There are a couple of problems with this:  1)
the
> non-adjacent side is still sending messages during this 2*T(beat) time
> period, this period could be several seconds during which message
buffers
> could overflow and/or messages could be lost, and 2) only the ASP/SGP
> connected to the failure is unavailable while the other ASP/SGPs
> at the node
> could still be available and should have the traffic moved over to
them as
> soon as possible..
> Below is a proposal that should solve most of this problem and limit
> (eliminate?) the possible message loss.    The M3UA RFC allows for the
> assignment of IDs to ASPs but they are only transported in the ASP UP
> message and there is no discussion of what they are used for.
> Some changes
> and clarifications are needed.  First, for the ASP IDs to be useful,
they
> must be unique per association from an AS.  Second, the ASP Down and
ASP
> Down Ack must also have the ASP ID parameter as an optional parameter
> (adding it to the ASP Inactive [Ack] should also be considered).
> Third, an
> ASP/SGP that still has an available association to the remote
> node should be
> able to send (forward) an ASP Down/ASP Down Ack that contains the
> ASP ID of
> the unavailable ASP (association).  Each of these items are
> addressed below.
> ASP ID uniqueness
> It is fairly easy to show that assigning an ASP ID to the process that
> handles all associations for a network interface is of very little
use.
> Suppose that you have an ASP that has an association to 2 (or
> more) SGPs at
> an SG.  Suppose the ASP only wants to stop traffic on one of the
> associations.  It would send an ASP Inactive or ASP Down.  There is no
ASP
> IDs present but there is an implied ASP ID for the ASP.  Will the
> SG assume
> that all associations to this ASP are going out of service or
> should it only
> assume that the association that carried the message is going out of
> service?  It is the latter case that is assumed.  Hence, the
> generic ASP Up,
> ASP Inactive, ASP Down, etc. only apply to the association (ASP
> and ASP ID)
> that the messages are received on.  Therefore, the implicit and
> explicit ASP
> IDs must be unique per association between the AS and SG.
> ASP ID Optional Parameter in ASP Down and ASP Down Ack
> The need for the ASP ID to be an optional parameter in the ASP
> Down and ASP
> Down Ack will become clear in the next section.  It will allow the
ASP/SGP
> to be explicit about which association is being impacted.  Making
> the ASP ID
> optional in the ASP Inactive and ASP Inactive Ack should also be
> considered.
> Forwarding of Locally Detected Association Failure.
> When a node detects an association failure, its M3UA should notify the
> affected adjacent node of the failure via an available association to
the
> adjacent node.  When the AS/SG detects the association failure, it
should
> send an ASP Down [Ack] with the "failed" ASP ID (association) on an
> association that is still available to the adjacent SG/AS.  When
[TOLGA] If there is still a healthy association between those two nodes,
why initially not to have a multihomed SCTP association, which also
includes this interface? If number of interfaces is high, IMO this would
increase detection time for host failures, but is this the reason, why
you didn't prefer to use multihoming?
> the M3UA at
> the adjacent SG/AS receives the ASP Down [Ack] with an ASP ID that is 
> different from the known ASP ID for the association, it should handle 
> message as though the ASP Down [Ack] was received by the SGP/ASP
> (association) corresponding with the ASP ID.  This will cause the 
> SG/AS transition the ASP/association to the DOWN state and to move the

> traffic away from the failed ASP/association (that it has not yet 
> detected).

_______________________________________________
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: "Tolga Asveren" <[email-masked]>
Date: Thu, 27 Jun 2002 17:12:43 -0400

John,

> From: Schantz, John [mailto:[email-masked]]
> Sent: Thursday, June 27, 2002 4:42 PM
> To: Tolga Asveren; [email-masked]
[TOLGA] But then how can the other association, from which you propose to
send ASPDOWN[ACK] survives? Probably it uses another NIC/Ethernet, but then
why not make this interface also part of the multihomed association?