RE: Frameformat in a l2cs gmpls rnvironment.

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

hi, Juergen
 
see some in-line below,
 

>> 3. use lower 3 bytes of MAC address for L2 label encoding. 
>> 
>> 802.1Q bridge forwards Ethernet frames using two dataplane tables 
>> - MAC forwarding table and VLAN forwarding table. 
>> Bridge control protocols, such as GARP, GVRP, GMRP, 
>> manipulate one of the two dataplane entities. 
>> 
>> Similarly, option 1 and 3 are about which one of two 
>> dataplane entities 
>> GMPLS protocol should control on behalf of bridge control protocols. 
>> The two proposals do not intend to modify bridge behavior 
>> seriously, such as MAC learning, aging, filtering. 
>> Therefore, the approaches 1 and 3 are in the scope of CCAMP. 
> 
>Even so your option 3 may not change the hardware it totaly changes 
>the forwarding behaviour as it redefines the meaning of a MAC address. 
>The MAC address is a end station address that identfies the source 
>and sink of the MAC frame. In your proposal it will be used as link 
>local label. 
 

There's no (in principle) physical change in the MAC forwarding behavior. 
GMPLS will configure MAC forwarding entry as if static entry 
is configured in MAC table by operator.

Suppose a network that Ethernet bridges interconnect routers. 
Normally single L2 data path is established between routers by MAC learning. 
If an operator manually configure another MAC forwarding path in the 
bridges, two L2 paths are established between routers.

Of course such configuration is not possible in 802.1 bridged network. 
However, GMPLS implementation may automate such configuration 
of semi-static MAC forwarding entry that otherwise be configured 
manually by operator.
 

>It would be the same as if MPLS would use a dedicated 
>IP address range as lable instead of its own label.
 

You may think it different perspective. 
MPLS forwards data using shim header, and the shim label is, 
again, encapsulated by Ethernet header. From the view of 
input and output link, Ethernet header (i.e. MAC addresses) is 
replaced at every hop together with shim label.

What if the router knows which Ethernet header is to be replaced 
to which Ethernet header in next link? Does it still need to lookup 
MPLS shim header at L3 level? In this case, it is sufficient for 
the switch performing swap operation in L2SC level. 
 
The whole idea of GMPLS is employing common control over 
underlying transport method, and in the case of Ethernet, 
the major transport method of Ethernet frame is MAC forwarding 
using Ethernet address, and so is GMPLS implementation for Ethernet.
 

>What will happen with the original MAC address when you enter 
>such a GMPLS Ethernet domain? Will you add a new "MAC header"?
 
 
You are actually referring three cases,

1. in local network that host forwards Ethernet frame via L2-LSP 
2. in core edge that provides L2VPN service 
3. in network that legacy switch and GMPLS switches are 
   interconnected.
 
In 1, Ethernet address is swapped to GMPLS prefixed address 
and forwarded via established L2-LSP.

In 2, user frames are encapsulated as you said.

In 3, normal Ethernet frames are forwarded via normal STP path, 
however GMPLS frames may be forwarded via different path 
established using RSVP-TE.

...... 
>> 
>> The benefit of L2SC switch is explained in section 4 of 
>> <draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt> 
>> 
>> Overall objective is improving scalability, traffic engineering (TE) 
>> characteristics of 802.1 bridge that it can be reliable, manageable 
>> enough to replace some core routers. 
> 
>This is also provided by Ethernet over MPLS even with label stacking.
 

but not by Ethernet bridges. 
When the price of Ethernet bridge is compared to MPLS router just by 
port and switching capacity, it is nearly ten times cheaper. 
What we are trying to do is delivering the capability of MPLS switch 
at the price of Ethernet switch.
 

>> The switching technique you mentioned above, such as 
>> Ethernet over MPLS as defined by PWE3 and L2VPN, 
>> are all actually router based technology, however this 
>> work is based on simple bridge architecture. 
>> Cost-effectiveness is the key differentiator. 
>> 
>This is what I hear often and what I mean with "we still call 
>it Ethernet as it will be cahep and simple as todays Ehternet". 
>In the end the same functionality is needed: lable lookup, 
>label swapping, signaling protocol, routing protocol, discovery protocol, ... 
>So from the functionality and architecture point of view no difference exists.
 

