Subject: [Megaco] QoS Package

From: CHATRAS Bruno FTRD/DAC/ISS <[email-masked]>
Date: Mon, 3 Sep 2001 18:26:38 +0200

Hello,

The overall purpose of draft--madhubabu-megaco-qospackage-00.txt is  not so
easy to understand. I ahev a rather basic question about the proposed
packages.At a first glance it seems that these packages provide an
alternative to a solution where both H.248 and COPS would be used on the
MGC-MG interface, assuming that the MGC (or the physical node hosting the
MGC function) implements a Policy Decision function. Is this a correct
understanding?

BTW, are there any call flows that illustrate the use of these packages?

Regards,

Bruno

_______________________________________________
Megaco mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/megaco

---

From: "Madhu Babu Brahmanapally" <[email-masked]>
Date: Mon, 3 Sep 2001 18:11:23 -0400

Hi Bruno/all,
The basic idea of defining the QoS package is to enable the MGC control the
MG for assuring QoS. In case of DiffServ, the goal is achieved by setting
the TOS byte in the IP packet with the DSCP value specified by the MGC. In
case of IntServ, the MG has to do little more.
1) Generation of Path message for initiating resource reservation
"downstream".
2) Generation of Resv message for reserving the resources "upstream".

Generation of Path message is simple compared to the case where a Resv
message is generated. The MG needs to specify the traffic characteristics
i.e. the parameters for the Sender TSPEC. These parameters are provided to
the MG from the MGC using the properties defined in the RSVP package.

There are two possible schemes for the MG generating a Resv message.
1) The MG forwards all the information of the Path message(both Tspec and
ADSPEC) to the MGC (MG here acts as a relay agent) and waits for the
further indication from the MGC. The MGC (acts as PEP or a COPS client)
forwards the policy decision (with parameters) to the MG, thus enabling the
MG to generate the RESV message.
2) The other possibility is that the MGC specifies the receiving stream
reservation choices and MG after receiving the information from the MGC,
waits for the PATH message and then correlate the parameters and contacts
the COPS server (MG here acts like a PEP) for further decision making. The
MG after receiving the response can generate the RESV message.

Both methods have their (dis)advantages.
For method (1) MG need not perform anything more except exchanging the
information it receives in the Path message. But during this process all the
parameters needs to be mapped to some property so that they can be exchanged
in the H.248 messages. MGC in this case acts as a PEP and again has to
generate request to a COPS server.
In method (2) the MG acts as a PEP and contacts a COPS server to indicate
the result to the MGC using the events defined.
To avoid the information forward back and forth between the MGC, the MG
directly contacts the COPS server. Method (1) fits perfectly with the Megaco
methodology of control decision making at the MGC (but with the mentioned
overhead). The draft at present assumes that the MG does the policy control
part(with/without COPS).

Thanks for throwing some light on this issue, as we were not able to decide
the best method. Hope now there can be some discussion on the list for
deciding the best practice.

Regards

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
CHATRAS Bruno FTRD/DAC/ISS
Sent: Monday, September 03, 2001 12:27 PM
To: [email-masked]'
Subject: [Megaco] QoS Package

Hello,

Regards,

Bruno