Subject: RE: [Megaco] Support for redundant MG failover

From: "Kevin Boyle" <[email-masked]>
Date: Thu, 24 Apr 2003 12:32:52 -0400

Comments inline. [KJBII]

Kevin

-----Original Message-----
From: Flemming Andreasen [mailto:[email-masked]] 
Sent: Thursday, April 24, 2003 11:24 AM
To: Adrian Soncodi
Cc: Fernando Vallejo Lazaro; [email-masked]
Subject: Re: [Megaco] Support for redundant MG failover

Adrian Soncodi wrote:

> Fernando,
>
> Thanks for the reply. See comments inline.
>
> Adrian
>
>
>
> Fernando Vallejo Lazaro wrote:
>
>> Hi all,
>>
>> Only some comments.
>>
>> - You say : "So while talking on A1-A1, the MGC cannot for example 
>> audit on A2-A2, because this is immediately considered a failover 
>> (...)". I don't think this is true. If an MG receives an Audit from 
>> MGC-A2 (which it does not know) it will reject the transaction 
>> because there is no association established with it.
>
> Some MGs do this, others either don't reply or they failover. The 
> latter may be in violation of the standard, but I think that's because 
> it's not very well explained.
>

I think part of the problem here is that the concept of a control
association is not very well defined when it comes to UDP; how do you
determine if a message received is part of the UDP control association ?

[KJBII] H.248 control associations have absolutely nothing to do with
transport.  To quote from the most recent version of Annex F: "A control
association is a communication relationship whereby an MGC is controlling an
MG.  A control association is instantiated via registration.  The control
association is terminated by the MG going out of service, being successfully
handed off to an alternate MGC, or successfully failing over to an alternate
MGC.  An MG shall have at most one control association at any time.  Only
MGs may instantiate control associations.  Control associations as defined
here apply only within the context of media gateway control signalling.
This definition should not be confused with that of control associations in
the context of transport (TCP, UDP, etc.)."

[KJBII] So, to go even further on the point above, the MG may "know" MGC-A2
(that is, have it in its list of MGCs), but because there can be only one
control association at any given time, and those associations are
established by the MG, the communication from MGC-A2 should be viewed as, at
best, an inappropriate control message.  At worst, it would be an attack to
attempt to gain control of the MG.  Also, I would like to note that an audit
command would never be construed as a failover.  Only a SC with a method of
failover would be a failover.

>
> In my case, since I use the audits on A2-A2 as heartbeats (just to 
> check for connectivity), any reply is OK, if only I get it. But this 
> is a problem if some other MGC really wants to audit and is rejected. 
> By the way, MGCP allows for this extra auditing, why is there a 
> difference in approach? This only complicates things for an MGC which 
> controls both MGCP and MEGACO MGs.

[KJBII] Megaco and MGCP are not the same.  There are many differences
between the two protocols, and this just happens to be one of them.

>
>> - If the MG is multi-homed you can provision the two IP static 
>> addresses as primary and secondary MGCs. In case one fails it will 
>> change to the other IP which in fact is the same MGC.
>
> Yes, but if the failure (MGCs interface A1) occurs after the initial 
> ServiceChange, sometimes during operations when the MG does not have 
> any notifications to send, and if the MG does not do any heartbeats, 
> then it won't be aware of the failure, it will just think it's idle. 
> So it will not initiate ServiceChange to the "alternate" MGC. 
> Furthermore, even if the MG receives a new command from MGC A2, as you 
> showed above, it will reply with an error and remain idle. (By the 
> way, where in the standard is this rule stated?)

Yes, however there are ways around this problem (by design, Megaco chose to
only have the MG be able to initiate the control association, so you just
need to make sure it does that - see H.248.14 for a solution).

There are however a couple of bad things here:
1. Only the statically provisioned list of backup MGCs can be contacted, and
only in the order they were provisioned. 

[KJBII] This is bad because?

2. The spec is silent on whether a backup MGC replicates the state of the
primary or not. Consequently, you cannot assume that it does, and hence
switching to the backup is something you don't want to do prematurely. 

[KJBII] Why is this the MGs concern?  The backup MGC is responsible for
getting itself attuned to the current state of affairs on the MG.  This can
be done in any number of ways, some of which are more detrimental to
existing connections than others.

3. The switchover is not graceful, i.e. there has to be a failure before you
start contacting the backup. In contrast, a more robust redundancy scheme
would detect/suspect the failure earlier during retransmission and switch to
one of the backups to prevent any loss of state. Furthermore, there should
be a way of indicating that a backup is fully redundant and hence the
switchover can be done fairly early without any risk.

[KJBII] Hmmm.  How would the MG know that the retransmissions were due to
MGC failure, as opposed to network congestion?  I believe that the MG will
have to wait for the retransmissions to run their course, or to utilize a
different method of determining that the MGC had failed that eliminates
network congestion as a possibility.