I understand well how today's routers become a machine of millions of gates. 
This is the solution I struggled for some years to simplify it best. 
That's why I am trying to preserve the original simplicity of hardware 
architecture of 802.1 Ethernet bridge. 
 
 

>One advantage compared to Ethernet over MPLS I see, is that 
>MPLS has to be again mapped into Ethernet for transport. 
>This addtional Ethernet layer is not needed.
>In your response to Richard you mention to use a simpler routing 
>for Ethernet in this enviroment using dynamic learning like in Ethernet. 
>How about a unified GMPLS control plane and restoration. 
>Will you introduce another spanning tree?
 
 

No, I'll just propose another way to achieve TE-LSP 
without relying on pre-established routing table. 
Please take a time to see 
<draft-jaihyung-ccamp-arpsignal-00.txt> 
and read the section about flood-routing.
 

thanks
 
Jaihyung 

 

-----?? ???----- 
?? ??: "Heiles Juergen" <juergen.heiles@siemens.com> 
?? ??: 2005-07-25 ?? 9:32:40 
?? ??: "CHO, JAI HYUNG" <jaihyung@etri.re.kr>, "Heiles Juergen" <juergen.heiles@siemens.com>, "per@defero.se" <per@defero.se> 
??: "ccamp@ops.ietf.org" <ccamp@ops.ietf.org> 
??: RE: Frameformat in a l2cs gmpls rnvironment. 






Dear Jaihyung, 

the discussion now goes too much into implementations, however I would like to add my comments/questions. 

Regards 

Juergen 



> -----Original Message----- 
> From: CHO, JAI HYUNG [mailto:jaihyung@etri.re.kr] 
> Sent: Monday, July 25, 2005 1:40 PM 
> To: Heiles Juergen; per@defero.se 
> Cc: ccamp@ops.ietf.org 
> Subject: RE: Frameformat in a l2cs gmpls rnvironment. 
> 
> 
.... 
> 3. use lower 3 bytes of MAC address for L2 label encoding. 
>  
> 
> 802.1Q bridge forwards Ethernet frames using two dataplane tables 
> - MAC forwarding table and VLAN forwarding table. 
> Bridge control protocols, such as GARP, GVRP, GMRP, 
> manipulate one of the two dataplane entities. 
> 
> Similarly, option 1 and 3 are about which one of two 
> dataplane entities 
> GMPLS protocol should control on behalf of bridge control protocols. 
> The two proposals do not intend to modify bridge behavior 
> seriously, such as MAC learning, aging, filtering. 
> Therefore, the approaches 1 and 3 are in the scope of CCAMP. 

Even so your option 3 may not change the hardware it totaly changes the forwarding behaviour as it redefines the meaning of a MAC address. The MAC address is a end station address that identfies the source and sink of the MAC frame. In your proposal it will be used as link local label. It would be the same as if MPLS would use a dedicated IP address range as lable instead of its own label. 
What will happen with the original MAC address when you enter such a GMPLS Ethernet domain? Will you add a new "MAC header"? 

...... 
> 
> The benefit of L2SC switch is explained in section 4 of 
> <draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt> 
> 
> Overall objective is improving scalability, traffic engineering (TE) 
> characteristics of 802.1 bridge that it can be reliable, manageable 
> enough to replace some core routers. 

This is also provided by Ethernet over MPLS even with label stacking. 

> The switching technique you mentioned above, such as 
> Ethernet over MPLS as defined by PWE3 and L2VPN, 
> are all actually router based technology, however this 
> work is based on simple bridge architecture. 
> Cost-effectiveness is the key differentiator. 
>  
This is what I hear often and what I mean with "we still call it Ethernet as it will be cahep and simple as todays Ehternet". 
In the end the same functionality is needed: lable lookup, label swapping, signaling protocol, routing protocol, discovery protocol, ... 
So from the functionality and architecture point of view no difference exists. 
One advantage compared to Ethernet over MPLS I see, is that MPLS has to be again mapped into Ethernet for transport. This addtional Ethernet layer is not needed. 
In your response to Richard you mention to use a simpler routing for Ethernet in this enviroment using dynamic learning like in Ethernet. How about a unified GMPLS control plane and restoration. Will you introduce another spanning tree? 



> 

..