RE: End-to-end L2-LSP

[<neil.2.harrison@bt.com>]

Hi Jaihyung,

Having had some private requests to 'say something' on the list here I want to respond to a point you raise below, viz:

"Ever increasing best effort bandwidth will eventually not satisfy 
both providers and customers for many reasons. Service providers 
will have difficulty in collecting expenses enough to invest on increased 
bandwidth. This will in turn gradually downgrade overall communication quality, 
and applications requiring real-time service will never satisfy customers. 
We already see such symptom in some low-price service providers. 
I believe new service structure that can provide difference of service 
quality will offer benefit to customers, providers as well as vendors in the end."



See if these observations help:

Real world networks (any mode) run at low utilisations over most of their working life for a whole raft of important reasons.  In this 'normal' operating region the key challenge for the network architecture is that it must enable operators the ability to create consistently meaningful/priced services over all load points.....else longer-term investment will suffer.  If the network architecture cannot address this then we have a serious problem brewing for not only this industry but all those dependent on it....and currently this would appear to be the case.  Many operators are already discovering that 'ever faster and faster' access without some fair usage pricing is not satisfactory.  And please don't assume this is an operator only problem (ie a mindset of 'here are some capabilities now you figure out how to use them' is not good enough).....if the operator community cannot generate a fair return on investment then both vendors and customers will ultimately all suffer.  There is no free lunch here....but we do need a fairly priced lunch.

When networks fail and enter the 'abnormal' operating region the nature of the key networking challenge changes significantly.  Here the key issue for the network architecture is targeted traffic survivability.  So how does one decide which traffic units are more important than other ones?...esp if I make the observation that ANY application can assume ANY 'importance' but yet all applications of a common kind have a fixed QoS requirement.  And this should not be just considered in the context of public services, we also need to include private network builder services.


I am of the strong opinion that trying to solve the above service-oriented problems by having lots of QoS classes in a single networking mode/technology won't work very well (understatement).  And there is a substantial body of historical networking evidence to support this view (and some interesting analysis, eg by Andrew Odlyzko).  Go have look at the truly successful networks that have prrofs by long-term existence and the one thing you will note that these all have in common is they do not have multiple QoS classes.  ATM tried multiple QoS classes and it was a failure.  Only AAL5 and AAL1 have any major use today.  So why is this?  Well its actually rather easy to explain:

Applications have only 3 broad classifications:  messages, files and streams.  It's therefore intuitively obvious one does need a large set of QoS/traffic classes to address this.  Indeed, in IP networking we find UDP, TCP and RTP map very nicely to the key major traffic classes.....this is NOT to say the serving network can effectively (ie includes cost) provide for these however.  AAL5 caters largely for the message/file class and AAL1 the stream class.  Everything else boils down to BW squeezing.....but successful networks run at low loads over most of their lives and BW is no longer such a scarce commodity that we need to try and conserve it everywhere.  Indeed BW should be used as a tool to drive down complexity....and complexity costs are indeed increasing (ask any operator about opex).  In fact a '1 mode/technology mindset' incurs lots of complexity.

Now although the above considers the public networking case it does not really address the needs of the private networking case.  Here, the basic service building block is a client/server layer network relationship where the client and server layer networks must be functionally decoupled....if for no other reason (and there are many other reasons) than the fact that the client and server layer networks may be owned by different operating parties.  In such a relationship how can anyone make any meaningful judgement as to a given application's importance?.....vis-à-vis the same application (but different user instance) in the same private network service instance, or the same application in some other customer's private network service instance.  And note that once we nest several layer networks deep then sight of ultimate end-user applications gets lost...as indeed they must, else the management of those lower layer networks would become intractably complex.

There is also a performance inheritance issue here, since the performance of layer network N is a combination of (i) impairments introduce by the nodes at layer N and (ii) the impairments introduced in the link-connections of layer N which come from trails at layer N-1.....this performance inheritance issue recurses to the duct.

So how are we to address the above issues of:
-	consistently meaningful/priced services in the normal operating regions?
-	correctly targeted traffic survivability in the abnormal operating region?
-	and across all public and private services?.....noting the important client/server relationship between layered networks mentioned above

I actually think there is a good solution to these problems....but it requires we let go of any technology religion and consider all 3 networking modes working in concert.  One key point to note is that in the co modes the trail object allows us to decouple the QoS semantic of child traffic units carried (that can change epoch by epoch) from the importance semantic of the parent trail entity (which is temporally invariant).