>> Maybe there should be a deep explanation of how to do this to smooth 
>> the process because the MG does not know whether the secondary is an 
>> independent MGC, a backup or a mirror and depending on this 
>> information it can behave in one way or another (e.g. a ServiceChange 
>> Request only
>> Informational)
>
> Here, I concur with you and with Flemming, there should be more 
> explanations. If you take into account multiple IP addresses, DNS 
> names translating to one or more IP addresses, MGs and MGCs working in 
> active-standby mode with or without complete state synchronization, as 
> well as multiple active-standby pairs handoff, things get complicated 
> enough to be worth additional explanations.

Agreed - there is work to be done in this area.

>> - Another thing the MGC can do when it detects the that A1 is going 
>> to die is to send a Handoff to the interface A2 for each MG so that 
>> the connections are restablished in the new path.
>
> This is what it's forced to do, but the MG is not aware that the 
> handoff is to the same MGC. Consequently, it continues to send pending 
> notifications to the old IP address, as per RFC 3015 section 7.2.8 
> (and still in h248v2-04):
>
> "At the same time, as indicated in clause 9, transaction replies and 
> pending indications must be sent to the address from which the 
> corresponding requests originated."
>
> This forces the "new" MGC (which is not really new) to re-issue all 
> the notification requests, which, apart from being a substantial 
> overhead, can cause serious race conditions, especially with packages 
> such as bcas. Again, from experience, this is a point of contention, 
> whether or not it's the right behavior.

[KJBII] Not true.  Any NEW event detections would go to the "new" MGC.
Remember, events in H.248 persist until a new events descriptor is sent to
replace the old.  Therefore, even through a handoff/failover, the MG should
continue to scan for events and report them to the controlling MGC -- the
"new" MGC once the handoff/failover occurs.

>
> If the MG were somehow aware that this is the same MGC, the signaling 
> path switchover between A1-A1 and A2-A2 would be faster and more 
> reliable.
>
> I think the MEGACO spec obviously did not consider multi-homed 
> MGs/MGCs, therefore we are trying to see if the existing rules "happen 
> to work" in this case. I have had a lot of arguments over it because 
> of different interpretations.
>

I agree (and actually, I'm surprised nobody has addressed it yet because it
has been known for a long time and pops up on the mailing list from time
time, but without much progress being made).

-- Flemming

[KJBII] There are many possibilities for redundancy -- multihoming is not
the only one.  Further, I don't see how the rules don't work, or how we can
optimize this particular case without penalizing the other possibilities.
The MG should not know, or care, that the MGC is multihomed.  The same goes
for the MGC with respect to the MG.  If you change IP addresses, then you
change control association, and that has consequences that have to be
rectified by the MGC.

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

---

From: Adrian Soncodi <[email-masked]>
Date: Thu, 24 Apr 2003 14:48:04 -0500

More comments inline.

Adrian

Kevin Boyle wrote:

> From: Flemming Andreasen [ mailto:[email-masked] ]
> transport.  To quote from the most recent version of Annex F: "A 
> control association is a communication relationship whereby an MGC is 
> controlling an MG.  A control association is instantiated via 
> registration.  The control association is terminated by the MG going 
> out of service, being successfully handed off to an alternate MGC, or 
> successfully failing over to an alternate MGC.  An MG shall have at 
> most one control association at any time.  Only MGs may instantiate 
> control associations.  Control associations as defined here apply only 
> within the context of media gateway control signalling.  This 
> definition should not be confused with that of control associations in 
> [KJBII] So, to go even further on the point above, the MG may "know" 
> MGC-A2 (that is, have it in its list of MGCs), but because there can 
> be only one control association at any given time, and those 
> associations are established by the MG, the communication from MGC-A2 
> should be viewed as, at best, an inappropriate control message.  At 
> worst, it would be an attack to attempt to gain control of the MG.  
> Also, I would like to note that an audit command would never be 
> construed as a failover.  Only a SC with a method of failover would be 
> a failover.
>
>
Where does the standard specify that 1 association = 1 IP address? 
Flemming is right, I think the association is poorly defined. It is 
"implied" that 1 association = 1 MGC, but this is precisely what leads 
to confusion when the MGC is multi-homed.

I scanned the document, the association is first mentioned in section 
7.2.8 under 5) Handoff, but with no prior definition, and no definition 
is given further on. The definition you quote from Annex F (why is it 
not in the main document?) doesn't address my question either. Hence, 2 
possible interpretations for the MEGACO control association:

