RE: Frameformat in a l2cs gmpls rnvironment.

[<richard.spencer@bt.com>]

Jaihyung, 

As both you and Adrian thought that I was talking about an Ethernet Control plane, I mustn't have adequately articulated my point. When I mentioned a "data plane for control traffic" below, I was not talking about an Ethernet control plane. I was referring to the transport of GMPLS IP control protocol traffic over a standard 802.1 data plane, using either untagged frames or a common VLAN ID.

Regards,
Richard

> -----Original Message-----
> From: CHO, JAI HYUNG [mailto:jaihyung@etri.re.kr]
> Sent: 23 July 2005 05:39
> To: Spencer,R,Richard,XDE73 R
> Cc: ccamp@ops.ietf.org
> Subject: RE: Frameformat in a l2cs gmpls rnvironment.
> 
> 
>  
> 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 
> > > 
> > 
> > 
> > 
> 
> 
> 
> 
>