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

From: Steve Cipolli <[email-masked]>
Date: Thu, 1 May 2003 17:14:54 -0400

My understanding of both MGCP and MEGACO is that neither has a mechanism to
distinguish multihomed interfaces from redundant MGCs/MGs.  In MGCP the list
of IP addresses returned for a given domain name may be a set of
(multihomed) interfaces, a set of redundant MGCs/MGs, or some combination of
both.  In MEGACO the provisioned list of MGCs in an MG has this exact same
property.  

I do see the fact that MEGACO MGCs have no mechanism to contact MGs on
multihomed interfaces as a significant deficiency.  I agree that mapping a
list IP addresses returned from a domain name to the set of interfaces
supported by a MEGACO association would be benefical, but the problem of how
to distinguish multihomed interfaces from redundant MGs/MGCs still remains
unclear to me (for both MEGACO and MGCP).

--Stephen

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Thursday, April 24, 2003 11:04 AM
> To: Adrian Soncodi
> Cc: Megaco
> Subject: Re: [Megaco] Support for redundant MG failover
> 
> 
> 
> 
> Adrian Soncodi wrote:
> 
> > Hello, all,
> >
> > I was wondering what is your oppinion on the following:
> >
> > Another topic that is not addressed in the MEGACO spec is 
> the case of
> > a multi-homed MG, i.e. an MG where:
> > - the primary controller has 2 physical interfaces A1 and A2,
> > potentially on 2 different subnets, working in load-sharing mode
> > (rather than active-standby)
> > - the secondary MG controller can then be either transparrent (it
> > takes over A1 and A2 on switchover) or non-transparent (has 2 more
> > physical addresses, B1 and B2).
> >
> > One may argue that multi-homing is not necessary, for 
> example because
> > you can always assign a single "logical" IP address A that is
> > reachable over both interfaces A1 and A2. Yes, but this schema
> > requires some dynamic IP routing capability in the backbone (e.g. to
> > figure out when A1 is down and packets for A should be 
> routed to A2),
> > which has a number of disadvantages:
> > - Depending on the routing protocol, the latency for dynamic updates
> > of the addresses can be very large (180 seconds in case of RIP),
> > unacceptable for telephony.
> > - Depending on the network topology, interface failures may 
> not become
> > visible in the backbone. For example, if there is a LAN 
> switch between
> > the MG and the first router, then the router does not see when the
> > interface A1 fails (unless the dynamic routing domain is extended to
> > include the MG, which is not always the case).
> > - Some service providers (especially the smaller ones) do not run a
> > dynamic IP routing protocol in their (whole) backbone, or 
> they may not
> > even have a real backbone, for example they may use leased lines, IP
> > over ATM/FR PVCs with no sophisticated routing capabilities.
> >
> > On the other hand, making the physical addresses A1 and A2 visible
> > allows for redundant signaling paths to the MG using only static IP
> > routing in the network, which in certain situations is desirable.
> >
> > The MGC-MG redundancy schema gets even more complicated if you
> > consider that the MGC can be multi-homed too. Effectively, 
> it can have
> > the same A1, A2, B1, B2 schema as the MG. In this case, 
> what is really
> > useful is an SCTP association (MGC-A1, MGC-A2, MG-A1, 
> MG-A2), because
> > this takes care of all the combinations. But if the MG supports only
> > UDP, it is not clear from the standard how to emulate this SCTP
> > behavior. For example:
> > - Some MGs do a DNS query for the MGC name, get 2 IP addresses in
> > response, but they just ignore the second IP address, thus ignoring
> > that the MGC is multi-homed.
> > - Other MGs consider the IP addresses as being 2 different MGCs,
> > rather than one multi-homed MG. The problem is that they 
> only talk to
> > one MGC at a time, and then they need a "handover" to 
> switch. So while
> > talking on A1-A1, the MGC cannot for example audit on A2-A2, because
> > this is immediately considered a failover (causing for example the
> > pending notifications to be lost). The MGCP spec, for example,
> > explicitly states that an MG should not change its 
> controlling entity
> > when being audited from another IP address (and it doesn't 
> say whether
> > this is a different MGC or the same multi-homed MGC).
> >
> > I think what needs to be clarified here is:
> > - Whether an MG/MGC can be multi-homed and how to handle 
> its multiple
> > IP addresses.
> > - Whether an MG/MGC with active-standby controllers, transparent or
> > non-transparent switchover, are considered one MG/MGC or 2 MG/MGCs
> > - Whether a domain name for an MG/MGC which yields more than one IP
> > address through DNS, is associated with one controller, or with an
> > active-standby pair, or possibly even with more 
> active-standby pairs.
> >
> 
> I agree - these are rather big holes in the current specs IMO.
> 
> 
> >
> > The case with non-transparent MG controller switchover, as Flemming
> > mentioned, poses additional problems. For example, if the active MG
> > controller loses connectivity over A1 and A2, it may not 
> even notice,
> > because not all MGs do heartbeats. So if the MGC determines it can
> > actually talk to B1 and B2, it cannot force an MG controller
> > switchover, or at least the standard does not define the 
> procedure for
> > this. I would note that, in practice, however, most of the MGs and
> > MGCs have transparent switchover (there is no B1, B2, they reuse A1,
> > A2 ...).
> >
> > The MGCP spec is a little more explicit on how the IP addresses are
> > handled. So I don't understand why this topic is outside 
> the scope of
> > MEGACO.
> >
> 
> Right. I have always thought it was unfortunate, that Megaco did not
> specify anything about use of multiple IP addresses and/or interfaces
> (apart from the static provisioning of backup MGCs) as this limits the
> robustness of the protocol when using UDP/TCP. I was hoping 
> that Annex F
> would rectifiy some of that, but it doesn't seem like it.
> 
> >
> > I raised these issues because, from my experience, every 
> single vendor
> > interprets them differently, and MGC-MG redundancy is a delicate
> > subject. Any suggestions?
> 
> 1. Continued discussion on the mailing list (preferably with 
> more input
> from some of the traditional Megaco gurus).
> 2. Write a contribution for SG16 addressing this.
> 3. Forget about TCP and UDP and just use SCTP.
> 
> -- Flemming
> 
> 
> _______________________________________________
> 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: Flemming Andreasen <[email-masked]>
Date: Thu, 01 May 2003 18:08:35 -0400

> both.  In MEGACO the provisioned list of MGCs in an MG has this exact same

I'm not sure the capabilities of MGCP are relevant to this discussion, but since
you asked:
- The set of IP addresses associated with a domain name, and for which
retransmission and failover procedures are defined in MGCP, are assumed to
belong to the same logical MGC. The MGC may be one or more machines each with
one or more interfaces.
- In order to failover to a backup MGC, "vanilla" MGCP would have the backup MGC
contact the MG.
- Alternatively, the NotifiedEntityList parameter defined in the MGCP Redirect
and Reset package (draft-foster-mgcp-redirect-02.txt) allows you to provide a
set of domain names the MG can contact (as opposed to just one in the
NotifiedEntity parameter). The multiple domain names can either represent the
same and/or  multiple different MGCs. The key with this extension is that the
domain names are contacted in an ordered fashion.

> unclear to me (for both MEGACO and MGCP).

See above for MGCP. For Megaco, I agree and would propose that something along
the lines of what has been defined for MGCP could be used.

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 01 May 2003 18:08:35 -0400

-- Flemming