1) I am inclined to interpret this as 1 association = 1 MGC = 1 FQDN 
(where a number of MGC-FQDN pairs can be provisioned on the MG). In this 
case, if the FQDN yields 2 IP addresses through DNS, then the MGC is 
multi-homed and the MG would know that. The MG can either create one 
SCTP association with the MGC, which would then take care of all the IP 
addresses, or (if SCTP is not supported) it could emulate this behavior 
using UDP. The latter obviously requires new procedures, quite simple in 
fact. But this would be very beneficial, because it would allow a 
redundancy schema with very robust and efficient switchover between 
signaling paths. Many MGs/MGCs could do this today easily, but there are 
interop problems because the exact procedures are not clearly stated.

2) If on the other side you would rather have it as 1 association = 1 IP 
address, then the standard should say that 1 MGC = 1 FQDN which should 
always yield exactly 1 IP address (otherwise it makes no sense). Also 
that a multi-homed MGC should be viewed as 2 distinct MGCs, with 2 
FQDNs, 2 IP addresses.

3) Lacking all that, the standard could at least say that multi-homed 
MGs are just not addressed, which leaves the possibility that procedures 
may be defined in future extensions. I keep telling people that this is 
the case,

In other words, in the current standard the model is not clear (the 
arity of these relationships), which is quite important.

I would prefer 1), because this is more uniform whatever the transport 
is. Under 2), SCTP doesn't even make much sense, it doesn't buy you much.

> Yes, however there are ways around this problem (by design, Megaco 
> chose to only have the MG be able to initiate the control association, 
> so you just need to make sure it does that - see H.248.14 for a solution).
>
> 1. Only the statically provisioned list of backup MGCs can be 
> contacted, and only in the order they were provisioned.
>
> 2. The spec is silent on whether a backup MGC replicates the state of 
> the primary or not. Consequently, you cannot assume that it does, and 
> hence switching to the backup is something you don't want to do 
> prematurely.
>
> [KJBII] Why is this the MGs concern?  The backup MGC is responsible 
> for getting itself attuned to the current state of affairs on the MG.  
> This can be done in any number of ways, some of which are more 
> detrimental to existing connections than others.
>
> 3. The switchover is not graceful, i.e. there has to be a failure 
> before you start contacting the backup. In contrast, a more robust 
> redundancy scheme would detect/suspect the failure earlier during 
> retransmission and switch to one of the backups to prevent any loss of 
> state. Furthermore, there should be a way of indicating that a backup 
> is fully redundant and hence the switchover can be done fairly early 
> without any risk.
>
> [KJBII] Hmmm.  How would the MG know that the retransmissions were due 
> to MGC failure, as opposed to network congestion?  I believe that the 
> MG will have to wait for the retransmissions to run their course, or 
> to utilize a different method of determining that the MGC had failed 
> that eliminates network congestion as a possibility.
>
>
> [KJBII] Not true.  Any NEW event detections would go to the "new" 
> MGC.  Remember, events in H.248 persist until a new events descriptor 
> is sent to replace the old.  Therefore, even through a 
> handoff/failover, the MG should continue to scan for events and report 
> them to the controlling MGC -- the "new" MGC once the handoff/failover 
> occurs.
>
For new event notifications, I agree with you that this should be the 
behavior. But can you point out the text that backs your statement? 
Because I've been pointed to the text I quoted above by an MG vendor, as 
a reason to implement it the other way around (continue to send  events 
to the old IP address). And yes, I'm talking about the same events 
descriptor that persists.

For replies and their retransmissions, I don't know ... For example, if 
you send an audit just to check for connectivity on a given path 
(A2-A2), then it would be important that replies go back where the 
request came from. So maybe the text I quoted should not put replies and 
indications in the same bin.

> I agree (and actually, I'm surprised nobody has addressed it yet 
> because it has been known for a long time and pops up on the mailing 
> list from time time, but without much progress being made).
>
> -- Flemming
>
> [KJBII] There are many possibilities for redundancy -- multihoming is 
> not the only one.  Further, I don't see how the rules don't work, or 
> how we can optimize this particular case without penalizing the other 
> possibilities.  The MG should not know, or care, that the MGC is 
> multihomed.  The same goes for the MGC with respect to the MG.  If you 
> change IP addresses, then you change control association, and that has 
> consequences that have to be rectified by the MGC.
>
I tend to disagree with this, see comments above. Again, you imply that 
1 association = 1 IP address, but if this is the case, it must be stated 
clearly.

---

From: Adrian Soncodi <[email-masked]>
Date: Thu, 24 Apr 2003 14:48:04 -0500

More comments inline.

Adrian

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 24 Apr 2003 18:04:47 -0500

I disagree with the notion that MEGACO spec fails to address
multi-homing. Multi-homing is elegantly addressed by using SCTP
(specified in H.248 Annex H). One of the reasons for having SCTP in IETF
is to relieve other upper layer protocols, such as MEGACO, from the
complicated task of dealing with multi-homing. 

