Subject: End-to-end L2-LSP

From: "CHO, JAI HYUNG" <[email-masked]>
Date: Tue, 12 Jul 2005 09:09:31 +0900

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

---

From: <[email-masked]>
Date: Tue, 12 Jul 2005 08:09:49 +0100

Jaihyung Cho,

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: [email-masked] [mailto:[email-masked]]On
> Behalf Of CHO, JAI HYUNG
> Sent: 12 July 2005 01:10
> To: [email-masked]
> Subject: End-to-end L2-LSP
> 
> 
>  
> Dear all,
> 
> Greetings.
>

---

From: "CHO, JAI HYUNG" <[email-masked]>
Date: Tue, 12 Jul 2005 17:20:49 +0900

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

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

Regards, 
Richard

---

From: <[email-masked]>
Date: Wed, 13 Jul 2005 12:53:13 +0100

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

> From: CHO, JAI HYUNG [mailto:[email-masked]]
> Sent: 12 July 2005 09:21
> To: Spencer,R,Richard,XDE73 R; [email-masked]
> Subject: RE: End-to-end L2-LSP
> 
> 
> 
> 
> Dear Richard,
> 
> 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 
>

---

From: "CHO, JAI HYUNG" <[email-masked]>
Date: Wed, 13 Jul 2005 23:14:22 +0900

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

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

-----?? ???----- 
?? ??: "[email-masked]" <[email-masked]> 
?? ??: 2005-07-13 ?? 8:53:13 
?? ??: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]> 
??: 
??: RE: End-to-end L2-LSP 

Jaihyung, 

Thanks, 
Richard

---

From: <[email-masked]>
Date: Wed, 13 Jul 2005 17:10:30 +0100

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

> Sent: 13 July 2005 15:14
> ?? ??: "[email-masked]" <[email-masked]>, 
> "[email-masked]" <[email-masked]> 
> ??: 
> 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 
>

---

From: "CHO, JAI HYUNG" <[email-masked]>
Date: Thu, 14 Jul 2005 12:24:26 +0900

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 

-----?? ???----- 
?? ??: "[email-masked]" <[email-masked]> 
?? ??: 2005-07-14 ?? 1:10:30 
?? ??: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]> 
??: 
??: 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 upg!
 rading the user devices to support the set up of L2-LSPs. 

Regards, 
Richard 

> is only as 
> data transmission, 
> VLAN ID, 802.1p 
> switch between the 
> peers. Secondly, 
> assume that

---

From: <[email-masked]>
Date: Fri, 15 Jul 2005 17:20:56 +0100

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of CHO, JAI HYUNG
> Sent: 14 July 2005 04:24
> To: Spencer,R,Richard,XGH5 R; [email-masked]
> 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 
> 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 
> forwarded

---

From: <[email-masked]>
Date: Wed, 20 Jul 2005 16:09:56 +0100

Jaihyung,

I agree that extending signalling down to the end-user is one possible solution to address charging/billing issues, another possible solution would be to use session based billing. I also agree that using L2-LSPs could be a viable solution for providing traffic separation and bandwidth guarantees in a service providers network, another possible solution would be to extended MPLS into the access network.

However, if you want to extend L2-LSPs (not just signalling) down to the end user, then there are a number of complicated technical and commercial issues that must be overcome. Please see below for some of the key issues:

1. If you want to eliminate the possibility of congestion in the enterprise/home network using L2-LSPs for the reasons you give below, then on every node in the network you will need:

- A CPU: for control plane protocol processing
- Routing: At least static, an IGP for large networks and OSPF-TE if TE is required
- Signalling: RSVP-TE
- Policing: Per connection policing, e.g. per VLAN

I do not know how much it would cost to upgrade the $20 five port 10/100 switch sitting on my desk to support all this, but I do not believe this would be a trivial amount, particularly at the volumes demanded by enterprises. In addition, a hierarchical architecture would be required for the solution to scale and therefore aggregation switches within the enterprise network would also need to support hierarchical CAC and policing.

2. Unless you want to reinvent LANE, then you will need to continue to support CL Ethernet broadcasts and multicasts on GMPLS enabled switches. To protect the L2-LSP traffic from CL broadcast traffic you could rate limit it to say 1% of the bandwidth available. However, how would you capacity plan for and rate limit (dynamic, receiver driven) multicast traffic for which usage patterns are difficult to predict? In my opinion you will need to use over provisioning along with CoS, which would raise the question, why is over provisioning and CoS OK for multicast traffic (which could be critical, e.g. trading floor information), but not OK for unicast traffic?

