RE: End-to-end L2-LSP

["CHO, JAI HYUNG" <jaihyung@etri.re.kr>]

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