Re: H.248.64 question

Hello Bruno,

H.248.64 indicates:
8.3.2 Service-enhanced IPR forwarding
Service-enhanced IPR forwarding comprises all functions that may be 
overlaid on the basic forwarding, e.g., QoS support, traffic control, 
DiffServ PHBs, policy enforcement (e.g., filtering), traffic metering, 
etc. There may then be multiple interface IPR contexts, which depend on 
whether the service was interface- or route-based.

and:

9.6.3.1 Creation of a FIB for a context of type "RIPR"
"...The MGC may also set properties for service-enhanced IPR forwarding 
on these terminations...."

So yes it is possible to set DSCP depending on the route or interface.

Regards, Christian

On 26/05/2011 2:02 AM, [email protected] wrote:
>
> I can rephrase my question using the template you have used. Is it 
> possible for an MGC to request an MG in IPR mode to act according to 
> the following rule?
>
> R = Forwarding incl. Packet header modifications
>
> -> C = …
>
> -> A= … plus modification of the ToS bits
>
> If yes, does it have to modify properties of a termination (or stream) 
> in the IIPR context or of an associated RIPR context?
>
> *De :*Schwarz, Albrecht (Albrecht) 
> [mailto:[email protected]]
> *Envoyé :* mercredi 25 mai 2011 16:41
> *À :* CHATRAS Bruno RD-CORE-ISS; [email protected]
> *Objet :* 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