[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt
Hi John,
Optical switches based on Wavelength Selective Switch (WSS) technology
requires the wavelength information for switching. This technology is NOT
wavelength agnostic.
| |
| wdm | wdm
|2 |2
--------- ---------
wdm 1| optical |3 wdm 1| optical |3 wdm
--------| switch |------------| switch |---------
| (WSS) | | (WSS) |
--------- ---------
|4 |4
| wdm | wdm
| |
Note that the figure above shows an example of two optical switches interconnect
by a single WDM fiber. In this example, each optical switch can be connect to 4
other optical switches.
As you can see, the optical ports information do not provide enough information
for wavelength switching.
Hope that clarifies the application requirement.
Thanks,
Sidney
> -----Original Message-----
> From: Drake, John E [mailto:John.E.Drake2@boeing.com]
> Sent: Friday, October 28, 2005 5:33 PM
> To: dpapadimitriou@psg.com; Shiba, Sidney
> Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org
> Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt
>
>
> Hi,
>
> Below is the text of an e-mail is sent to the Ethernet/GMPLS mailing
> list.
>
> Upon reflection I am not sure using a real wavelength value makes much
> sense. Between a pair of adjacent nodes, there may be
> multiple pairs of
> switch ports in the same TE link that support a given frequency. If a
> real wavelength value is used, how do the two nodes agree on
> which pair
> of switch ports to use?
>
> Furthermore, the amount of configuration is the same - you
> still need to
> configure the wavelength of each switch port.
>
> Thanks,
>
> John
> ==============================================================
> ==========
> ====
> Adrian,
>
> In the transparent photonic lambda switch case, the labels also have
> only local significance. When an LSP is established, the input ports,
> as identified with local labels, are cross-connected to the output
> ports, as identified with local labels.
>
> There is just extra configuration to identify, using strictly local
> identifiers, the wavelength associated with the all of the switch's
> ports, and an additional CAC requirement that the wavelengths of the
> input and output ports are the same.
>
> Thanks,
>
> John
>
>
> > -----Original Message-----
> > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com]
> > Sent: Thursday, October 27, 2005 10:03 AM
> > To: Shiba, Sidney
> > Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel;
> > richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org
> > Subject: Re: comments on
> draft-shiba-ccamp-gmpls-lambda-labels-00.txt
> >
> > shiba - see inline for some additional hints:
> >
> > >>Shiba, Sidney wrote:
> > >>
> > >>>Adrian, Dimitri,
> > >>>
> > >>>Thanks for reviewing these I-D.
> > >>>
> > >>>Wavelength continuity constraint does require the use of
> semanticful
> > >>>label whether it is spectral or index.
> > >>
> > >>=> see my reply to adrian on this specific point
> > >>
> > >>>I agree with Dimitri that the
> > >>>wavelength indexing requires document updating each time a new
> > >>>spectrum is introduced.
> > >>
> > >>=> indeed and in addition it requires updating the already
> > >>signaled path
> > >>
> > >>>The use of spectral label provides self maintainance, i.e.,
> > >>>no need to update any document and the use of the nominal value
> > >>>provides a common semantic ground.
> > >>
> > >>=> what do you mean by self-maintenance - would you provide a
> > >>bit more detail
> > >
> > > [Sidney]What I've meant here was that it was not necessary to
> > > update any document when new wavelengths are inventoried. In the
> > > case of indexing approach, it would require the
> wavelength indexing
> > > document to be updated with implementation impacts.
> > >
> > > In the case, the nominal value is used, there is no need for
> > > documentation update.
> >
> > ok - what you mean here is that you are going to make use of the
> already
> > defined C-Type 2 - what about the specific encoding of the
> value space
> ?
> >
> > >>=> now i have a more specific question before being light-up
> > >>how do you know the frequency that you can support ?
> > >
> > > [Sidney] Some new technologies integrate optical switch and
> mux/demux
> > > capabilities, which allows the equipment to know the spectrum it
> > supports.
> >
> > indeed - but the question is what does happen if the
> "detected" values
> > (during initialization) do not match the nominal values ? you don't
> > initialize then ?
> >
> > >>if these differ from the nominal values how are you going to deal
> with
> > these
> > >>discrepancies ?
> > >
> > > [Sidney] These new technologies uses the nominal value as
> reference.
> We
> > can say
> > > that a lightpath wavelength is identified by its nominal value. If
> the
> > equipment
> > > is drifting from this nominal value, it is considered as
> a failure.
> >
> > ok - but if the deviation is such you have overlap - how the control
> > plane is going to be able to detect such failure ?
> >
> > >>this said i am not necessarily sure that having to
> maintain the data
> > plane
> > >>specifics as part of the control plane is really helping
> > >>operations (is this method not just duplicating complexity ?)
> > >
> > > [Sidney] The wavelength is WDM specific as much as the SUKLM label
> > encoding
> > > is for SONET. The wavelegth/frequency nominal value is used to
> identify
> > the
> > > facilities to cross-connect.
> >
> > there is an equivalence but there is also a major difference, the
> > structure is invariant independently of the state of the
> network, with
> > spectral value space you may have labels that become unavailable due
> to
> > non-local usage of wavelength in the network
> >
> > hence, there is also no real coupling to the data plane more than
> > knowing the type of interface and some generic capabilities
> >
> > >>>I'm not sure if the draft needs to be updated before the
> > >>>face-to-face meeting or after all comments are collected. Please
> > advise.
> > >>
> > >>=> suggest to keep discussion on - document update can be
> > >>performed at a later stage
> >
> > thanks,
> > - dimitri.
> >
> > >>>>-----Original Message-----
> > >>>>From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org]On
> > >>>>Behalf Of Adrian Farrel
> > >>>>Sent: Thursday, October 27, 2005 4:45 AM
> > >>>>To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be;
> > >>>>ccamp@ops.ietf.org
> > >>>>Subject: Re: comments on
> > >>
> > >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt
> > >>
> > >>>>
> > >>>>Dimitri,
> > >>>>
> > >>>>Thanks for your work reviewing these recent I-Ds. It is
> > >>>>really valuable
> > >>>>and I'd welcome other people doing similar reviews.
> > >>>>
> > >>>>
> > >>>>
> > >>>>>there is a specific point to be clarified in this document:
> > >>>>>
> > >>>>>semanticless vs semanticful label (even here there is a
> distinction
> > >>>>>between spectral vs indexes i.e. using the wavelength index)
> > >>>>>
> > >>>>>domain-wide vs link local significant label
> > >>>>
> > >>>>Without being too picky, I think all labels are semanticful
> > >>>>otherwise, we
> > >>>>would not know what resource they refered to.
> > >>>>
> > >>>>So the point reduces to whether the scope of the semantics
> > >>>>are link-local
> > >>>>or wider.
> > >>>>
> > >>>>
> > >>>>
> > >>>>>so, the comparison from this perspective with TDM labels is
> > >>>>
> > >>>>difficult to
> > >>>>
> > >>>>
> > >>>>>parse, the latter is semanticful but link local
> > >>>>>
> > >>>>>now, i don't specifically see what has changed the late 90's,
> early
> > >>>>>y2k's, to have a change in the wavelength label definition;
> > >>>>
> > >>>>This is the question I would like to get to the bottom of. In
> > >>>>other words:
> > >>>>do we need this function?
> > >>>>
> > >>>>It seems to me that the question being asked is this:
> > >>>>
> > >>>> If I want to compute a path that has some form of wavelength
> > >>>> constraints, what information do I need access to?
> > >>>>
> > >>>>Another question might be:
> > >>>>
> > >>>> If I want to signal a path with wavelength constraints what
> > >>>> information do I need to include in the signaling message?
> > >>>>
> > >>>>
> > >>>>I'd suggest that when we started on GMPLS, we were
> > >>
> > >>enthusiastic about
> > >>
> > >>>>transparent optical networks, but we were not properly
> > >>>>focusing wavelength
> > >>>>constraints because lambda-switching PXCs didn't take off.
> > >>>>Therefore we
> > >>>>didn't examine the requirements for wavelength constraints in
> > >>>>routing and
> > >>>>signaling. The authors of this I-D are claiming new hardware
> > >>>>requirements
> > >>>>for the same function.
> > >>>>
> > >>>>
> > >>>>
> > >>>>>there are
> > >>>>>several solution possible
> > >>>>>
> > >>>>>- absolute values: the freq. of the wavelength: difficult to
> adopt
> > >>>>>because referenced values are nominal and knowing all
> interactions
> > >>>>>between wavelengths this knowledge is at the end of little
> > >>
> > >>practical
> > >>
> > >>>>>usage; (introduces implicit ordering)
> > >>>>>
> > >>>>>- indexed values: the # of the wavelength: it does not
> > >>
> > >>provide for a
> > >>
> > >>>>>future proof label space for inst. in case new frequencies
> > >>>>
> > >>>>are inserted
> > >>>>
> > >>>>
> > >>>>>in the grid (introduces explicit ordering)
> > >>>>>
> > >>>>>- diff. values e.g. freq spacing starting from a reference
> > >>>>
> > >>>>value: pauses
> > >>>>
> > >>>>
> > >>>>>the question of the reference value and does suffer from the
> former
> > >>>>>issue (introduces implicit ordering)
> > >>>>>
> > >>>>>- the solution available today - cumbersome in some
> control plane
> > >>>>>operations (e.g. label set translation) and not easy to
> > >>>>
> > >>>>troubleshoot but
> > >>>>
> > >>>>
> > >>>>>independent of any physical consideration (spectral), scale to
> any
> > >>>>>number of wavelength per fiber, does not introduce any
> > >>
> > >>ordering, the
> > >>
> > >>>>>most flexible (since allowing each system to maintain its
> specific
> > >>>>>control operations) and the less constraining since maintaining
> the
> > >>>>>control plane operations independent of any data plane
> specifics
> > >>>>>
> > >>>>>
> > >>>>
> > >>>><http://www.ietf.org/internet-drafts/draft-shiba-ccamp-gmpls-l
> > >>>
> > >>>ambda-labels
> > >>>-00.txt>
> > >>>
> > >>>.
> > >>>
> > >>
> > >
> > > .
> > >
>