Subject: Re: FW: Redundant MG's

From: "Kaul, Bharat" <[email-masked]>
Date: Tue, 30 Jan 2001 14:00:52 -0800

I was under the impression that we will be dealing with these issues in next
version of the protocol as per our earlier discussions on the list. But
better sooner than later.

I think we should have one LOGICAL redundant MG for every LOGICAL primary MG
to keep things simple and manageable. Both the primary and the backup MG
have to register with the MGC through ServiceChange. Either of these MGs is
allowed to specify their partner in the mated pair configuration with the
appropriate role.

Here is what I suggest. We can put these suggestions as part of Extension
Parameters in ServiceChange if we don't intend to add to the current syntax.
In the approach suggested, we can have one primary and multiple secondary
MGs.

Two new ServiceChange Methods:

1) MatedRestart
2) MatedSwitch

A New ServiceChange Parameter

1) ServiceChangedMatedInfo

Description and use of the above is given below:

ServiceChange request has a ServiceChange Method as "MatedRestart" to
indicate that it is a registration request for one of the MGs in the mated
pair.  The ServiceChange Request will have ServiceChangeMatedInfo as a
ServiceChange Parameter with following syntax:

ServiceChangeMatedInfo =  matedToken = {role, MID}
role = Primary/StandBy

The two MGs can register as and when they please. However, during the time
interval where Primary is registered and StandBy is not, the MGC will send
commands only to Primary as it does in non-redundant configurations.
Registration of StandBy MG before Primary MG is allowed but MGC won't send
any commands to the redundant MG until Primary MG registers successfully.

After the two MGs have registered with the MGC, the MGC sends commands to
both the MGs and expects response from only one of them (irrespective of the
transport). The StandBy MG must not respond unless it knows for sure that
the Primary MG has failed. The state synchronisation between MGs in the
mated-pair configuration is beyond the scope of the protocol.

If the MGC receives a response for the transmitted command from the StandBy
MG, it should assume that the Primary MG has failed (and hasn't been able to
send ServiceChange with method as "Failover").
In such a case, it switches the roles of the MGs with StandBy becoming
Primary.The Primary MG should be assumed to be out of service and no
commands to be transmitted to this MG.

The out of service MG has to re-register with the MGC with method as
"MatedRestart" to be part of the Mated-pair configuration. It must register
as "StandBy".

If the mated-pair MGs at any point of time wish to switch roles, the
PRIMARYMG sends a ServiceChange Request with method as "MatedSwitch" to the
MGC, specifying the ServiceChangeMatedInfo parameter indicating the MG which
should be chosen as PRIMARY now.. After this, MGC should switch roles for
the MGs and follow above behaviour.

Comments ?

- Bharat

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Tuesday, January 30, 2001 8:11 AM
To: [email-masked]
Subject: Re: FW: Redundant MG's

I agree with your concern about UDP.

Either we deprecate the whole idea, or we have to add words in the
Implementors Guide.
First of all, how does the MGC know about the redundant MG?
    We need a ServiceChange that registers you as a secondary for (some
number of?)
        primaries
    Then we need an "ack" for transactions.  Probably just a
Reply=TransactionId.

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Tuesday, January 30, 2001 10:47 AM
To: [email-masked]
Subject: Re: FW: Redundant MG's

First point: that the redundant MG cannot accept/reject transactions simply
means that it does not send transaction responses back to the MGC.  It can
still update internal state, allowing it to take over immediately if the
other MG fails.  I am still bothered by the transport issue: the arrangement
won't work with UDP/ALF unless empty messages are sent back to the MGC to
acknowledge received messages.

> -----Original Message-----
> From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ]
> Sent: Tuesday, January 30, 2001 12:33 AM
> To: [email-masked]; Taylor, Tom-PT
> [NORSE:B901:EXCH]
> Subject: Re: FW: Redundant MG's
>
>
>
>
> Hello,
>
> I am not in full agreement with the text given in the protocol....
>
> >   Allowing the MGC to send duplicate messages to both MGs
> accommodates
> >   pairs of MGs that are capable of redundant failover of one of the
> >   MGs.  Only the Working MG shall accept or reject transactions.
>
> What's the use of sending duplicate transactions to standby
> MG when it is not
> doing anything with those transactions ?
>
> Transactions should be sent to the MG which creates
> association with MGC and
> after switchover, transactions should be sent to the newly active MG.
>
> Also, when we talk about duplicate transactions from MGC end,
> are these
> transactions going on two different associations ?
>
> Thanks for your time ....
> Chan....
>
>
>
>
>
>
> Tom Taylor <[email-masked]> on 01/29/2001 08:06:27 PM
>
> Please respond to Tom Taylor <[email-masked]>
>
> To:   [email-masked]
> cc:    (bcc: Chanchal Hassija/HSS)
>
> Subject:  Re: FW: Redundant MG's
>
>
>
>
> We need to distinguish between retransmissions triggered by
> application-level
> timers when reliable transport is being used and
> retransmissions when UDP/ALF is being used.  In the latter
> case, messages should
> be acknowledged by the inactive MG(s) even if
> they are not being accepted or rejected.  The MGC should
> handle retransmissions
> to each MG independently, since the messages
> may be taking different routes and thus be subject to
> different loss conditions.
>
> Tom Taylor
>
> On Thu, 25 Jan 2001 14:02:41 -0500, Lisa Amberger
> <[email-masked]> wrote:
>
> >Section 11.4 "Failure of an MG" in RFC 3015 states that:
> >
> >   Allowing the MGC to send duplicate messages to both MGs
> accommodates
> >   pairs of MGs that are capable of redundant failover of one of the
> >   MGs.  Only the Working MG shall accept or reject transactions.
> >Given one or more redundant MG's. When an MGC sends messages
> to the primary
> >MG and one or more secondary MG's.
> >How is retransmission handled?
> >A) Each time that the message is retransmitted to the
> primary MG, it is also
> >retransmitted to the secondary MG's.
> >B) Retransmission to the primary MG and secondary MG's is handled
> >independently. (The SRTT time will be used for retransmissions to the
> >primary MG. The default RTT will be used for retransmission
> to the secondary
> >MG's)
> >C) Messages are only retransmitted to the primary MG.
>
>
>
>
>
>
>

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 30 Jan 2001 17:34:53 -0600

Rserpool may provide a more generic solution to this. Also, you may find
discussions captured in H.323 Annex R (draft) useful.

-Qiaobing