3. Routers are relatively stable systems that are switched on permanently and therefore RSVP-TE sessions are stable and only go down when there is a failure. End user systems however such as PCs, set top boxes, games consoles, etc. are not always switched on and are not as stable. What will the effect on the network be when large number of RSVP-TE sessions are going up/down, e.g. as a result of game console resets or PC crashes/freezes? These effects will ripple through the enterprise/home network into the operators network, and therefore mechanisms must be put in place to protect against them.

4. When an IP device wants to forward a packet it uses ARP to discover the MAC address of the IP next hop (unless its already in the MAC table) and adds the Ethernet header before forwarding the packet on. Now, if you want to extend connections down to the end user device, then the device will need to map IP traffic to different L2-LSPs. A simple 1-to-1 mapping between an IP next hop address and a MAC address will not be sufficient as there may be multiple connections (e.g. using different VLAN IDs) associated with an IP next hop. So, policies will need to be configured on end user devices to map IP traffic (e.g. based on src/dest IP address, port numbers, etc.) to a specific L2-LSP (e.g. based on src/dest MAC address and/or VLAN ID).  

5. End user devices such as PCs and VoIP phones are likely to only need to support a relatively low number of L2-LSPs. However, devices such as content servers and call servers/gateways will need to support hundreds/thousands of L2-LSPs. Connection setup and state maintenance for large numbers of L2-LSPs will consume a significant amount of processing resources, as will policies to map IP traffic to the different L2-LSPs. Therefore, I would expect that the system software (and possibly hardware) will need to be designed from the ground up to be able to support large numbers of L2-LSPs.

6. Enterprise networks are built using not just switches but routers as well. Firstly, for L2-LSPs to be set up between switches and routers, they must belong to the same address space to communicate with each other. However, this address space must be separate from the IPv4 forwarding address space. To use an example of why this is true, routers connected via Ethernet segments are considered to be directly connected, however, if the IPv4 and L2-LSP address spaces were the same, then IP routers separated by GMPLS switches would be multiple hops away from each other. In addition to address space separation, routing protocol instances must also be separated. This need for this separation is obvious when considering using a link state routing protocol which relies on a topological view of the network, i.e. the IPv4 and L2-LSP topologies are different. 

Secondly, routers break up Ethernet segments and must therefore must always be the headend or tailend for a L2-LSPs, i.e. they cannot be midpoints. This means that from a control plane perspective, on receiving a L2-LSP path message a router must terminate the LSP and send back a resv message whether it is the intended destination/sink or not. It must then originate a path message for a new L2-LSP and send it onto the next hop GMPLS switch. This is not how RSVP-TE works today and therefore will require modifications. In addition, traffic will be blackholed if transmitted by the source before all the separate L2-LSPs have been setup end-to-end to the sink/destination. This means that some kind of end-to-end signalling message will need to be sent by the sink/destination once the final L2-LSP has been established to inform the source that the end-to-end connectivity has been provided. This functionality is not supported by RSVP-TE today and will therefore require protocol modifications.

Thirdly, routers forward packets based on information in the IP header. So, when a router receives a packet via a L2-LSP it will strip of the L2 header and perform an IP lookup. Now, for the packet to be forwarded using the correct L2-LSP the router must have a policy that tells it which L2-LSP to use as there may be multiple L2-LSPs to the same destination, e.g. for different voice calls or video downloads. However, before a policy can even be configured, the router needs to know what traffic (e.g. based on src/dest address, port number, DSCP, etc.) to map to which L2-LSP, and this information needs to come from the traffic source using signalling, i.e. RSVP-TE. I do not believe this is supported today and will therefore require modifications.

Regards,
Richard

> anticipated 
> constraining 
> to support 
> > [mailto:[email-masked]]On 
> > > > Behalf Of CHO, JAI HYUNG 
> > > > Sent: 12 July 2005 01:10 
> > > > To: [email-masked]

---

From: "CHO, JAI HYUNG" <[email-masked]>
Date: Thu, 21 Jul 2005 23:59:07 +0900

Hi, Richard,
 
Thank you for your tons of questions. 
It is a bit hard to answer in single mail. 
So, I divided it in two pieces. 
Here I send you the first part of answers to questions 1~5.

>I agree that extending signalling down to the end-user is one 
>possible solution to address charging/billing issues, another possible 
>solution would be to use session based billing. I also agree that using 
>L2-LSPs could be a viable solution for providing traffic separation 
>and bandwidth guarantees in a service providers network, another 