I'd call it a bad strategy if now some one would insist on using UDP and
duplicate the multi-homing handling complexity of SCTP inside MEGACO
before calling it adequately addressed.

-Qiaobing

Adrian Soncodi wrote:
> > association is not very well defined when it comes to UDP; how do
> > you determine if a message received is part of the UDP control
> > association ?
> >
> > [KJBII] H.248 control associations have absolutely nothing to do
> > with transport.  To quote from the most recent version of Annex F:
> > "A control association is a communication relationship whereby an
> > MGC is controlling an MG.  A control association is instantiated via
> > out of service, being successfully handed off to an alternate MGC,
> > or successfully failing over to an alternate MGC.  An MG shall have
> > at most one control association at any time.  Only MGs may
> > instantiate control associations.  Control associations as defined
> > here apply only within the context of media gateway control
> > signalling.  This definition should not be confused with that of
> > control associations in the context of transport (TCP, UDP, etc.)."
> >
> > associations are established by the MG, the communication from
> > MGC-A2 should be viewed as, at best, an inappropriate control
> > message.  At worst, it would be an attack to attempt to gain control
> > of the MG.  Also, I would like to note that an audit command would
> > never be construed as a failover.  Only a SC with a method of
> 7.2.8 under 5) Handoff, but with no prior definition, and no
> definition is given further on. The definition you quote from Annex F
> (why is it not in the main document?) doesn't address my question
> either. Hence, 2 possible interpretations for the MEGACO control
> association:
> 
> (where a number of MGC-FQDN pairs can be provisioned on the MG). In
> this case, if the FQDN yields 2 IP addresses through DNS, then the MGC
> is multi-homed and the MG would know that. The MG can either create
> one SCTP association with the MGC, which would then take care of all
> the IP addresses, or (if SCTP is not supported) it could emulate this
> behavior using UDP. The latter obviously requires new procedures,
> quite simple in fact. But this would be very beneficial, because it
> would allow a redundancy schema with very robust and efficient
> switchover between signaling paths. Many MGs/MGCs could do this today
> easily, but there are interop problems because the exact procedures
> are not clearly stated.
> 
> 2) If on the other side you would rather have it as 1 association = 1
> IP address, then the standard should say that 1 MGC = 1 FQDN which
> should always yield exactly 1 IP address (otherwise it makes no
> sense). Also that a multi-homed MGC should be viewed as 2 distinct
> MGCs, with 2 FQDNs, 2 IP addresses.
> 
> MGs are just not addressed, which leaves the possibility that
> procedures may be defined in future extensions. I keep telling people
> that this is the case,
> 
> > [KJBII] Megaco and MGCP are not the same.  There are many
> > differences between the two protocols, and this just happens to be
> > one of them.
> >
> > >
> > chose to only have the MG be able to initiate the control
> > association, so you just need to make sure it does that - see
> > H.248.14 for a solution).
> >
> > 2. The spec is silent on whether a backup MGC replicates the state
> > of the primary or not. Consequently, you cannot assume that it does,
> > and hence switching to the backup is something you don't want to do
> > prematurely.
> >
> > for getting itself attuned to the current state of affairs on the
> > MG.  This can be done in any number of ways, some of which are more
> > retransmission and switch to one of the backups to prevent any loss
> > of state. Furthermore, there should be a way of indicating that a
> > backup is fully redundant and hence the switchover can be done
> > fairly early without any risk.
> >
> > [KJBII] Hmmm.  How would the MG know that the retransmissions were
> > due to MGC failure, as opposed to network congestion?  I believe
> > that the MG will have to wait for the retransmissions to run their
> > course, or to utilize a different method of determining that the MGC
> > had failed that eliminates network congestion as a possibility.
> >
> >
> > MGC.  Remember, events in H.248 persist until a new events
> > descriptor is sent to replace the old.  Therefore, even through a
> > handoff/failover, the MG should continue to scan for events and
> > report them to the controlling MGC -- the "new" MGC once the
> > handoff/failover occurs.
> >
> Because I've been pointed to the text I quoted above by an MG vendor,
> as a reason to implement it the other way around (continue to send
>  events to the old IP address). And yes, I'm talking about the same
> events descriptor that persists.
> 
> For replies and their retransmissions, I don't know ... For example,
> if you send an audit just to check for connectivity on a given path
> request came from. So maybe the text I quoted should not put replies
> and indications in the same bin.
> 
> > >
> > [KJBII] There are many possibilities for redundancy -- multihoming
> > is not the only one.  Further, I don't see how the rules don't work,
> > or how we can optimize this particular case without penalizing the
> > other possibilities.  The MG should not know, or care, that the MGC
> > is multihomed.  The same goes for the MGC with respect to the MG.
> > If you change IP addresses, then you change control association, and
> > that has consequences that have to be rectified by the MGC.
> >
> I tend to disagree with this, see comments above. Again, you imply
> that 1 association = 1 IP address, but if this is the case, it must be
> stated clearly.
>

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 24 Apr 2003 18:04:47 -0500

