Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]

["Adrian Farrel" <adrian@olddog.co.uk>]

Whoa there!

GMPLS assumes an IP control plane.
I am aware that there is work afoot in other SDOs to assign a dedicated
VLAN tag to specify the control plane traffic. This is not what we are
doing.

As far as I am aware, everyone in the IETF is comfortable with the idea of
using IP packets to carry control plane data through an IP-enabled DCN. In
Ethernet the issue will be whether the control plane is in band (use IP
address and MAC address) or out of band (use distinct DCN).

The use of a separate VLAN ID to signify the control plane is out of scope
for CCAMP.

Thanks,
Adrian

----- Original Message ----- 
From: <richard.spencer@bt.com>
To: <juergen.heiles@siemens.com>; <loa@pi.se>; <per@defero.se>
Cc: <ccamp@ops.ietf.org>
Sent: Friday, July 22, 2005 4:33 PM
Subject: RE: Frameformat in a l2cs gmpls rnvironment.


Juergen,

Before you can use GMPLS to set up VLANs a data plane must first exist to
carry the GMPLS control plane traffic. Yes you can use the standard
Ethernet data plane for this purpose (and in fact must do so for the
solution to be viable), but its not as simple as that. You cannot assume
that just because two GMPLS peers are directly connected that they can
communicate with each other.

To exchange GMPLS control plane packets between a pair of GMPLS peers, the
peers will need to agree to use either untagged control packets or to tag
them with a common VLAN ID. The use of a separate VLAN for GMPLS control
traffic is analogous to using a separate VLAN for management traffic
today. If two switches belong to the same management VLAN then you can use
ICMP ping to verify connectivity between them. However, if one switch has
been put into the wrong management VLAN then the ping will obviously fail.

If you want to use a separate VLAN for GMPLS control plane traffic, then
you either need to (i) define a reserved GMPLS signalling VLAN ID, or (ii)
leave it up to the operator to choose a VLAN ID. If you leave it up to the
operator to decide what VLAN ID to use, then you need to consider what the
implications in the inter-operator case will be, i.e. what VLAN ID range
should be used for control plane traffic and what VLAN ID range should be
used for user plane traffic.

I'm not saying that defining how GMPLS control plane packets are forwarded
in the Ethernet data plane will be an issue, simply that this is something
that must be addressed to develop interoperable solutions.

Regards,
Richard

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> Behalf Of Heiles Juergen
> Sent: 22 July 2005 14:17
> To: Loa Andersson; Pär Mattsson
> Cc: ccamp@ops.ietf.org
> Subject: RE: Frameformat in a l2cs gmpls rnvironment.
>
>
> GMPLS for SONET/SDH has no impact on the SONET/SDH data
> plane. It introduces a control plane for connection setup
> instead of a network management based connection setup. GMPLS
> for Ethernet can work in the same way. Ethernet as such is
> cl, but VLANs are setup and GMPLS can provide a control plane
> for VLAN setup. The Ethernet data plane is not changed and
> MAC address learning and forwarding is still be done within a
> VLAN. So no change to the Ethernet data plane. No GMPLS
> traffic is introduced, it is still VLAN traffic.
> Introducing a dedicated GMPLS label for Ethernet (GMPLS
> traffic) goes beyond GMPLS as a control plane technique.
>
> Regards
>
> Juergen
>
>
>
>
> > -----Original Message-----
> > From: owner-ccamp@ops.ietf.org
> > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Loa Andersson
> > Sent: Friday, July 22, 2005 12:05 PM
> > To: Pär Mattsson
> > 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.
> >
> > /Loa
> >
> > Pär 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
> >
>
>