[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
> >
>
>