-Qiaobing

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 24 Apr 2003 20:19:06 -0400

> before calling it adequately addressed.

If SCTP support was an integral part of and mandatory in Megaco, then I'd
agree with that, however it's not; TCP and UDP are.

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 24 Apr 2003 20:19:06 -0400

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 24 Apr 2003 20:53:06 -0400

> Subject: Re: [Megaco] Support for redundant MG failover

<snip>

> transport.

Why not ? If I'm using TCP, then how can anything be sent outside that
TCP connection in either direction ?

> To quote from the most recent version of Annex F: "A control
> association is a communication relationship whereby an MGC is

I think you need to throw in a bit more text and perhaps some examples.
The above doesn't make it a whole lot clearer exactly what a control
association is and the semantics it carries with it.

> should be viewed as, at best, an inappropriate control message.

How does the MG "know" that the message comes from MGC-A2 and not MGC-A1
? Is that simply based on the mID in the message header ? If so, the
concept of a control association seems a bit fluffy (anybody can put
whatever name they want in there). If not, what is it based on ?

> At worst, it would be an attack to attempt to gain control of the MG.

OK, however I'm still missing a clear definition of exactly what a
control association is, and how the MG determines if a message it is
either sending or receiving is part of an existing control association.

> [KJBII] This is bad because?

1. Provisioning in general is bad.
2. The backups cannot be changed dynamically which is problematic in
lots of cases. For example, if I need to change the list of backups due
to upgrades, failures, etc., there's no simple or dynamic way of doing
this. Another example could be that each (or some) of the backups
represent alternative interfaces for a single MGC. How do I now redirect
my MG to not contact any of these interfaces ? Can't be done.

and the list goes on.

> detrimental to existing connections than others.

It's a concern because a failure to receive a response may occur for any
number of reasons (as you note below), e.g. interface failure, network
problems, or MGC failure. If you knew, that some of the addresses belong
to the same MGC (which could be a cluster of boxes), then upon not
receiving a response, you could quickly move on to another interface
without any risk. In this way, interface failures and local network
problems that do not affect all interfaces are not catastrophic. As for
a backup MGC to audit an MG to figure out what is going, this is first
of all a time-consuming and resource-intensive task, and secondly it
will not allow for a transparent failover in all cases, let alone
restore the call state that existed on the failed MGC.

> that eliminates network congestion as a possibility.

Exactly. The MG will not be able to determine what the real problem is,
however in the event the problem only affects part of the MGC and
communication to a different interface is possible, allowing/requiring
the MG to move on quickly to the next interface is very helpful.

> them to the controlling MGC -- the "new" MGC once the handoff/failover

Right, but what about old ones that are in the process of being
retransmitted and/or new ones being generated before the new control
association is up ? They should of course go to the new MGC as well, but
does the spec actually say that (it may be implied by the control
association, but if not already specified explicitly, it would be worth
doing so) ?

> consequences that have to be rectified by the MGC.

I disagree and based on this thread as well as similar ones in the past,
so do others it seems. As an aside, MGCP specified these things in great
detail, and I have yet to hear anybody complain that it is overly
restrictive in its support for multihoming and redundancy. On the
contrary. The same can easily be done for Megaco.

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 24 Apr 2003 20:53:06 -0400

<snip>

and the list goes on.

-- Flemming

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 24 Apr 2003 20:18:57 -0500

> agree with that, however it's not; TCP and UDP are.

Then, is multi-homing support "an integral part of and mandatory in
Megaco"? 

It seems to me there are only two options: 1) if people feel that
multi-homing should be made "an integral part of and mandatory in
Megaco", then the solution could be to simply make SCTP "an integral
part of and mandatory in Megaco" and we are done. 2) if people feel that
multi-homing should be optional, then whenever/wherever one needs
multi-homing, he/she simply uses the "optional" SCTP transport and the
problem is solved. I don't see a case where more stuff needs to be built
into MEGACO. In other words, either way I see MEGACO spec as complete
and adequate.

-Qiaobing

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 24 Apr 2003 20:18:57 -0500

-Qiaobing

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 25 Apr 2003 08:50:49 -0400

Qiaobing Xie wrote:

> problem is solved.

Those are indeed two options, and from a theoretical point of view, there is no
doubt this is the cleanest solution. Having said that, the original question was
whether Megaco has adequate built-in support for redundancy and failover. Some
claimed it did, however they have yet to show how it would actually work let
alone where it is specified, and you seem to agree that without SCTP, there are
indeed holes here.