Indeed, that's one important message I wanted to cast in this WG. 
Not only this is technically interesting, but the behind goal is about 
improving income structure of Internet service providers. 
I hope this can be an answer to the issue of QoS&Pricing 
that Neil Harrison once noted in last mail of this thread.
 
Customers may basically use cl-ps service in fixed rate base, and 
when they need real-time service such as IP-TV or video phone, 
they may request simple CBR-like co-ps SVC-based service 
(i.e. L2-LSP) over cl-ps network using GMPLS signal. 
This way, operators may improve their service structure and invest 
to upgrade their access network.

[snip]
>1. If you want to eliminate the possibility of congestion in the 
>enterprise/home network using L2-LSPs for the reasons you 
>give below, then on every node in the network you will need: 
> 
>I do not know how much it would cost to upgrade the $20 five 
>port 10/100 switch sitting on my desk to support all this, 
>but I do not believe this would be a trivial amount, particularly 
>at the volumes demanded by enterprises. 

I guess your five port $20 switch will be connected to machines 
owned only by you. If you can control resource usage of your 
machines, you don't need GMPLS implemented switch. 
However, if you need to share a switch with some of your colleague, 
I will recommend spending more that $20 on switch in order to enjoy 
nice video communication while your colleague abusing your 
network with P2P file transfer. I think this is worth while to spend 
money considering importance of your personal communication. 
As I noted in previous mail, GMPLS implemented switch will be 
necessary in nodes where automated resource control is crucial.

>In addition, a hierarchical 
>architecture would be required for the solution to scale and 
>therefore aggregation switches within the enterprise network 
>would also need to support hierarchical CAC and policing.

This is beyond issue we can discuss at the moment. 
I'd like further technical discussion, however, 
I think we need to wait until this idea of L2-LSP is 
officially chartered in CCAMP. 
I hope enough number of people support the idea that 
we can continue work on this issue.

>2. Unless you want to reinvent LANE, then you will need to 
>continue to support CL Ethernet broadcasts and multicasts on 
>GMPLS enabled switches. To protect the L2-LSP traffic from 
>CL broadcast traffic you could rate limit it to say 1% of 
>the bandwidth available. However, how would you capacity 
>plan for and rate limit (dynamic, receiver driven) multicast 
>traffic for which usage patterns are difficult to predict? 
>In my opinion you will need to use over provisioning along with CoS, 
>which would raise the question, why is over provisioning 
>and CoS OK for multicast traffic 
>(which could be critical, e.g. trading floor information), 
>but not OK for unicast traffic?

There will be a technical solution for multicast and broadcast. 
A member of DT once showed his interest on multicast solution 
for Ethernet using RSVP instead of IGMP. 
I also have an idea of extending point-to-point L2-LSP to 
multipoint L2-LSP as similar way that learning bridges 
learn backward path from source address.

However, I have some doubt on necessity of multicast service. 
Do we really need multicast for streaming service in local/access ? 
I think even IP-TV will be better serviced using point-to-point 
connection in access network. 
There's very low chance of two subscribers receiving same channel 
at the same time if the receiver group is not that great. 
Multicasting is necessary in core network, however I doubt the 
same needs in local/access network, except some rare case.
 
>3. Routers are relatively stable systems that are switched on 
>permanently and therefore RSVP-TE sessions are stable 
>and only go down when there is a failure. End user systems 
>however such as PCs, set top boxes, games consoles, etc. 
>are not always switched on and are not as stable. 
>What will the effect on the network be when large number 
>of RSVP-TE sessions are going up/down, e.g. as a result 
>of game console resets or PC crashes/freezes? 
>These effects will ripple through the enterprise/home 
>network into the operators network, and therefore mechanisms 
>must be put in place to protect against them.

Control overhead of RSVP was discussed a lot in conjunction with IntServ. 
There have been proposals to reduce the overhead in core network 
such as RFC3175 or [HIER]. In particular, proposed architecture for 
LSP aggregation [HIER] will greatly help to solve the issue.

% [HIER] draft-ieft-mpls-lsp-hierarchy-08.txt