For the private services case the issue is very simple.  One must provide a co-cs or co-ps CBR-like server layer.  Indeed, its no coincidence that as one nears the duct all transport networks look like this.  They are the most efficient way of handling bulk traffic of any type as any major operator will tell you.

For the public service case let us assume a customer could select the mode he/she wanted to use and pay for this accordingly.  So for message and some file applications the customer may be happy with a simple cl-ps mode service (1 QoS class).  For stream and some file applications the customer may be happy to pay for a simple CBR-like co-ps SVC-based service (again 1 QoS class).  Just have think about this...and I mean really think....of how this could address some otherwise very hard problems in the QoS/pricing area.  And just consider how simple both the data-plane (classifiers/marking/shaping/policing/CAC/whatever) and control-plane (routing and signalling messages sets) components become.

You can think of this as the marriage of the best of the Internet and PSTN worlds if you like.  I do believe this scenario is worthy of serious consideration and should not be dismissed lightly.

regards, Neil



> -----Original Message-----
> From: owner-ccamp@ops.ietf.org 
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of CHO, JAI HYUNG
> Sent: 14 July 2005 04:24
> To: Spencer,R,Richard,XGH5 R; ccamp@ops.ietf.org
> Subject: RE: End-to-end L2-LSP
> 
> 
>  
>  
> Dear Richard,
> 
> See in-line please,
> 
> >Thank you for taking the time to respond to my questions. I 
> anticipated
> >that your response would include "over-provisioning is the 
> best answer" 
> >to decrease the chance of congestion on non-GMPLS switches. 
> >This is what is done in the LAN environment today in 
> conjunction with CoS, 
> >and this is why I believe there will be two opposing views on how 
> >far L2-LSP connections should be extended down to the user. One view 
> >is that over provisioning and CoS work fine in the 
> enterprise network today, 
> >and therefore the L2-LSP should only be extended down to the point 
> >at which the enterprise network connects to the SP network, 
> >e.g. Ethernet DSLAM. I think the other view will be that 
> over provisioning 
> >and CoS in the enterprise network don't work and therefore L2-LSPs 
> >should be provided end-to-end using only GMPLS capable switches. 
> >I wouldn't have thought there would be much call for mixed 
> >GMPLS/non-GMPLS enterprise networks (except for during migration) 
> >due to the opposing views, e.g. if over provisioning is good 
> enough for 
> >one switch, why isn't it good enough for the other?
> 
> Over-provisioned network is non-guaranteed network. It can't prevent 
> occasional congestion at any rate. Further, network condition 
> in private 
> network is very diverse. You can't predict minimum service level 
> inside every private network. 
> 
> Suppose that an ISP want to provide high-quality, video-phone service 
> for enterprise users. Nothing can be guaranteed inside the 
> over-provisioned 
> customer network. If the service level is not satisfactory, 
> customers will complain 
> to service provider even if the main cause is in his network 
> or destination network. 
> We need some structure that coordinate service quality in 
> both private sector, 
> as well as in public sector consistently. 
> An end-to-end signal is an effective means to communicate between 
> user terminal, private switches and provider switches, and 
> concert service 
> quality at each different operations network. This is a goal 
> that RSVP (RFC2205) 
> pursued, however ineffective in local network because 
> Ethernet industry 
> didn't support RSVP over Ethernet (RFC2814, 2815, 2816). 
> Now we have another opportunity to realize the goal using L2-LSP. 
> Therefore, I believe end-to-end LSP is necessary even in 
> enterprise network 
> for the purpose of providing guaranteed commercial service.
> 
> >I think where most people will agree is that using connections
> >in the SPs access network does make sense in order to 
> provide efficient 
> >link utilisation and per connection policing to ensure one customers 
> >traffic can not affect another's. Regarding the ability to 
> set up new 
> >connections based on a request from the user (rather than 
> constraining 
> >RSVP signalling to inside the SP network), I think this will come 
> >down to enterprise customer demand for improved service performance. 
> >If a customer wasn't getting the performance they needed from their 
> >SP and was offered a new service that allowed them to setup 
> new L2-LSP 
> >connections on demand that would offer better performance 
> (e.g. for voice 
> >calls or video conferences), then upgrading the user devices 
> to support 
> >the new service could well be an attractive proposition. If 
> on the other 
> 
> Yes, this will be one of prospective service newly enabled 
> using L2-LSP.
> 
> >hand a customer buys a best effort service and considers the 
> >performance
> >to be 'good enough', then there would be no reason to go to 
> the expense 
> >of upgrading the user devices to support the set up of L2-LSPs.
> 
> Ever increasing besteffort bandwidth will eventually not satisfy 
> both providers and customers for many reasons. Service providers 
> will have difficulty in collecting expenses enough to invest 
> on increased 
> bandwidth. This will in turn gradually downgrade overall 
> communication quality, 
> and applications requiring real-time service will never 
> satisfy customers. 
> We already see such symptom in some low-price service providers. 
> I believe new service structure that can provide difference 
> of service 
> quality will offer benefit to customers, providers as well as 
> vendors in the end.
> 
> I also look forward to see you at Paris and continue helpful 
> discussion.
> 
> Sincerely
> 
> Jaihyung
> 
> 
>  
> 
> Dr. Jaihyung Cho
> ETRI, Korea
> phone :       042) 860-5514
> oversea: +82-42-860-5514
> fax:         +82-42-861-5550 
> 
> 
> 
> 
> -----?? ???----- 
> ?? ??: "richard.spencer@bt.com" <richard.spencer@bt.com> 
> ?? ??: 2005-07-14 ?? 1:10:30 
> ?? ??: "jaihyung@etri.re.kr" <jaihyung@etri.re.kr>, 
> "ccamp@ops.ietf.org" <ccamp@ops.ietf.org> 
> ??: 
> ??: RE: End-to-end L2-LSP 
> 
> 
> 
> Jaihyung, 
> 
> Thank you for taking the time to respond to my questions. I 
> anticipated that your response would include 
> "over-provisioning is the best answer" to decrease the chance 
> of congestion on non-GMPLS switches. This is what is done in 
> the LAN environment today in conjunction with CoS, and this 
> is why I believe there will be two opposing views on how far 
> L2-LSP connections should be extended down to the user. One 
> view is that over provisioning and CoS work fine in the 
> enterprise network today, and therefore the L2-LSP should 
> only be extended down to the point at which the enterprise 
> network connects to the SP network, e.g. Ethernet DSLAM. I 
> think the other view will be that over provisioning and CoS 
> in the enterprise network don't work and therefore L2-LSPs 
> should be provided end-to-end using only GMPLS capable 
> switches. I wouldn't have thought there would be much call 
> for mixed GMPLS/non-GMPLS enterprise networks (except for 
> during migration) due to the opposing views, e.g. if over 
> provisioning is good enough for one switch, why isn't it good 
> enough for the other? 
> 
> I think where most people will agree is that using 
> connections in the SPs access network does make sense in 
> order to provide efficient link utilisation and per 
> connection policing to ensure one customers traffic can not 
> affect another's. Regarding the ability to set up new 
> connections based on a request from the user (rather than 
> constraining RSVP signalling to inside the SP network), I 
> think this will come down to enterprise customer demand for 
> improved service performance. If a customer wasn't getting 
> the performance they needed from their SP and was offered a 
> new service that allowed them to setup new L2-LSP connections 
> on demand that would offer better performance (e.g. for voice 
> calls or video conferences), then upgrading the user devices 
> to support the new service could well be an attractive 
> proposition. If on the other hand a customer buys a best 
> effort service and considers the performance to be 'good 
> enough', then there would be no reason to go to the expense 
> of upgrading the user devices to support the set up of L2-LSPs. 
> 
> I look forward to the discussions in Paris. 
> 
> Regards, 
> Richard 
> 
> > -----Original Message-----
> > From: CHO, JAI HYUNG [mailto:jaihyung@etri.re.kr] 
> > Sent: 13 July 2005 15:14 
> > To: Spencer,R,Richard,XDE73 R; ccamp@ops.ietf.org 
> > Subject: RE: End-to-end L2-LSP 
> > 
> > 
> >  
> >  
> > Dear Richard Spencer
> >  
> > see in-line
> >  
> > >Jaihyung,
> > > 
> > >Perhaps I'm becoming too much of a pessimist;-)
> >  
> > oh, not at all,
> > you are reasonable enough to dig up unclear knowledge 
> > please go ahead until you finally get satisfactory answer. 
> >  
> > 
> > >Ignoring the commercial aspects, please can you help clarify
> > a few technical
> > >questions I have in order to help me gain a better
> > understanding of the proposal?
> > > 
> > >1. You say that one of the key reasons for using GMPLS in
> > the enterprise
> > >network is to provide end-to-end QoS control. However, you
> > also say that not
> > >all the switches will need to support GMPLS, only those at
> > bottle necks.
> > >Please can you expand on this to explain how you can have 
> end-to-end
> > >QoS control when the L2-LSP is not end-to-end? 
> >  
> > 
> > The contextual meaning of 'End-to-end LSP' is that GMPLS label is
> > assigned from source terminal and removed at destination terminal, 
> > because RSVP-TE message is exchanged from host to host. 
> > It may not perfectly guarantee QoS when the GMPLS deployment 
> > is not complete, however it will at least be good enough 
> > for end-user applications to tell those GMPLS implemented 
> L2 switches 
> > what frame must be given priority service when congestion occur. 
> >  
> > 
> > >As being discussed
> > >on the PWE3 mailing list, the performance a service receives 
> > is only as
> > >good as the worst performing server layer. Therefore, if there is a
> > >standard 802.1 workgroup switch between the user and the 
> > L2-LSP that is
> > >experiencing congestion (e.g. due to a large amount of
> > peer-to-peer traffic),
> > >then the QoS that the user receives will only be as good as
> > that provided
> > >by the congested workgroup switch.
> >  
> > 
> > of course, ETH-GMPLS does not prevent congestion inevitably 
> occurring
> > in those non-GMPLS deployed part. 
> >  
> > 
> > >The only way I can see a network using a mixture of GMPLS
> > and non-GMPLS
> > >switches guaranteeing end-to-end QoS would be to design the
> > network in
> > >such a way that the non-GMPLS switches could never become 
> congested.
> >  
> > 
> > Yes, that will be the way wise network designer improve 
> their network.
> >  
> > 
> > >To do this would require that RSVP requests be used for ALL
> > traffic flows
> > >to ensure that there was enough bandwidth available, along
> > with strict
> > >per L2-LSP policing on the user devices (e.g. PC).
> > >However, the obvious flaw in this approach is that someone could 
> > >just come along and connect 
> > >an end device to a non-GMPLS switch and start transmitting traffic 
> > >(without performing CAC/policing) causing the switch to 
> > become congested.
> > >Therefore, please can you explain how end-to-end QoS can be
> > guaranteed
> > >in a mixed non-GMPLS and GMPLS switching environment?
> >  
> > 
> > Of course traffic came from non controlled ingress can not be
> > prevented 
> > in non-GMPLS node. There's no magic. Only the 
> > over-provisioning is the 
> > best answer. However, once the aggregated traffic pass 'ANY' one of 
> > GMPLS enabled node, those uncontrolled traffic will suffer 
> > queuing discipline. 
> >  
> > 
> > >2. Section 5.1 currently states "When the customer initiates
> > data transmission,
> > >the access switch maps the user flow into the L2 LSP.
> > Mapping procedure is
> > >subject to implementation choices, and is out of the scope of this
> > >document." In order to be able to map any traffic, first of 
> > all the switch needs
> > >to know what type of traffic (e.g. based on source/dest MAC,
> > VLAN ID, 802.1p
> > >bits, etc) should be mapped to the L2-LSP. In Figure 1, if
> > an L2-LSP is set up
> > >from the DSLAM to the edge router based on a request from
> > the user (e.g. via
> > >a PC or VoIP phone), then won't the user also need to signal
> > what type of
> > >traffic should to be mapped to the L2-LSP?
> >  
> > 
> > Thank you for pointing out important thing.
> > That's the most unfortunate part I reluctantly agreed because the 
> > work condition in the framework DT was not to span L2-LSP 
> > beyond provider network. 
> > As you noticed, mapping user traffic at provider access is awkward. 
> > A smooth method will be for user terminal aware of the L2 label 
> > to use by receiving RSVP-TE message. 
> > However, there was strong argument that RSVP-TE must not 
> > go beyond provider network because the DT is not chartered 
> > to work in customer network. 
> > That's why I requested amendment of CCAMP charter 
> > to include user terminal explicitly in CCAMP work scope, so that 
> > avoid such silly argument in future. 
> >  
> > 
> > >3. In section 5.1, the text states that the aggregation
> > switch between the
> > >DSLAM and edge router may be a 802.1 switch, i.e. it doesn't
> > have to support
> > >GMPLS. To set up a connection, first of all there needs to
> > be a data plane
> > >capable of carrying control plane traffic between GMPLS
> > peers. Secondly,
> > >the GMPLS peers need reachability information in order to
> > forward control
> > >messages onto the next peer (i.e. a static or IGP route). If
> > the GMPLS peers
> > >(e.g. the DSLAM and edge router in Figure 1) are not
> > directly connected,
> > >then the GMPLS control packets will need to be forwarded by
> > the 802.1 switch.
> > >Would the idea be to have say a "control traffic VLAN"
> > configured between the
> > >DSLAM and edge router via the transit 802.1 switch so that
> > control packets
> > >could be forwarded transparently by the 802.1 switch?
> >  
> > 
> > Although it doesn't preclude use of VLAN, I think such
> > special configuration 
> > for RSVP-TE control message is not necessary in legacy switches. 
> > Legacy switches only need to pass RSVP-TE messages as they 
> > pass normal data frames. Only the GMPLS implemented switches 
> > need to distinguish frames containing RSVP-TE messages and 
> > snoop them. 
> > Detail of implementation is, of course, for future discussion. 
> >  
> > 
> > >4. If we assume that control messages can be transparently 
> forwarded
> > >by the intermediate 802.1 aggregation switch then how are 
> > user frames
> > >forwarded in the data plane by the 802.1 switch?
> >  
> > 
> > Legacy switches do not distinguish control/data frames.
> >  
> > 
> > >If the DSLAM sets up a L2-LSP
> > >to the edge router using say VLAN ID 99, how does the switch 
> > know that any
> > >packets coming in with a VLAN ID of 99 should be forwarded
> > out of the port
> > >connecting to the edge router?
> >  
> > 
> > oh, you misunderstood the L2-LSP.
> > The question you are asking depends on how L2 label is encoded. 
> > there was hot debate in the DT about the issue how L2 label 
> > is encoded. 
> > My proposal is to use part of MAC address for label and the 
> > other people 
> > argued to use VLAN ID for label. The debate was not concluded 
> > because the goal of the L2SC framework document is not to select 
> > implementation method but to draw necessary work scope. 
> > I believe this issue will be dealt in depth after Paris meeting. 
> > So, please reserve your question until then and ask to those 
> > VLAN proponents. 
> >  
> > 
> > >5. During connection setup, I take it that the GMPLS peers
> > assume that
> > >resources are available within the intermediate 802.1 switch
> > to support
> > >the connection (as its transparent). However, as there is no
> > >CAC/policing being performed by the 802.1 switch 
> > >(the L2-LSPs are transparent), and due to the any-to-any and 
> > broadcast
> > >based nature of Ethernet (i.e. its CL properties), then 
> how can this
> > >assumption be made? This comes back to my original question, how 
> > >can end-to-end QoS be guaranteed in an environment where there is 
> > >a mixture of 802.1 and GMPLS enabled switches? 
> >  
> > 
> > yes, you came back to the question I answered in above ;-)
> > so, please see above. 
> > GMPLS enabled nodes must be positioned at points congestion 
> > is likely to be expected. 
> >  
> > Thanks
> >  
> > Jaihyung
> >  
> > 
> > ============================================
> > 
> >  
> > 
> > -----?? ???-----
> > ?? ??: "richard.spencer@bt.com" <richard.spencer@bt.com> 
> > ?? ??: 2005-07-13 ?? 8:53:13 
> > ?? ??: "jaihyung@etri.re.kr" <jaihyung@etri.re.kr>, 
> > "ccamp@ops.ietf.org" <ccamp@ops.ietf.org> 
> > ??: 
> > ??: RE: End-to-end L2-LSP 
> > 
> > 
> > 
> > 
> > Jaihyung,
> > 
> > Perhaps I'm becoming too much of a pessimist;-) Ignoring the
> > commercial aspects, please can you help clarify a few 
> > technical questions I have in order to help me gain a better 
> > understanding of the proposal? 
> > 
> > 1. You say that one of the key reasons for using GMPLS in the
> > enterprise network is to provide end-to-end QoS control. 
> > However, you also say that not all the switches will need to 
> > support GMPLS, only those at bottle necks. Please can you 
> > expand on this to explain how you can have end-to-end QoS 
> > control when the L2-LSP is not end-to-end? As being discussed 
> > on the PWE3 mailing list, the performance a service receives 
> > is only as good as the worst performing server layer. 
> > Therefore, if there is a standard 802.1 workgroup switch 
> > between the user and the L2-LSP that is experiencing 
> > congestion (e.g. due to a large amount of peer-to-peer 
> > traffic), then the QoS that the user receives will only be as 
> > good as that provided by the congested workgroup switch. 
> > 
> > The only way I can see a network using a mixture of GMPLS and
> > non-GMPLS switches guaranteeing end-to-end QoS would be to 
> > design the network in such a way that the non-GMPLS switches 
> > could never become congested. To do this would require that 
> > RSVP requests be used for ALL traffic flows to ensure that 
> > there was enough bandwidth available, along with strict per 
> > L2-LSP policing on the user devices (e.g. PC). However, the 
> > obvious flaw in this approach is that someone could just come 
> > along and connect an end device to a non-GMPLS switch and 
> > start transmitting traffic (without performing CAC/policing) 
> > causing the switch to become congested. Therefore, please can 
> > you explain how end-to-end QoS can be guaranteed in a mixed 
> > non-GMPLS and GMPLS switching environment? 
> > 
> > 2. Section 5.1 currently states "When the customer initiates
> > data transmission, the access switch maps the user flow into 
> > the L2 LSP. Mapping procedure is subject to implementation 
> > choices, and is out of the scope of this document." In order 
> > to be able to map any traffic, first of all the switch needs 
> > to know what type of traffic (e.g. based on source/dest MAC, 
> > VLAN ID, 802.1p bits, etc) should be mapped to the L2-LSP. In 
> > Figure 1, if an L2-LSP is set up from the DSLAM to the edge 
> > router based on a request from the user (e.g. via a PC or 
> > VoIP phone), then won't the user also need to signal what 
> > type of traffic should to be mapped to the L2-LSP? 
> > 
> > 3. In section 5.1, the text states that the aggregation
> > switch between the DSLAM and edge router may be a 802.1 
> > switch, i.e. it doesn't have to support GMPLS. To set up a 
> > connection, first of all there needs to be a data plane 
> > capable of carrying control plane traffic between GMPLS 
> > peers. Secondly, the GMPLS peers need reachability 
> > information in order to forward control messages onto the 
> > next peer (i.e. a static or IGP route). If the GMPLS peers 
> > (e.g. the DSLAM and edge router in Figure 1) are not directly 
> > connected, then the GMPLS control packets will need to be 
> > forwarded by the 802.1 switch. Would the idea be to have say 
> > a "control traffic VLAN" configured between the DSLAM and 
> > edge router via the transit 802.1 switch so that control 
> > packets could be forwarded transparently by the 802.1 switch? 
> > 
> > 4. If we assume that control messages can be transparently
> > forwarded by the intermediate 802.1 aggregation switch then 
> > how are user frames forwarded in the data plane by the 802.1 
> > switch? If the DSLAM sets up a L2-LSP to the edge router 
> > using say VLAN ID 99, how does the switch know that any 
> > packets coming in with a VLAN ID of 99 should be forwarded 
> > out of the port connecting to the edge router? 
> > 
> > 5. During connection setup, I take it that the GMPLS peers
> > assume that resources are available within the intermediate 
> > 802.1 switch to support the connection (as its transparent). 
> > However, as there is no CAC/policing being performed by the 
> > 802.1 switch (the L2-LSPs are transparent), and due to the 
> > any-to-any and broadcast based nature of Ethernet (i.e. its 
> > CL properties), then how can this assumption be made? This 
> > comes back to my original question, how can end-to-end QoS be 
> > guaranteed in an environment where there is a mixture of 
> > 802.1 and GMPLS enabled switches? 
> > 
> > Thanks,
> > Richard 
> > 
> > > -----Original Message-----
> > > From: CHO, JAI HYUNG [mailto:jaihyung@etri.re.kr] 
> > > Sent: 12 July 2005 09:21 
> > > To: Spencer,R,Richard,XDE73 R; ccamp@ops.ietf.org 
> > > Subject: 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 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> 
> 
> 
> 
>