[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: End-to-end L2-LSP




Dear Richard,

Yes, I believe it is not only commercially profitable but it may also grow total 
revenue of service operators by introducing new services.

For example, think the example of IP phone you referred.
How do you think you can provide reliable VoIP service and 
safely authenticate phone users and charge fees as counted by packet usage
using simple Ethernet based xDSL network ?

There's hardly new service that providers may offer using Ethernet based 
architecture, and collect sufficient profit to investment.

A sophisticated ATM switch might do the work if it is not expensive. 
However, my intension is modifiying existing design of Ethernet hardware
with a little bit additional cost,  and provide the level of service that 
ATM switches might offer.

We have initial design of the Ethernet-MPLS hardware. I don't think
GMPLS enabled Ethernet switch will be so complex. The market price
of GMPLS enabled switch will not be so expensive than normal 
Ethernet switches.

Further, it only requires upgrade of switches in some bottleneck points of network.
Read the framework documents of L2SC. It doesn't require entire replacement
of switches to introduce new service. 

Every year, ISPs purchase new access switches and replaces old machines.
With a bit additional cost, ISPs may use the GMPLS enabled switch for
normal Ethernet switching in initial deployment. 

When the GMPLS function is enabled in some upgraded part of network, 
ISPs may provide high quality, reliable VoIP service to xDSL customers
using RSVP-TE enabled VoIP phone. 
The high quality video-phone service enabled by GMPLS will be 
competable to legacy voice only phone service.


There are lots of things I can argue about commercial aspects of this technique.
However I don't think it is not appropriate to discuss this issue in this mailing list.
All I can say is,
yes, I believe that it may be commercially viable.


Thanks 

Jaihyung

================================================

Do you really think the benefits of extended GMPLS down to the end user could ever justify the costs involved in upgrading LAN switches and things like IP phones (simple low cost commodity items) to support GMPLS signalling/routing? 

Your proposal may be technically possible (though it would require new hardware and significant software upgrades), but commercially I would consider this to be a non-starter. 

Regards, 
Richard 

> -----Original Message----- 
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On 
> Behalf Of CHO, JAI HYUNG 
> Sent: 12 July 2005 01:10 
> To: ccamp@ops.ietf.org 
> Subject: End-to-end L2-LSP 
> 
> 
>  
> Dear all, 
> 
> Greetings. 
> 
> I am a co-editor of the Ethernet-GMPLS framework document. 
> (draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt) 
> 
> I am writing this to explain the motivation behind the 
> proposal of scenario-1, and to raise the issue of 
> end-to-end LSP to be included in CCAMP charter. 
> 
> An important goal intended in scenario-1 is 
> QoS control over end-to-end packet delivery using LSP. 
> In other words, the purpose of scenario-1 is extending coverage 
> of GMPLS control including customer network and end-user device, 
> such as PC, VoIP phone, IP-TV, or even future 4G mobile phone. 
> End-user applications will have a means to request resources 
> to network using GMPLS signal. 
> 
> Unfortunately, this view is not included in the 
> framework because there was strong opinion that 
> L2-LSP must not span beyond provider network because 
> CCAMP is not chartered to work on customer 
> network. I am wondering if this is right argument. 
> Perhaps the charter can be amended to include this work. 
> 
> I believe there is little technical reason to preclude 
> LSP being used in customer network. It is a reasonable 
> assumption that private company may also use GMPLS 
> implemented Ethernet switch, once the L2SC work is successful. 
> Currently, CCAMP is the only place discussing the matter of 
> Ethernet and LSP. There is no other WG dealing similar issue. 
> If CCAMP wants to work on Ethernet, 
> I think the coverage of common GMPLS control must be 
> extended to include all area where Ethernet is deployed. 
> Currently, Ethernet is dominantly deployed in first-mile 
> network where access network as well as customer network 
> and user hosts are usually included. Therefore, user host must 
> be considered as initiation and termination point of L2-LSP. 
> 
> Another important reason to include user host in CCAMP 
> work scope is to achieve consistent end-to-end control of QoS. 
> End-to-end QoS has long been desired goal since RSVP was 
> first designed. This goal can be best achieved using 
> end-to-end GMPLS signal and L2-LSP. 
> Currently, RSVP (RFC2205) is available in many user hosts. 
> There is only a little difference between RSVP and RSVP-TE. 
> If the RSVP-TE signal of provider network can reach user host 
> across Ethernet based private network, an LSP can be established 
> from application to application via the provider backbone. 
> Service providers will be able to control application flows 
> in L2-LSP level as well as in aggregated LSP pipe of similar 
> application type. A variety of new services will be enabled using 
> the enhanced capability of distinguishing and controlling each 
> individual application flow. 
> 
> I personally believe that end-to-end L2-LSP may offer 
> innovative solutions for servicing IP-TV as well as fast mobility. 
> There have been some experimental approaches combining 
> MPLS and IP mobility. However such potential of the new 
> application can only be explored when end-user host is 
> included in the scope of CCAMP work area. 
> 
> Therefore, I hereby sincerely request people's attention 
> and support on this perspective of end-to-end LSP. 
> If there is enough number of people agree on this view, 
> the WG can request the necessary update of the charter. 
> 
> Thank you. 
>  
> Jaihyung Cho 
>  
>  
>  
> ETRI, Korea 
> phone :       042) 860-5514 
> oversea: +82-42-860-5514 
> fax:         +82-42-861-5550 
> 
> 
> 
> 
> 
> 
>