The MPLS WG Archive

["Eric He" <eric@evl.uic.edu>]

Thanks a lot!  Helped me a lot!

Sorry for some maybe off-topic questions.
So the understanding is that Integrated Serivce is still necessary for
Microflow level QoS in even MPLambdaS enabled network.
(1) Is Integrated Service practical and easy to deploy in research network?
Is there any academic or industrial solution?  I did some research and seems
IntServ is kinda obsolete.  DiffServ is more scalable but in research
network with fewer users I think scalability is not a problem.
(2) Any research is undergoing on the interaction of Integrated Service and
GMPLS?

Thanks again!
Eric He
----- Original Message -----
From: "Fred Baker" <fred@cisco.com>
To: "Eric He" <eric@evl.uic.edu>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Sent: Monday, June 10, 2002 3:54 PM
Subject: Re: Microflow level QoS implemented by GMPLS


> At 05:36 PM 6/10/2002 -0700, Eric He wrote:
> >Integrated Service is used to implement end-to-end microflow level in
> >IP-based network.  But if we can create a host-to-host lightpath using
> >GMPLS, is Integrated Service still necessary to ensure end-to-end Quality
> >of Service? Any comments are more than welcome!
>
> if it's literally light, done with mirrors, there are no queues, and
> configuring queues is unnecessary. You still have the question of whether
> the amount of bandwidth used by the telephone traffic exceeds the amount
> permitted by policy, or if there is no policy, the amount of bandwidth
> available.
>
> If it an OEO solution, you still have the distinct possibility of queues
> forming in the network, and there are questions there.
>
> The lightpath will almost certainly be part of an end-to-end solution; at
> least my PC doesn't have a fiber output on the back, and the hotel room I
> stayed in a few nights ago lacked an optical connection. You also need to
> address the end to end solution even if the optical portion of it is
solved.
>
> In short, there is still no magic. You can massively overprovision so that
> there is no case in which traffic engineering is relevant; in such a case,
> your part of the network probably has no current requirement, either for
> QoS or for traffic engineering. If you don't, you have to think about the
> effects of your network on the applications using it.
>