Subject: Re: MG and DiffServ

From: S KA N <[email-masked]>
Date: Tue, 15 Aug 2000 12:12:54 -0700

> > 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.
>
> 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?

If I recall correctly, there is a requirement
specified by MSF also to have a Bearer Control
Interface (probably on MGC) which will enable
multiple bearer control system to coexists
(MPLS, PNNI, ISUP). So even this also points
towards having MGCP understand different
bearer types.

<<<SKAN>>>

>
> Mike
>
> Mike Buckley
> +44-1457-877718 (T)
> +44-1457-877721 (F)
> [email-masked]
>
>
> ----- Original Message -----
> From: "Michael Thomas" <[email-masked]>
> To: "Mike Buckley" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, August 14, 2000 9:37 PM
> Subject: Re: MG and DiffServ
>
>
> >
> > 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
> >
> >
> > Mike Buckley writes:
> >  > 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,
> >  >
> >  > > >Can you think of any relation between the MG
> and
> >  > > >DiffServ?
>
=== message truncated ===

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