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

From: Tom Taylor <[email-masked]>
Date: Tue, 13 May 2003 14:35:13 -0400

It seems to me that the outlines of a solution have been sketched in Fernando's 
note.  Al the information to support multi-homing and the associated behaviour can 
be introduced through a set of ROOT properties that can be either provisioned on the 
MG or set there after the initial control association has been established.

Adrian Soncodi wrote:
> 
> 
> Fernando Vallejo Lazaro wrote:
> 
>> 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.
>>
> 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!
> 
>> 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.
>>
> 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
> 
>> 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
>>  
>>
>> Flemming Andreasen wrote:
>>
>>> 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
>>>
>>> Qiaobing Xie wrote:
>>>
>>> > (Try to respond to similar remarks from two mails)
>>> >
>>> > Flemming Andreasen wrote:
>>> > ...
>>> > > 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.
>>> > ...
>>> >
>>> > Adrian Soncodi wrote:
>>> > ...
>>> > > 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.
>>> > >
>>> >
>>> > 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
>>>
>> -- 
>> Fernando Vallejo Lazaro
>> Phone:  +34 91 330 5614
>> SW  Wireline ASD-Madrid
>>       ALCATEL
>>
>>  
> 
> 
> 
> 
> _______________________________________________
> 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: Tom Taylor <[email-masked]>
Date: Tue, 13 May 2003 14:35:13 -0400

---

From: Adrian Soncodi <[email-masked]>
Date: Tue, 13 May 2003 15:34:08 -0500

Tom Taylor wrote:

> It seems to me that the outlines of a solution have been sketched in 
> Fernando's note.

Tom,

I don't quite understand, can you elaborate on this statement? I was 
trying to make the point that, for multi-homing, we could allow 2 or 
more IP addresses per MG and/or MGC, which would make it simpler to 
establish for example one SCTP association using all of them.

Initially, Fernando said that 1 MEGACO control association = 1 IP 
address, and implied that 2 IP addresses would be viewed as 2 distinct 
MGCs. But in this case:
- explaining which MGC pairs with which other MGC as multi-homed 
entities is more difficult,
- plus, if an SCTP association uses more than 1 IP address (which it 
should, in order to take advantage of multi-homing), then it would mean 
that 1 control association spans 2 MGCs, which seems to contradict the 
model. Handoff and failover wouldn't work in this case, because MEGACO 
does not control the selection of the IP addresses withing the SCTP layer.

Therefore, what do you think about the number of IP addresses per 
MG/MGC? If SCTP is allowed to use only one IP address per entity, then 
why would one ever use SCTP instead of TCP? My understanding is SCTP was 
supposed to be a solution for multi-homing.

Additionally (I don't know if you followed the whole discussion in this 
thread), a number of people have expressed interest in supporting 
multi-homing over UDP too. This would also benefit from allowing 
multiple IP addresses per MG/MGC, but a few clarification in the 
procedures would be required. Would you be willing to consider adding 
this additional functionality?

Regards,

Adrian

> Al the information to support multi-homing and the associated 
> behaviour can be introduced through a set of ROOT properties that can 
> be either provisioned on the MG or set there after the initial control 
> association has been established.
>
>
> Adrian Soncodi wrote:
>
>>
>>
>> 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:
>>
>>> What I feel is that the gap is in the definition of the secondary 
>>> MGCs and its provisionning.
>>> MGCs. Now this can only be done using a  HandOff method but 
>>> sometimes this message cannot
>>> 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
>>> So in case a MGC is multihomed it could inform the MG at startup 
>>> that a MGC exists which is a
>> Some people would interpret "mirrored" as different machines, with 
>> some state synchronization between them...
>>
>> 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
>>> In this way not too much work has to be added and we can accomplish 
>>> a solution.
>>>
>>> Regards
>>> Fernando
>>>  
>>>
>>>> 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
>>>> that it does not, unless you use SCTP, which is not part of the 
>>>> base Megaco protocol.
>>>> 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
>>>> > > seem to be much desire to change that. I personally think 
>>>> that's a bit of a shame, but
>>>> > > so be it.
>>>> > ...
>>>> >
>>>> > Adrian Soncodi wrote:
>>>> > ...
>>>> > > Why? Someone could similarly say "if you want MEGACO, it must 
>>>> be over
>>>> > define another solution in IETF. Well, if that is the case, I 
>>>> don't have
>>>> > much else to say...
>>>> >
>>>> > related to using SCTP for MEGACO multi-homing support, I'd be 
>>>> more than
>>>> > glad to help answer.
>>>> >
>>>> > -Qiaobing
>>>>
>>> -- 
>>> Fernando Vallejo Lazaro
>>> Phone:  +34 91 330 5614
>>> SW  Wireline ASD-Madrid
>>>       ALCATEL
>>>
>>>  
>>
>>
>>
>>
>>