> I don't see a case where more stuff needs to be built

So is it consensus that Megaco needs SCTP in order to properly support
multihoming/redundancy/failover, and there should be no further specification of
how that might be achieved using UDP/TCP instead ?

On a related note:    When the concept of a control association is clarified,
please make sure that the clarification explicitly covers SCTP operation as
well.

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 25 Apr 2003 08:50:49 -0400

-- Flemming

---

From: Adrian Soncodi <[email-masked]>
Date: Fri, 25 Apr 2003 11:31:19 -0500

>please make sure that the clarification explicitly covers SCTP operation as
And the number of FQDNs and IP addresses per MGC. Also clarify what 
happens if a DNS query returns more than 1 IP address for an MGC 
(assuming SCTP is not supported, is only the first one considered)?
This is important for the MEGACO MIB. The one that is currently in the 
works actually does specify a single IP address per MGC. If SCTP is 
supported, then there should be more ... But I wouldn't expect the MIB 
document to clarify what the model is, I think it should just reflect 
the model as per the main document.

Adrian

---

From: Adrian Soncodi <[email-masked]>
Date: Fri, 25 Apr 2003 11:31:19 -0500

Adrian

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 25 Apr 2003 14:41:26 -0500

...
> alone where it is specified, and you seem to agree that without SCTP, there are

SCTP is part of the solution. Therefore, if you take SCTP out of the
picture, of cause you will see (big) holes :-)

> multihoming/redundancy/failover, 

SCTP only gives you multi-homing support (which you can view as
providing link level redundancy). For app-level redundancy/failover such
as clustering, active/standby, pooling support, SCTP will not help you.
Instead, RSERPOOL WG is currently working on a generic solution for this
type of app-level redundancy/failover support.

> and there should be no further specification of

When SIGTRAN was started (at about the same time MEGACO did), people
asked similar question, and debated extensively over the following
options: a) re-design UDP/TCP to add multi-homing support; b) let each
upper layer protocol to build its own internal multi-homing support; and
c) to create a generic general transport that supports multi-homing. And
the consensus was option c) and the result is SCTP. MEGACO left SCTP
transport in an annex because SCTP was under development at the time
MEGACO was decided. In terms of stack availability, there are commercial
SCTP and MEGACO/SCTP stacks in the market.

-Qiaobing

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 25 Apr 2003 14:41:26 -0500

-Qiaobing

---

From: Adrian Soncodi <[email-masked]>
Date: Fri, 25 Apr 2003 15:01:19 -0500

Consider the provisioning, i.e. the MEGACO MIB. If SCTP is supported 
(either mandatory or optional), the MIB would need to allow an MG to 
have 2 or more IP addresses for the same MGC. So there you go, whether 
you like it or not, the MG is aware that the MGC is multi-homed. It has 
to be, since you cannot have one SCTP association to several machines, 
they wouldn't be able to handle the sequence numbers.

Next, consider an MG which supports all the transport protocols. It may 
work with MGCs that support only some of the protocols.
- If a multi-homed MGC supports SCTP, then it can be modeled as 1 MGC 
with multiple IP addresses.
- If the MGC supports only UDP, then why does the MGC have to be modeled 
differently, i.e. as 2 MGCs, each with only one IP address?
This only forces the MGC to handoff to itself, which has some issues as 
I mentioned before.

I think the clean way to address this is as follows:
- Define the "MEGACO control association", a number of people agreed on 
this.
- In the main document, define the handoff/failover procedures in terms 
of the control association only (this separates them from the transport 
concepts). Clarify what happens to replies and event notifications on 
switchover, what happens when the MG is audited from outside the control 
association etc. (see the issues raised previously).
- For each transport protocol (because there is a section or annex 
anyway), detail how the control association works and is maintained, and 
here is where one or more IP addresses get involved.

In the UDP case, there is no real "complexity" for a uniform approach of 
multi-homing, the MG only needs to accept commands from either IP 
address, and to be safe always reply to the source address. Most of the 
MGs/MGCs can do this today, but the handoff gets in the way e.g. because 
subsequent event handling is not clear.

This layered approach seems to me quite elegant and natural. I don't 
think multihoming over UDP should be excluded just "because". So far, 
there are not many implementations of MEGACO over SCTP.

Adrian

---

From: Adrian Soncodi <[email-masked]>
Date: Fri, 25 Apr 2003 15:01:19 -0500

Adrian

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 25 Apr 2003 15:11:15 -0500

Adrian Soncodi wrote:
> you like it or not, the MG is aware that the MGC is multi-homed. It
> has to be, since you cannot have one SCTP association to several
> machines, they wouldn't be able to handle the sequence numbers.
> 
> Next, consider an MG which supports all the transport protocols. It
> may work with MGCs that support only some of the protocols.
> - If the MGC supports only UDP, then why does the MGC have to be
> modeled differently, i.e. as 2 MGCs, each with only one IP address?
> This only forces the MGC to handoff to itself, which has some issues
> as I mentioned before.

