RE: Frameformat in a l2cs gmpls rnvironment.

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

Richard, 
 
IEEE recommends to use Ethernet Length/Type code for distinguishing control frames.
All GARP, GVRP, GMPR and other proposed OAM frame follow this rule.
IEEE particulary discourages using some number in data forwarding address 
being used for exchange of control data. An example is using some multicast address 
for exchange of hello frames. This rule is also applied to the case of VLAN forwarding.
I think this policy is to prevent control chaos with other L2 protocols.
We need to be careful in taking approach to use some L2-LSP exclusively 
for control plane because it may result in unwanted conflict with both people and machine.
 
Regards,
 
Jaihyung
 

-----?? ???----- 
?? ??: "richard.spencer@bt.com" <richard.spencer@bt.com> 
?? ??: 2005-07-22 ?? 8:44:08 
?? ??: "per@defero.se" <per@defero.se>, "loa@pi.se" <loa@pi.se> 
??: "ccamp@ops.ietf.org" <ccamp@ops.ietf.org> 
??: RE: Frameformat in a l2cs gmpls rnvironment. 



Regardless of whether or not a switch is directly connected to hosts, it must be able to forward packets using the connectionless Ethernet data plane. This is due to the fundamental requirement that for GMPLS switches to be able to exchange control information with each other, a data plane for control traffic must be present. This is akin to using the IP data plane for MPLS signalling in an IP/MPLS network. An alternative would be to use a static reserved L2-LSP for control traffic in the same way that reserved VPI/VCIs are used for PNNI signalling in ATM. 

Regarding connecting hosts to GMPLS switches, I personally don't think extending L2-LSPs into the enterprise/home network is commercially viable. However, if you do want to use GMPLS switches in the home/enterprise network and for some reason don't want to extend L2-LSPs down to the host then you will not be performing normal Ethernet Mac address switching anyway. Instead you will need some kind of policy on the switch that maps connectionless Ethernet packets (e.g. based on MAC src/dest, 802.1p, VLAN) to a L2-LSP. This is because multiple L2-LSPs to the same destination (e.g. a gateway router) may exist for different services/flows (e.g. video download, VoIP call, etc.). 

Regards, 
Richard 

> -----Original Message----- 
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On 
> Behalf Of Par Mattsson 
> Sent: 22 July 2005 11:42 
> To: Loa Andersson 
> Cc: ccamp@ops.ietf.org 
> Subject: Re: Frameformat in a l2cs gmpls rnvironment. 
> 
> 
> > Per and Dimitri, 
> > 
> > I would like to come down stronger than that, for me it is 
> > a very strong requirement that the same switch can handle 
> > both VLANs and GMPLs trafic correctly. I can't dsee how that 
> > could be done if using the VLAN tpid to indicate GMPLS 
> > traffic. 
> 
> If you ever want that same switch to handle traffic for a directly 
> connected  host (not to uncommen) you would want that to use normal 
> ethernet macaddress switching. So of course you do not want to have to 
> choose between vlan and gmpls, you would want both at the same time. 
> 
> /per 
> 
> 
> > 
> > /Loa 
> > 
> > Par Mattsson wrote: 
> >>>hi par, one of the possibilities that has been considered 
> to cope with 
> >>>this requirement is to use a dedicated TPID for the 
> Ethernet labeled 
> >>>frames; this would allow differentiated processing with non-labeled 
> >>>framesthanks. 
> >> 
> >> 
> >> That seems to make more sence. If that frame is to be sized like a 
> >> 802.1q 
> >> frame. There is not that much space left to a label. Or is 
> the demand to 
> >> use jumboframes ? 
> >> Has there been any discussion on labelstacking, and mainly where to 
> >> place 
> >> the information? 
> >> 
> >> Regards. 
> >> Per 
> >> 
> >> 
> >> 
> > 
> > 
> > -- 
> > Loa Andersson 
> > 
> > Principal Networking Architect 
> > Acreo AB                           phone:  +46 8 632 77 14 
> > Isafjordsgatan 22                  mobile: +46 739 81 21 64 
> > Kista, Sweden                      email:  loa.andersson@acreo.se 
> >                                             loa@pi.se 
> > 
> 
> 
>