---

From: Adrian Soncodi <[email-masked]>
Date: Tue, 13 May 2003 15:34:08 -0500

Tom,

Regards,

Adrian

---

From: Tom Taylor <[email-masked]>
Date: Tue, 13 May 2003 20:34:56 -0400

Ok, I'll work a bit harder.

First point:  I'd say the control association is uniquely identified by the mId of 
each peer, but is associated with transport (and much other) state.  I've always 
thought of the mId part of the message as an identifier, not necessarily tied to an 
address, even if that is what the syntax suggests.  The syntax also allows an mId 
which is simply a NAME.  Hence I do not believe the protocol as it stands identifies 
a control association with a network address.

This means it is quite feasible to associate a control association with multiple 
addresses at either end.  The protocol has a way to allow you to express additional 
information of this sort if you need to pass it at the application level: you 
provide it as properties defined in a package.

Second point:  pre-start-up is by definition outside the scope of the protocol, 
since the protocol has yet to operate.  The SRV record approach used by SIP is only 
one alternative of a number that SIP offers.  All we can standardize (as we have 
already done) is that an initial condition for the operation of the protocol is that 
the MG knows what TRANSPORT (not NETWORK) address it should use to reach the MGC. 
How it determines that transport address is up to the implementation.

For SCTP the initial transport address used is that of the initial primary path. 
That doesn't prevent the use of multihoming; the peers supply the alternative 
addresses as part of the SCTP protocol exchange, and there is no need for Megaco to 
account for them explicitly.  If you want to use UDP instead of SCTP, you have to 
agree on a similar exchange of information.  I've already pointed out above how this 
could be done, by setting and reading of ROOT properties on the MG.

---

From: Tom Taylor <[email-masked]>
Date: Tue, 13 May 2003 20:34:56 -0400

---

From: Adrian Soncodi <[email-masked]>
Date: Wed, 14 May 2003 18:25:30 -0500

Tom Taylor wrote:

> First point:  I'd say the control association is uniquely identified 
> by the mId of each peer, but is associated with transport (and much 
> other) state.  I've always thought of the mId part of the message as 
> an identifier, not necessarily tied to an address, even if that is 
> what the syntax suggests.  The syntax also allows an mId which is 
> simply a NAME.  Hence I do not believe the protocol as it stands 
> identifies a control association with a network address.
>
> This means it is quite feasible to associate a control association 
> with multiple addresses at either end.  The protocol has a way to 
> allow you to express additional information of this sort if you need 
> to pass it at the application level: you provide it as properties 
> defined in a package.
>
> Second point:  pre-start-up is by definition outside the scope of the 
> protocol, since the protocol has yet to operate.  The SRV record 
> approach used by SIP is only one alternative of a number that SIP 
> offers.  All we can standardize (as we have already done) is that an 
> initial condition for the operation of the protocol is that the MG 
> knows what TRANSPORT (not NETWORK) address it should use to reach the 
> MGC. How it determines that transport address is up to the 
> implementation.

Indeed, I need to qualify: When I say "IP address", it's just a 
shorthand for "IP address + TCP/UDP/SCTP port", which is a transport 
address. So we are not really talking about network addresses.