>4. When an IP device wants to forward a packet it uses ARP 
>to discover the MAC address of the IP next hop 
>(unless its already in the MAC table) and adds the Ethernet 
>header before forwarding the packet on. Now, if you want to 
>extend connections down to the end user device, then the 
>device will need to map IP traffic to different L2-LSPs. 
>A simple 1-to-1 mapping between an IP next hop address 
>and a MAC address will not be sufficient as there may 
>be multiple connections (e.g. using different VLAN IDs) 
>associated with an IP next hop. So, policies will need 
>to be configured on end user devices to map IP traffic 
>(e.g. based on src/dest IP address, port numbers, etc.) 
>to a specific L2-LSP (e.g. based on src/dest MAC address and/or VLAN ID). 

You pointed out important issue. 
Currently, Ethernet layer only maps IP and MAC in 1-to-1. 
Unless Ethernet-IP interface is extended as you suggested, 
users must be satisfied with at most single L2-LSP established 
between machine to machine. If they want another connection, 
they have to disconnect previous connection. 
This scenario will be OK in most real-life applications. 
However in future, extension to layer interface will be necessary 
and the solution should be consulted with IEEE.

>5. End user devices such as PCs and VoIP phones are 
>likely to only need to support a relatively low number 
>of L2-LSPs. However, devices such as content servers 
>and call servers/gateways will need to support 
>hundreds/thousands of L2-LSPs. Connection setup and 
>state maintenance for large numbers of L2-LSPs will 
>consume a significant amount of processing resources, 
>as will policies to map IP traffic to the different L2-LSPs. 
>Therefore, I would expect that the system software 
>(and possibly hardware) will need to be designed from 
>the ground up to be able to support large numbers of L2-LSPs.

Some high-performance servers are capable of handling 
millions of TCP connections. 
I believe the added complexity for LSP connection 
will not be far greater that the work-load normally assumed 
in contemporary servers.

It may be a problem to local gateways if the signaling load 
is not bypassed. However, even in this case, there can be 
some solutions we can devise.
ok, for rest of questions, 
I'll reply it in next mail. 

thanks

Jaihyung 

-----?? ???----- 
?? ??: "[email-masked]" <[email-masked]> 
?? ??: 2005-07-21 ?? 12:09:56 
?? ??: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]> 
??: 
??: RE: End-to-end L2-LSP 

Jaihyung, 

Secondly, routers break up Ethernet segments and must therefore must always be the headend or tailend for a L2-LSPs, i.e. they cannot be midpoints. This means that from a control plane perspective, on receiving a L2-LSP path message a router must terminate the LSP and send back a resv message whether it is the intended destination/sink or not. It must then originate a path message for a new L2-LSP and send it onto the next hop GMPLS switch. This is not how RSVP-TE works today and therefore will require modifications. In addition, traffic will be blackholed if transmitted by the source before all the separate L2-LSPs have been setup end-to-end to the sink/destination. This means that some kind of end-to-end signalling message will need to be sent by the sink/destination once the final L2-LSP has been established to inform the source that the end-to-end connectivity has been provided. This functionality is not supported by RSVP-TE today and will therefore require protocol modi!
 fications. 

Regards, 
Richard

---

From: "CHO, JAI HYUNG" <[email-masked]>
Date: Mon, 25 Jul 2005 19:14:28 +0900

Hi, Richard

Here's continued part of reply to your original question. 
reply to the questions 1~5 are also enclosed below.

>6. Enterprise networks are built using not just switches 
>but routers as well. Firstly, for L2-LSPs to be set up 
>between switches and routers, they must belong to 
>the same address space to communicate with each other. 
>However, this address space must be separate from the 
>IPv4 forwarding address space. To use an example 
>of why this is true, routers connected via Ethernet 
>segments are considered to be directly connected, however, 
>if the IPv4 and L2-LSP address spaces were the same, 
>then IP routers separated by GMPLS switches would be 
>multiple hops away from each other. In addition to address 
>space separation, routing protocol instances must also be separated. 
>This need for this separation is obvious when considering 
>using a link state routing protocol which relies on a topological 
>view of the network, i.e. the IPv4 and L2-LSP topologies are different.

Allow me a bit lengthy writing at this time, because there's 
some message I want to tell you and people who might read this.

I think routing of GMPLS signal should be different 
in the access/enterprise network. 
If GMPLS implemented Ethernet switch aims to replace some core routers, 
it has to offer the same routing property as core routers do. 
However, if a vendor targets Ethernet market using the GMPLS 
implemented switch, the switch must be able to offer similar 
characteristics as Ethernet switches. 
In Ethernet, such notion of addressing and routing configuration 
as in IGP doesn't exist. The only routing feature Ethernet has is 
'broadcast, MAC learning, and filtering'. 
(%note: STP, MSTP, etc. must be seen in different perspective in this context)

