[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Frameformat in a l2cs gmpls rnvironment.



Hi Richard,
            actually the usage of a specific VLAN tag for the control plane
seems to me a good idea.

It is a fast and simple way to distinguish data plane traffic from control
plane traffic.

Regards

Diego



<richard.spencer@bt.com>@ops.ietf.org on 25/07/2005 11.54.36

Sent by:    owner-ccamp@ops.ietf.org


To:    <jaihyung@etri.re.kr>
cc:    <ccamp@ops.ietf.org>

Subject:    RE: Frameformat in a l2cs gmpls rnvironment.

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