>
> For SCTP the initial transport address used is that of the initial 
> primary path. That doesn't prevent the use of multihoming; the peers 
> supply the alternative addresses as part of the SCTP protocol 
> exchange, and there is no need for Megaco to account for them explicitly.

But this approach has one big disadvantage: If the interface 
corresponding to the initial transport address is down, you don't get to 
find out about additional alternative addresses in subsequent protocol 
exchanges. This substantially diminishes the usefulness of multi-homing 
for redundancy.

This problem could be avoided by allowing an MG/MGC to be provisioned 
with 2 or more transport addresses for the remote peer (and having the 
MG use them from the beginning, e.g. for the SCTP INIT). But people tend 
to think that the main spec does not allow more than one transport 
address (for example, the MEGACO MIB only specifies one per MG/MGC). So 
how should it be?

Adrian

> If you want to use UDP instead of SCTP, you have to agree on a similar 
> exchange of information.  I've already pointed out above how this 
>> address, and implied that 2 IP addresses would be viewed as 2 
>> distinct MGCs. But in this case:
>> should, in order to take advantage of multi-homing), then it would 
>> mean that 1 control association spans 2 MGCs, which seems to 
>> contradict the model. Handoff and failover wouldn't work in this 
>> case, because MEGACO does not control the selection of the IP 
>> addresses withing the SCTP layer.
>>
>> MG/MGC? If SCTP is allowed to use only one IP address per entity, 
>> then why would one ever use SCTP instead of TCP? My understanding is 
>> SCTP was supposed to be a solution for multi-homing.
>>
>> Additionally (I don't know if you followed the whole discussion in 
>> this thread), a number of people have expressed interest in 
>> supporting multi-homing over UDP too. This would also benefit from 
>> allowing multiple IP addresses per MG/MGC, but a few clarification in 
>> the procedures would be required. Would you be willing to consider 
>> adding this additional functionality?
>>
>> Regards,
>>
>> Adrian
>>
>>
>>> behaviour can be introduced through a set of ROOT properties that 
>>> can be either provisioned on the MG or set there after the initial 
>>> control association has been established.
>>>
>>>
>>> Adrian Soncodi wrote:
>>>
>>>>
>>>>
>>>>> Why? Because the assocation is done through a ServiceChange 
>>>>> Restart message which involves
>>>> 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.
>>>>
>>>>  "The ServiceChangeAddress provides an address to be used within 
>>>> the Context of the association currently being negotiated ..."
>>>>
>>>> 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!
>>>>
>>>>> I think there should be a way in which the MGC could inform the 
>>>>> MGs about existing secondaries
>>>>> This process can be independent on the actual procedures done by 
>>>>> the operators to declare
>>>>> secondary MGCs.
>>>>>
>>>> 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...
>>>>
>>>> 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
>>>>
>>>>> 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
>>>>>  
>>>>>
>>>>>> Furthermore, despite everything, the fact of the matter is that 
>>>>>> for various reasons, not
>>>>>> > > multihoming/redundancy/failover is not very well supported, 
>>>>>> and that there doesn't
>>>>>> > > You seem to say "if you want multi-homing, it must be only 
>>>>>> over SCTP".
>>>>>> > I didn't mean to say "you must". I was under the impression 
>>>>>> that some of
>>>>>> > is not really about the lack of a solution, it's more about 
>>>>>> that some of

---

From: Adrian Soncodi <[email-masked]>
Date: Wed, 14 May 2003 18:25:30 -0500

Adrian

---

From: "Jackson.liu" <[email-masked]>
Date: Mon, 19 May 2003 16:06:47 +0800

Dear Taylor:

Would please tell me the QoS, RSVP, Diffserv packages defined in MEGACO? How can I find it?

Thanks.

Jackson
UTStarcom Ltd. SZ R&D Office.
3/F, Legend Research & Developemnt Building, High-tect Industrial Park
Tel: (86-755)26983555-3599
Fax: (86-755)26983786
E-Mail: [email-masked]
_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "Jackson.liu" <[email-masked]>
Date: Mon, 19 May 2003 16:06:47 +0800

Dear Taylor:

Thanks.

Jackson