Subject: Re: MG and DiffServ

From: S KA N <[email-masked]>
Date: Sat, 12 Aug 2000 13:02:12 -0700

Hi All,

> >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?
>
> Most MG's are already diffserv or TOS compliant. In
> any case you can't require a vendor to build
> something unless you plan to give them a lot of
> money.

I am still in the same loop. Let me go one more level
down this time. How would I consider an MG to be
QoS (e.g. diffserv, mpls, rsvp) compliant? Is it
not possible that first make the MG w/o QoS support
and then later at the time of selling it to a customer
put a QoS compliant layer-3 device such as an MPLS
router with diffserv, etc, with it. In this case,
would
it still be considered QoS compliant?

Request you to comment on this.

>>>SKAN<<<

__________________________________________________
Do You Yahoo!?
Yahoo! Mail – Free email you can access from anywhere!
http://mail.yahoo.com/

---

From: Mike Buckley <[email-masked]>
Date: Sun, 13 Aug 2000 13:43:53 +0100

You really need to sort out roles and responsibilities before you can answer
these questions.

In the general case you have to make a distinction between the VoIP service
provider and IP network operator.  Of course they may be one and the same
but this assumption will not provide a general solution.

The MG is a service provider function, it is linked to IP telephony or some
other application - as such it is likely to be owned by the IP telephony
service provider.  The IP transport network on the other hand is likely to
be general purpose and will be carrying traffic of different types and from
different sources.

So where do Diff Serv and RSVP/IntServ fit in?  I would submit that these
are part of the IP transport network, are application independent, and under
the control of the IP network operator.
So in the general case they are really nothing to do with the MG which is
the territory of the IP telephony service provider.

Between the MG and the IP network must be some form of border element which
is owned by the IP network operator.  This is the device that will terminate
RSVP or Diff Serv as far as the network operator is concerned.  This device
will also provide policy enforcement ON BEHALF OF THE NETWORK OPERATOR.   In
the TIPHON architecture this device is called an interconnect Function
(ICF).

RSVP or Diff Serv could of course be extended beyond the domain of the IP
Network Operator.  This must be by service level agreements, however, and
these must address issues of  security,
policy enforcement and network addressing.  TIPHON has chosen to regard the
situation of end to end homogeneity as a special case.  The general case is
where the transport domain mechanisms terminate at the ICFs on the boundary
of the IP network operators domain of control.  This model allows end to end
QoS solutions where the media pass through IP domians with different QoS
mechanisms, policies and address spaces (NATs may be part of the ICFs).

So Diff Serv and other mechanisms could terminate in the MG but this would
require agreements between the network operator and service provider.
Policy Enforcement, NAT and security would also need to be covered by such
agreements if a network operator was to pass these roles on to a third
party.

Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
[email-masked]

----- Original Message -----
From: "S KA N" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, August 12, 2000 9:02 PM
Subject: Re: MG and DiffServ

Hi All,

__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/

---

From: Michael Thomas <[email-masked]>
Date: Mon, 14 Aug 2000 13:37:37 -0700

I don't get what the big problem is here. Edge
devices can and do participate in QoS. This may be
as simple as just setting the DSCP, or as
complicated as having the application signal its
desire for enhanced QoS using RSVP, performing its
own internal microflow policing, using integrity
and policy objects to transmit identity, etc,
etc. The common aspect is that they are requests
made by the application layer which are initiated
by an IP host.

For MEGACO, there are some implications because
MG's must be able to be made dumb, policywise.
Since e-2-e QoS needs to be initiated by device,
that means that the on-the-wire protocol that
controls the device (MGC) needs a means to
instruct the dumb device (MG) of the correct QoS
policy to initiate.  This is no different in
principal than the MGC telling the MG what codec
it prefers the MG to use.

As far as the transit network goes, this is really
a pairwise settlement issue between the MG and the
telephony service provider (they may not be owned
by the same entity either), the TSP and the ISP,
and the ISP's amongst themselves. Part of that
business and settlement relationship in each case
needs to be how it fulfills the SLA of the
upstream customer. If my contract says that I get
EF treatment with any subscriber, that just says
that any foreign transit networks better abide
within the confines of that SLA, or they need to
figure something else out. Fortunately, things
like MPLS are making those sort of traffic
engineering problems more tenable versus strict
destination based routing, though I suppose it's
even possible with DSCP's accounted for in the
FEC's.

I really don't see how that differs materially
from normal peering point politics though, and I'm
not sure that it warrents a big glossy new TLA.

                Mike

---

From: Mike Buckley <[email-masked]>
Date: Tue, 15 Aug 2000 13:37:07 +0100

> it prefers the MG to use.

Not sure I followed this.  Are you saying that Megaco should carry details
of the transport QoS mechanisms that may be supported in the MG?

Mike

Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
[email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Tue, 15 Aug 2000 17:59:41 -0700

> of the transport QoS mechanisms that may be supported in the MG?

   Absolutely. The MG may have no idea what QoS
   policy is appropriate, and in fact it may
   change on a call by call basis which says that
   it *must* be setable from the MGC.

             Mike

---

From: Paul Sijben <[email-masked]>
Date: Tue, 29 Aug 2000 16:24:09 +0200

I agree.

Flemming, I'd gladly help in drawing up the appropriate packages.

Paul

--
Paul Sijben              Tel:+31 356874774
Lucent Technologies      Message:+31 208702874
Forward Looking Work     Fax: +31 208702874
Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)