Here is an example that shows why you would prefer to have all this
multi-homing thing be transparent to (i.e., hidden away from) MEGACO.
This is the whole idea of having SCTP that relieves the upper layer from
worrying about how to deal with individual IP address(es). MIB should
definitely be built to be able to deal with the MEGACO over SCTP case.

....
> there are not many implementations of MEGACO over SCTP.

I hope this will change as people start to be more interested in
redundancy and their system availability. 

For some one who's thinking of deploying MEGACO and also worrying about
multi-homing for the sake of system availability, you seem to imply that
there are two choices here: a) to pick a MEGACO implementation that
supports SCTP, or b) to modify/re-work MEGACO spec to add an internal
UDP-based multi-homing and then wait for some one to implement the new
mechanism. I don't see how choice b) is in any way more available or
easier than a).

-Qiaobing

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 25 Apr 2003 15:11:15 -0500

....

-Qiaobing

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 25 Apr 2003 16:27:26 -0400

> picture, of cause you will see (big) holes :-)

For sure SCTP can solve these problems, but having been involved in the early days of
Megaco, allow me to straighten out the facts a bit here: SCTP was never part of
Megaco, neither in design, nor specification. It always has been and to date remains
an optional add-on that came to the table later on. The lack of references to SCTP in
the Megaco spec makes that pretty evident too.

> type of app-level redundancy/failover support.

This is well-understood, however just like you can have multihoming support without
SCTP, you can have redundancy/failover support without RSERPOOL. Megaco actually
includes some support for this in the form of a statically provisioned list of backup
MGCs.

> the consensus was option c) and the result is SCTP.

Sure, but please don't confuse the generic discussions about this problem that took
place in SIGTRAN with the specific discussions that took place in Megaco.

> MEGACO left SCTP
> MEGACO was decided.

I'm not sure it's worth debating this issue, but suffice it to say that this is not
quite how things transpired. In any case, SCTP is there as an option today for those
that wish to use it. For those that don't, we've already concluded that
multihoming/redundancy/failover is not very well supported, and that there doesn't
seem to be much desire to change that. I personally think that's a bit of a shame, but
so be it.

-- Flemming

> In terms of stack availability, there are commercial

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 25 Apr 2003 16:27:26 -0400

-- Flemming

---

From: Adrian Soncodi <[email-masked]>
Date: Fri, 25 Apr 2003 15:49:07 -0500

>mechanism. I don't see how choice b) is in any way more available or
Because a) implies adapting a whole new stack in the system, while b) is 
just a few lines of code change, and many MGs have already done this. 
Furthermore, due to the fact that the spec is incomplete in this area, 
b) is not even a violation of the standard, it's probably just a very 
small extension/clarification. So a couple of sentences in the main spec 
could make this officially a valid solution, along with a), which we 
should obviously keep.

You seem to say "if you want multi-homing, it must be only over SCTP". 
Why? Someone could similarly say "if you want MEGACO, it must be over 
UDP". But we don't, we allow all 3 protocols, for flexibility.

Adrian

---

From: Adrian Soncodi <[email-masked]>
Date: Fri, 25 Apr 2003 15:49:07 -0500

Adrian

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 25 Apr 2003 20:10:26 -0500

(Try to respond to similar remarks from two mails)

> In any case, SCTP is there as an option today for those
...

Adrian Soncodi wrote:
...
> UDP". But we don't, we allow all 3 protocols, for flexibility.

I didn't mean to say "you must". I was under the impression that some of
us were saying that we had a technical issue to support multi-homing in
MEGACO, and my response was essentially "this is not an issue, there are
protocol specs existing in IETF to do just that, which is
MEGACO/H.248-Annex-H plus SCTP." Now, I think what I am hearing is, it
is not really about the lack of a solution, it's more about that some of
us just don't want to use the existing IETF solution (for whatever
non-tech reasons, or simply just don't wish to use it) and prefer to
define another solution in IETF. Well, if that is the case, I don't have
much else to say... 

Of cause, if there are tech issues/shortcomings/drawbacks/advantages
related to using SCTP for MEGACO multi-homing support, I'd be more than
glad to help answer.

-Qiaobing

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 25 Apr 2003 20:10:26 -0500

...

Adrian Soncodi wrote:
...

-Qiaobing

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 25 Apr 2003 22:45:09 -0400

Qiaobing

