Subject: RE: [midcom] H.248 for midcom? Not.

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 6 Dec 2002 13:06:20 -0500

Well ...

This is just for conversation: I've never been terribly happy with the
distortions required to the Megaco model to make it work for midcom.  On the
other hand, Megaco is not a pure master/slave protocol, so your final words
bother me a bit.  The fact the MG is the boss when it comes to starting up
the control association is actually one of Megaco's black marks in this
application.

The problems with the Megaco model are clear, and I summarize them here as a
review in the light of the new information provided by the semantics work.

According to the semantics we have established, the life of a Policy Rule is
independent of the life of the Midcom session in which it was created.
Since the Midcom session is identified with the Megaco control association,
the modelling of Policy Rules in Megaco terms has to allow for such
independent existence.

The Midcom requirement to allow multiple agents to have access to the same
Policy Rule has no explicit constraint, as far as I can recall.  Our
semantics treat this as a matter of transactional exclusion on the one hand
and policy on the other.  What is missing is any statement that the owner of
the Policy Rule has to have terminated its session before another Agent can
have access to the rule.  I'm not proposing to add such a statement here.
But the implication for Megaco is that a Policy Rule cannot be identified
directly with either a Termination or a Context.  We (the Megaco authors)
have finessed this by positing a resource layer, manipulated by properties
of terminations created for that purpose.  The fact is that the resources
(i.e. Policy Rules) are a new architectural element, actually orthogonal to
anything else Megaco offers.

IF the missing constraint described in the previous paragraph were added, a
Policy Rule could be identified straightforwardly with a specific Megaco
Termination.  At that point, I think you would find that the fit with Megaco
is pretty good, but of course, there would be a lot of excess baggage.  The
problem with the direction of session initiation would remain.

> -----Original Message-----
> From: Eric Burger [mailto:[email-masked]] 
> Sent: Friday, December 06, 2002 10:48 AM
> To: IETF Midcom (E-mail)
> Subject: [midcom] H.248 for midcom? Not.
> 
> 
> Reviewing the MIDCOM protocol evaluation document, I had some 
> questions about the H.248 (megaco) analysis.
> 
> Requirement 2.1.3, "Middlebox can relate to multiple Agents", 
> refers to the ability for a set of agents to manipulate (in 
> H.248 parlance) the same end-point.  It is true, as described 
> in the document, that one can partition a media gateway into 
> multiple virtual media gateways (VMG).  By design, H.248 
> restricts a one-to-one association between a VMG and an 
> agent.  In addition, AFAIK the standard H.248 model has no 
> possibility for VMG's to have the same end-points.  This is 
> an architectural feature of H.248.  Even if you "extended" 
> H.248 to allow the same ephemeral end-point to be addressed 
> by two VMG's, it would, by definition, have different names.  
> Thus, I do not understand how H.248 could possibly meet this 
> requirement.
> 
> In fact, the response to Requirement 2.1.4 highlights this 
> issue.  H.248 is deterministic in the face of multiple 
> requests because it cannot have them.
> 
> Requirement 2.1.12:
> The biggest leap of faith is the proposal of a MIDCOM Ruleset 
> Package.  If we stuck with the H.248 master-slave model, I 
> would expect rule processing to occur at the MGC (agent).  I 
> can't envision how to implement a rule set end-point entity.  
> It seems to be rather foreign to the whole H.248 framework. 
> _______________________________________________
> midcom mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/midcom
> 
_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Paul Sijben <[email-masked]>
Date: Tue, 10 Dec 2002 21:16:19 +0100

Although Tom ends the quoted message a bit negative I see this mail as 
quite positive.
Tom, what you say you are missing is the multiple relationships. You can 
in fact get them is you want by creating a package. We (John and I) 
conceded on that point when we made MEGAGO _because_ we saw that you 
could add them easily. The package could depict ownership of the 
terminations and contexts and transfer it if you like.

I am sorry but the excess baggage is just nonsense. If you look at the 
bits we only use and the bits that you need to send, they are identical. 
TIPHON's EMP usage shows that MEGACO is quite usefule here.

I do agree that the (element) management mechanism of MEGACO is too much 
focussed on the residential gateway scenario. That is why I always 
conveniently forget about it for any other use and point to a decent 
management system to address that aspect of operations.

Eric Burger's points are covered by this as well. Multiple relationships 
can be done by giving terminations and contexts an owner attribute. 
Having two owners for one Termination is a BAD idea anyway.
But these comments come from the problem is with the way MIDCOM is 
written ruleset from the standpoint of a traditional router/firewall.
You should not match a RULE to a Termination, you match a _flow_ with a 
termination. If you look at the flow of packets as identifying things, 
then it is clear that there is only one owner for a particular flow at a 
given time!

Paul

 > From: "Tom-PT Taylor" <[email-masked]>
 > To: "'Eric Burger'" <[email-masked]>,
 >    "IETF Midcom (E-mail)" <[email-masked]>
 > Subject: RE: [midcom] H.248 for midcom? Not.
 > Date: Fri, 6 Dec 2002 13:06:20 -0500
 >
 >
 > Well ...
 >
-- 
Paul Sijben                         tel: +31205210321
Chief Technology Officer     tel direct: +31205210333
Picopoint                           fax: +31205210320
Amsterdam                        mobile: +31629582154
the Netherlands              http://www.picopoint.com