Re: H.248.64 question

Bruno, not sure I got your point.

The MG behaviour may be modeled by using "packet forwarding rules" (and Rule = {set of conditions for packet identification/classification} + {associated actions}; R = C + A).

The 1st set of H.248 packages by H.248.64 (2009) supports following rules, roughly:

I) R = "Native forwarding"
    -> C = FIB (RFC 4292)
    -> A = select output plus forwarding or not

II) R = "Forwarding incl. NAT"
    -> C = ...
    -> A = ... plus NAT

III) R = "Forwarding incl. basic filtering"
    -> C = ... plus filter conditions
    -> A = ... plus filter actions

That's a fairly abstracted summary.

Now, I'm guessing that you are considering rules such as:

IV) R = "Forwarding as DS PHB" or "Forwarding based on IPv4 ToS" ...
    -> C = ... plus DiffServ conditions
    -> A = ... inline with aimed DS PHB (e.g. as DiffServ Edge Router)

V) R = "Traffic policing + Forwarding"
    -> C = e.g. IP byterate conditions plus ...
    -> A = ...


I think that such a rule based description of considered packet operations would help to clarify
a) the requirements first
and
b) to check whether there are already existing H.248 capabilities or whether extensions might be required.

My impression is that we are talking about stage 3 (b) possible solutions before clarifying stage 2 (a) first.

Rgds, Albrecht

PS
Draft H.248.79 touches the topic of "Policy rule based description of packet operations" in clause 7.3. It may be noted that ALL known supported functions by H.248 IP-IP MGs may be described by such a rule concept.



________________________________
From: [email protected] [mailto:[email protected]]
Sent: Mittwoch, 25. Mai 2011 10:58
To: Schwarz, Albrecht (Albrecht); [email protected]
Subject: RE: H.248.64 question

Does it mean that you can't you mix-up Best Effort traffic with say VoIP traffic

De : Schwarz, Albrecht (Albrecht) [mailto:[email protected]]
Envoyé : mercredi 25 mai 2011 10:42
À : CHATRAS Bruno RD-CORE-ISS; [email protected]
Objet : RE: H.248.64 question

Bruno,

sorry for delay!

There are not any straightforward answers because the usage of H.248.52 (& perhaps H.248.53) implies certain roles.

E.g., DSCP marking (using H.248.52):
possible roles of an IP node
- DS pre-marker
- DS edge router
- DS interior node (providing DS PHB)

ALL existing H.248 Profiles with H.248.52 usage define just the DS pre-marker behaviour! Just because there were not any stage 2 requirements for other roles.
I guess that this situation is due to the specific location considered for that H.248 MGs (at the edge, either at access or peering side).

Now, I'm not sure what you are looking exactly, hm?
Let's consider a "DS interior node" role plus IPR mode.
The next question would be whether you are really want
a) DS PHB control for individual IP bearer connections? or
b) DS PHB control on aggregated level?

On a first glance I would conclude that H.248.52 (& .53) togther with H.248.64 may be applied at the granularity of route levels (aka RIPR contexts).
[BC] So the ds/dscp property would be set on a termination of a RIPR context rather than the a termination of an IIPR context? If yes, this need to be stated somewhere, e.g. in H.248.79....

That's already a sufficient baseline in my opinion for scenarios like NAT66-less plus DS pre-marker, i.e. an H.248 IP-IP MG located between two IPv6 networks (without the enforcement of local NAPT).

Regards,
Albrecht



________________________________
From: [email protected] [mailto:[email protected]] On Behalf Of [email protected]
Sent: Dienstag, 24. Mai 2011 13:29
To: [email protected]
Subject: [Megaco] H.248.64 question
Hi all,

A question about H.248.64:  Is the IPR mode compatible with the use of properties such as those defined in H.248.52 or H.248.53? If yes, I don't really understand how the MGC can request the MG to use a specific DSCP value for a particular packet for example? Can someone shed light on this?

Bruno

_______________________________________________
Megaco mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/megaco