This simplistic mind of routing results in successful acceptance 
of Ethernet. 
Now ordinary users may purchase and install Ethernet switch 
without burden of complex network configuration. Access network 
engineers are able to install Ethernet switches quickly in many 
outdoor sites because manual work is relatively simple. 
This helps reducing labor cost and OPEX a lot. 
In summary, what made Ethernet proliferating is the lightweightness, 
i.e. no manual numbering on ports, near-zero configuration, 
dynamic learning, broadcast & filtering, etc.

Such lightweightness can also be achieved in GMPLS 
when GMPLS signal doesn't rely on IP routing protocols, 
such as link-status or distance vector algorithm, but itself has 
controlled broadcast and learning capability as seen in Ethernet.

Ethernet learns destination MAC address from ARP broadcast. 
The switch optimizes data path from dynamic learning of backward path. 
Similarly, GMPLS signal may also be broadcast in a controlled way. 
Destination host group or access point to core network can be 
found from broadcast. L2-LSP can be establishment via the path 
learned from broadcast if the broadcast path is systematically recorded.

You may reference <draft-jaihyung-ccamp-arpsignal-00.txt> 
for detail of such routing method. Although the draft was written 
for ARP signaling, it can also be applied to RSVP-TE. 
I'll soon submit updated flood-routing method for RSVP-TE. 

The key message I want to tell is, 
the GMPLS control stack can be simplified if routing and signaling 
are merged in unified protocol. 
I'm sure this approach doesn't have the problem of routing hop 
or address space separation as you raised above.

>Secondly, routers break up Ethernet segments and must therefore 
>must always be the headend or tailend for a L2-LSPs, i.e. they 
>cannot be midpoints. This means that from a control plane perspective, 
>on receiving a L2-LSP path message a router must terminate the LSP 
>and send back a resv message whether it is the intended destination/sink 
>or not. It must then originate a path message for a new L2-LSP 
>and send it onto the next hop GMPLS switch. This is not how 
>RSVP-TE works today and therefore will require modifications. 
>In addition, traffic will be blackholed if transmitted by the source 
>before all the separate L2-LSPs have been setup end-to-end to 
>the sink/destination. This means that some kind of end-to-end 
>signalling message will need to be sent by the sink/destination 
>once the final L2-LSP has been established to inform the source 
>that the end-to-end connectivity has been provided. This functionality 
>is not supported by RSVP-TE today and will therefore require protocol modifications.

I agree in the point that routers break up L2-LSP connectivity. 
There's no way to provide end-to-end L2-LSP connectivity 
across L3 routers unless the routers are capable of supporting 
L2SC GMPLS. Perhaps local routers, gateways and edge routers are the 
first target to deploy L2SC GMPLS rather than Ethernet switches.

It is also no doubt some extension to RSVP-TE for L2SC will be 
necessary for end-to-end exchange of RSVP-TE. 
Clearly things that you pointed out need to be done.

>Thirdly, routers forward packets based on information in the IP header. 
>So, when a router receives a packet via a L2-LSP it will strip of the 
>L2 header and perform an IP lookup. Now, for the packet to be 
>forwarded using the correct L2-LSP the router must have a policy 
>that tells it which L2-LSP to use as there may be multiple 
>L2-LSPs to the same destination, e.g. for different voice calls or 
>video downloads. However, before a policy can even be configured, 
>the router needs to know what traffic (e.g. based on src/dest address, 
>port number, DSCP, etc.) to map to which L2-LSP, and this information 
>needs to come from the traffic source using signalling, i.e. RSVP-TE. 
>I do not believe this is supported today and will therefore require modifications.

Before you reach this conclusion, I want you look again where the 
source of problem is originated. 
If routers simply dispose MAC information, the router is losing 
important information to determine forwarding policy. 
The policy should have been known priori during LSP 
establishment time using RSVP-TE. This information is encoded 
in L2 label by ingress, thus the egress router should be able to 
keep the label information and use it for determining 
next L2-LSP to map. 
If a router doesn't have such capability of L2SC GMPLS, 
of course the policy decision will be that complex.

Sincerely,

Jaihyung 

 
-----?? ???----- 
?? ??: "CHO, JAI HYUNG" <[email-masked]> 
?? ??: 2005-07-21 ?? 11:59:07 
?? ??: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]> 
??: 
??: RE: End-to-end L2-LSP 

Hi, Richard, 

[snip] 

thanks 

Jaihyung 

-----?? ???----- 

Jaihyung, 

Regards, 
Richard