Nobody is denying that SCTP is an existing spec that solves the multihoming problem and it
is quite understandable that you in particular advocate it. However, you seem to have lost
sight of the original question in this thread, which was about native Megaco protocol
support for redundancy and failover, and as part of that, support for multihoming. Initial
claims was that Megaco fully supports this, but we seem to have converged on the opinion
that it does not, unless you use SCTP, which is not part of the base Megaco protocol.
Furthermore, despite everything, the fact of the matter is that for various reasons, not
everybody will be implementing SCTP at least for now (NATs, firewalls and security do not
help SCTP here) and since UDP and TCP are the basic requirements, it would have been nice to
have better mechanisms for these; it can be done very easily (see MGCP for example).
Sometimes, it's good to be a bit pragmatic.

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 25 Apr 2003 22:45:09 -0400

Qiaobing

-- Flemming

---

From: Fernando Vallejo Lazaro <[email-masked]>
Date: Mon, 28 Apr 2003 10:54:28 +0200

Hi,

I agree with Flemming that Megaco should be based on UDP and TCP.
SCTP is not widely deployed and can lead to problems of interoperability.
I would leave it as optional.

For me the control association is clearly defined and it is 1 association = 1 IP address.
Why? Because the assocation is done through a ServiceChange Restart message which involves
an IP address (in the MGC ID)  and not a domain name. If the DNS returns more than
one IP address for a given name the MG must choose one of them.

What I feel is that the gap is in the definition of the secondary MGCs and its provisionning.
I think there should be a way in which the MGC could inform the MGs about existing secondaries
MGCs. Now this can only be done using a  HandOff method but sometimes this message cannot
be sent by the primary MGC (e.g. network failure, crash of the MGC ...).
So it would be useful to add a new method in the ServiceChange to send this information and add

a new parameter indicating what type of relationship there is between primary and secondary
(e.g. mirror, backup, independent, third party.....)
So in case a MGC is multihomed it could inform the MG at startup that a MGC exists which is a
secondary mirror MGC (which corresponds to the same MGC but with another IP address).
This process can be independent on the actual procedures done by the operators to declare
secondary MGCs.

When a problem arises the MG can act in two ways:
1) If the new MGC is a mirror (maybe other types can be included here) it can resend the
transactions
which have failed in the old one.
2) If the new MGC is not a mirror it should try to establish a connection with a ServiceChange
as defined
in the megaco protocol. Then the MGC is in charge of recovering the state of the MG ASAP and
the service.

In this way not too much work has to be added and we can accomplish a solution.

Regards
Fernando

--
Fernando Vallejo Lazaro
Phone:  +34 91 330 5614
SW  Wireline ASD-Madrid
       ALCATEL

---

From: Fernando Vallejo Lazaro <[email-masked]>
Date: Mon, 28 Apr 2003 10:54:28 +0200

Hi,

Regards
Fernando

--
Fernando Vallejo Lazaro
Phone:  +34 91 330 5614
SW  Wireline ASD-Madrid
       ALCATEL

---

From: Adrian Soncodi <[email-masked]>
Date: Mon, 28 Apr 2003 17:41:13 -0500

> one IP address for a given name the MG must choose one of them.
This is how one would be tempted to interpret the spec today, although 
it is not explicitly stated. But as I have mentioned in a previous 
e-mail, this is not adequate for SCTP, where one would like to know that 
the 2 IP addresses are on the same machine, to be able to use them 
within a single SCTP association.

Also, the following quote from section 7.2.8 seems to indicate more than 
1 IP address is possible:

  "The ServiceChangeAddress provides an address to be used within the 
Context of the association currently being negotiated ..."

Since this is in the reply to ServiceChange, it looks like it can 
actually be a different IP address (which then must be interpreted in 
the context of the current association ...). Otherwise, why would the 
MGC return the same IP address as the destination IP address of the 
ServiceChange message? The MG already knows that one!

> This process can be independent on the actual procedures done by the 
I'm not sure a "mirror MGC" is the same MGC with another IP address. 
Some people would interpret "mirrored" as different machines, with some 
state synchronization between them...

Anyway, considering 2 or more multi-homed MGCs, i.e. 4 or more IP 
addresses, and if each IP address is a different MGC, then it becomes 
quite cumbersome to signal which one is paired with which one. I think 
it would be simpler and more clear to allow an MG to be provisioned with 
more than one IP address per MGC. Then you would immediately know the 
MGC is multi-homed. This works more elegantly with SCTP, and also with 
DNS, which can return several IP addresses for an FQDN.

Adrian

> 1) If the new MGC is a mirror (maybe other types can be included here) 
> it can resend the transactions
> 2) If the new MGC is not a mirror it should try to establish a 
> connection with a ServiceChange as defined
> in the megaco protocol. Then the MGC is in charge of recovering the 
> state of the MG ASAP and the service.
>

---

From: Adrian Soncodi <[email-masked]>
Date: Mon, 28 Apr 2003 17:41:13 -0500

Adrian