RE: End-to-end L2-LSP

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

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" <jaihyung@etri.re.kr> 
?? ??: 2005-07-21 ?? 11:59:07 
?? ??: "richard.spencer@bt.com" <richard.spencer@bt.com>, "ccamp@ops.ietf.org" <ccamp@ops.ietf.org> 
??: 
??: RE: End-to-end L2-LSP 







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

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 




-----?? ???----- 
?? ??: "richard.spencer@bt.com" <richard.spencer@bt.com> 
?? ??: 2005-07-21 ?? 12:09:56 
?? ??: "jaihyung@etri.re.kr" <jaihyung@etri.re.kr>, "ccamp@ops.ietf.org" <ccamp@ops.ietf.org> 
??: 
??: RE: End-to-end L2-LSP 



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 

> -----Original Message----- 
> From: CHO, JAI HYUNG [mailto:jaihyung@etri.re.kr] 
> Sent: 14 July 2005 04:24 
> To: Spencer,R,Richard,XDE73 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 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> 
> 
> 
>