Subject: Re: MG and DiffServ

From: S KA N <[email-masked]>
Date: Thu, 3 Aug 2000 16:34:14 -0700

Hi There,

If you can recall the meaning of DiffServ, its for
implementing differentiated services in the Internet.
Which basically means giving QoS to specially marked
data traffic. Now if you look at the requirements
specified in Section 5.5 of RFC2805, it says that
the MGCP protocol should support the ability to
specify QoS for the connection between MGs, etc.

Any comment.

...SKAN

> There's a difference between an operator's RFP
> requiring that their MGs
> support DiffServ and a protocol dependency on such
> support.  Megaco has no
> such dependency.
>
> > -----Original Message-----
> > From:       S KA N [SMTP:[email-masked]]
> > Sent:       Wednesday, August 02, 2000 3:26 PM
> > To: [email-masked]
> > Subject:    MG and DiffServ
> >
> > Hi,
> >
> > Can you think of any relation between the MG and
> > DiffServ?
> >
> > If a privately managed IP network is DiffServ
> > compliant and suppose if the same network
> > is going to be used for VoIP purposes also. Don't
> > we require the MGs to be DiffServ compliant?
> >
> > Any help/comment would be appreciated.
> >
> > ...SKAN

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/

---

From: Bill Foster <[email-masked]>
Date: Thu, 3 Aug 2000 18:01:22 -0700

Given that the MGC is often defining policy and QoS use is an important policy, it would be useful to have the capability.

> > > Any help/comment would be appreciated.

-----------------------------
Bill Foster
Phone: (408) 527-8791
Page:   (800) 365-4578
Fax:     (781) 998-6492

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 4 Aug 2000 08:28:26 -0500

All

Shouldn't this be defined by other mechanisms by default?

For example, typically the MG is dumb and requires a config image from some
TFTP server. A template config is usually utilized that should set the default
DSCP to a value that likely won't change. This isn't a Protocol issue, I don't
think, it's a semantics issue.

Another example, the port the MG is physically connected to on the Enet Switch
sets the traffic to a specific Voice VLAN. Again, this isn't a Protocol issue.

Another example, the Enet Switch knows that a MG is what's attached to a
specific port and sets all incoming traffic to a defined DSCP value -- again,
not a Protocol issue.

I think, typically, a Protocol deals with things that are negotiated. I yet
don't see why a MG (IP Phone) which is almost always getting its config file(s)
from a Server (MGC?) that it will yet need to have anything other than the one
default value (even if that is EF marked) which that Domain Administrator
assigns to all Voice traffic within that Domain.

I believe the same should apply to a MG that's a PSTN to IP Gateway. There
actually cannot be a priority change from the PSTN to the IP network in this
example by law, if that IP Network is providing a Telecommunications Service
(although I'm not sure that 'law' is the right word -- I just know MLPP cannot
be run on the PSTN or like network-types). Therefore, all inbound IP Voice
related traffic must have the same value as all other Voice traffic to those
types of providers.

I know Fred Baker is very resistant to the idea of Voice traffic having
multiple Forwarding queue behaviors within an internetworking device (i.e.
multiple levels of EF for dropping), so this would suggest the DSCP other than
EF isn't preferred by him (and others). His belief - and I'm not yet sure it's
correct in the long term - is that this is a session issue, not a forwarding
issue; therefore this is an RSVP/COPS Prioritization issue, isn't it?

At 06:01 PM 8/3/2000 -0700, Bill Foster wrote:
>Given that the MGC is often defining policy and QoS use is an important
>policy, it would be useful to have the capability.
>

*************************************
"At the end of the day... the most committed win!"

James M. Polk
Sr. Product Manager, Multiservice Architecture and Standards
Enterprise Voice Business Unit
Cisco Systems
Dallas, Texas
w) 972.813.5208
f)  972.813.5280
www.cisco.com