Hi,
It is always refreshing how engineers jump
straight to a discussion of the solution :-)
Perhaps we can assume that the framework draft
is a good representation of the problem space, and that we are ready to start
discussing the solutions.
One (perhaps the only?) significant question to
answer is how the frames will be labelled. This question is one we must come
to as soon as we are confident that the requirements need to be addressed at
all.
As has been pointed out, there are several
possibilities and to pick from these we need to understand:
1. Do we need to support explicit label
stacking?
Note that this is not supported in
TDM, LSC or FSC.
2. Do we need to be able to control (perhaps
through an
external signaling
controller) existing hardware and
install LSPs through existing
networks?
3. Do we need to support existing function
simultaneous to
the support of GMPLS L2
LSPs?
I think that from a chair's perspective I can
give some limited guidance.
A. These questions must be raised and answered
in the framework I-D
B. The answer to question 3 is "yes". This
means that the use of labels
must not significantly deplete any
namespace used to support other
function.
C. CCAMP is chartered to look at the control of
transport networks. This
includes Metro, but I am
unsure about Campus. It does not cover
signaling to the
desktop.
Thanks,
Adrian
----- Original Message -----
Sent: Friday, July 22, 2005 11:41
AM
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
> >
> > 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
> >
>
>
>
>