GMPLS: waveband switching

[Maarten Vissers <mvissers@lucent.com>]

John,

Yuri started the discussion on wavebands some days ago. Wavebands are
yet undefined in the transport plane. Looking into it a few days ago, I
tried to provide a definition of waveband and got immediately corrected
by an optical expert, resulting in an adapted definition of waveband
(see email below).

At this point in time, a waveband seems to be a group of Optical Channel
(OCh) signals. It represents a partition, not a new layer network. As
such a waveband should be represented as a "group of OCh signals" within
the OCh layer network.

Regards,

Maarten



Maarten Vissers wrote:
> 
> Manoj, Yuri,
> 
> I received a message that my definition of waveband is too restricted.
> 
> A waveband should be an optical multiplex, administered as a single
> bundle, not necessary contiguous in frequency slot.
> 
>         E.g. there may be good technical reasons to consider a
>         'waveband' created at an OADM formed by taking every 2nd
>         wavelength in a 50GHz-spaced transmission band.
> 
> In first instance the above definition may not be considered this as a
> "band"; it
> looks more like a "gapped-band" :-). Nevertheless, due to technical
> reasons we should consider a waveband as just another name for a
> particular group of wavelengths, which may best be viewed as a group of
> identified/listed wavelengths.
> 
> Regards,
> 
> Maarten
> 
> Maarten Vissers wrote:
> >
> > Manoj, Yuri,
> >
> > In my current understanding, a waveband is a group of OCh (optical
> > channel) signals located in a contiguous set of tributary (i.e.
> > frequency) slots.
> >
> > A waveband is therefore related to partitioning, rather than a layering.
> > A waveband shouldn't have an LSP encoding type itself, but instead be
> > part of the OCh layer network. E.g. a specific RGT (requested groupting
> > type) of "contiguous waveband" can be defined for this purpose with the
> > RNC (requested number of components) indicating the size of the
> > waveband.
> >
> > The above is simply a first shot; in general the issue can be more
> > complex due to the fact that the frequency slot for a 2G5, a 10G and a
> > 40G signal may have differnet bandwidths: e.g. 2G5 freq. slot width e.g.
> > 25 GHz, 10G freq. slot width e.g. 50 GHz and 40G freq. slot width e.g.
> > 100 GHz. For the case of (future?) mixed rate WDM signals with bit rate
> > optimized freq. slot widths, a waveband might need a start-of-waveband
> > and end-of-waveband (SOW-EOW) indication, instead of RNC.
> >
> > Regards,
> >
> > Maarten
> >
> > Yuri Landry wrote:
> > >
> > > Mano,
> > >
> > > >            Can someone tell me the message structure of Label Request and
> > > >Label Mapping in GMPLS ?
> > > >I am confused about the presence of LightPath Id in O-UNI messages and LSP
> > > >Id in GMPLS messages ? Is there one-to-one mapping between these Ids or Is
> > > >it like that both lightPath Id and LSP Id will be carried in GMPLS messages
> > > >? LSP Id is not present in O-UNI messages. Can one LightPath Id be mapped
> > > >to
> > > >multiple LSP Ids or vice versa ?
> > >
> > > I think you mean Connection ID and LSP ID. A connection ID is an ID for
> > > network connection, which may consist many LSPs. For example, the virtual
> > > concatenation case.
> > >
> > > A LSP may tunnel through multiple pre-established connections.
> > >
> > > >Also, for waveband switching, the genralized label has the format
> > > >(wavebandId - start label - end label).
> > > >When the label request message is received on incoming interface, how to
> > > >identify that the waveband label is requested ?
> > > >Is it the LSP encoding type or some other parameter in label request
> > > >message
> > > >? If it is the Lambda encoding type then how to identify that whether a
> > > >lambda or waveband label is requested ?
> > > >
> > > >Also, it is mentioned that wavebandId (32 bits) is selected by the sender
> > > >and reused in all the subsequent messages. What all subsequent
> > > >messages is it mentioning to ?
> > > >
> > > >Can wavebandId be present in Label Withdraw/Release messages ?
> > > >
> > > >I am not able to workout the message structures for GMPLS.
> > > >
> > >
> > > To me waveband label defined in GMPLS drafts is a joke. The reason to have
> > > the waveband label is that someone claimed that the waveband's order might
> > > flip when going through a switch. My suggestion is don't take it seriously.
> > >
> > > >I am not sure how these drafts are at last call. Atleast it should mention
> > > >the message structures of various messages.
> > > >
> > >
> > > Agree.
> > >
> > > Regards,
> > >
> > > Yuri
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at http://explorer.msn.com












John Drake wrote:
> 
> Yuri,
> 
> I've attached a private note I sent to Dimitri regarding waveband switching.
> It was originally put in at the suggestion of NorTel.  For both waveband
> switching and fiber switching, you are dealing with a situation in which you
> are using a standardized control plane to establish a multi-hop LSP with
> proprietary encoding of data.  As I mentioned, this would be accomplished
> using link coloring.
> 
> Personally, I have no problem removing either waveband switching or fiber
> switching, but we know have to accomodate them wrt the control plane, and I
> seriously doubt that there will ever be a completely non-proprietary of
> encoding the data for these types of LSPs.
> 
> Note that I am using 'proprietary' in the exclusive sense.
> 
> Thanks,
> 
> John
> -----Original Message-----
> From: John Drake
> Sent: Wednesday, March 28, 2001 11:15 AM
> To: 'Papadimitriou Dimitri'; John Drake; Lou Berger
> Cc: 'Mannie, Eric'; 'Bala Rajagopalan'; fubar@labn.net
> Subject: RE: Waveband Switching (was Re: GMPLS signaling)
> 
> Dimitri.
> 
> It's probably better to think of waveband switching as a special form of
> fiber switching; i.e., it has nothing to do with the SONET/SDH stuff at all.
> Suppose the trunk side of a DWDM system is attached to a PXC.  In the fiber
> switching case, the fiber between the DWDM system and a port on the PXC
> contains the entire set of lambdas, while in the waveband switching case
> there is a set of fibers between the DWDM system and a set of ports on the
> PXC, each of which contains a separate waveband.
> 
> In either case, the encoding of the signal on the fibers is completely
> proprietary, and it's the job of routing to ensure that a correct path
> through the network is obtained, such that the proprietary encoding is
> maintained end-end.  This would probably be done through link coloring, so
> that you only route across links that support NorTel waveband switching or
> Tellabs waveband switching.
> 
> So I think the signalling stuff is fine.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Yuri Landry [mailto:yurilandry@hotmail.com]
> Sent: Friday, May 25, 2001 7:02 AM
> To: ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com;
> tsg15q11@itu.int; t1x15@t1.org
> Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> concatena tion
> 
> Hello All,
> 
> So far, our discussions are focusing on the SONET/SDH draft. I'd like to
> re-direct your attention to other drafts. Rob's suggestion should apply to
> other drafts too.
> 
> One example, is the waveband switching and waveband label a standard or
> proprietary? Can author explain to me what exactly they means? How do they
> work? Any other standard reference? There are questions about it but no
> answer yet.
> 
> Regards,
> 
> Yuri.
> 
> >From: "Lazer, Monica A, NNAD" <mlazer@att.com>
> >To: "'Rob Coltun'" <rcoltun@redback.com>, ccamp@ops.ietf.org,
> >ip-optical@lists.bell-labs.com, q11/15 <tsg15q11@itu.int>,   "t1x1.5"
> ><t1x15@t1.org>
> >Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatena
> >tion
> >Date: Thu, 24 May 2001 18:11:36 -0400
> >
> >
> >Rob, You proposal makes a lot of sense. Having the signaling standard
> >support proprietary transport may jeopardize interoperability. The issue is
> >not about GMPLS supporting non-standard rates, the issue is about putting
> >in
> >formal and very specific support for a proprietary transport solution in a
> >standard document for signaling without taking the transport portion to a
> >standards body. Having formal signaling support for a proprietary
> >concatenation may cause interoperability issues when other vendors have a
> >different solution to the concatenation and while the signaling would
> >indicate the concatenation, the actual transport may not work.   On the
> >other hand we recognize that there may be a need for some interim support
> >for proprietary solutions.
> >
> >
> >Eric,
> >Below I have some additional specific comments for the document GMPLS
> >Extensions for SONET and SDH Control
> >
> >
> >CCT field (3 bits)
> >Since arbitrary contiguous concatenation is not a standard concatenation,
> >it
> >falls within the vendor proprietary set of solutions.
> >
> >So the CCT bits may be used as follows:
> >000    No contiguous concatenation requested
> >001    Standard contiguous concatenation
> >others Vendor specific contiguous concatenation
> >
> >Alternatively, a better solution is to use only 2 bits for this field and
> >use one bit to show whether contiguous concatenation is requested and the
> >second bit to show whether it is standard or non-standard contiguous
> >concatenation.
> >
> >
> >NCC field (16 bits)
> >This information is not sufficient.
> >NCC needs better description than a zero or non-zero number.
> >
> >SDH and SONET Labels
> >
> >Text in this section (Section 3, paragraphs 5 and 6) indicates that the
> >GMPLS proposal limits virtual concatenation to remain within a single
> >(component) link. If I understand this correctly, it means that GMPLS will
> >not allow inverse multiplexing (virtual concatenation) in the transport
> >plane if it requires different component links. This is too limiting.
> >
> >Annex 1 (sent out by Eric Mannie on 5/22)
> >Defines another type of concatenation - Flexible arbitrary contiguous
> >concatenation without describing precisely how it affects the OH bits. This
> >means that it will be impossible to have this type of concatenation in a
> >multi vendor environment based only on the GMPLS signaling. If the
> >transport
> >plane is proprietary, having the option in the signaling message will not
> >fix the interoperability problem between two different vendors supporting
> >their proprietary versions of arbitrary concatenation.
> >
> >Annex 2 (sent out by Eric Mannie on 5/22)
> >Arbitrary contiguous concatenation needs definition work for
> >interoperability.
> >Flexible arbitrary contiguous concatenation may be available today to
> >support contiguous signals, but it is not defined in the current standards.
> >Clear agreements on OH usage are needed between supporting vendors.
> >Maintenance and tracking of the signal needs to be well understood.
> >
> >
> >
> >Monica A. Lazer
> >Advanced Transport Technology and Architecture Planning
> >
> >908 234 8462
> >mlazer@att.com
> >
> >
> >-----Original Message-----
> >From: Rob Coltun [mailto:rcoltun@redback.com]
> >Sent: Thursday, May 24, 2001 7:24 PM
> >To: ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com; q11/15; t1x1.5
> >Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> >concatenation
> >
> >All,
> >     despite the heated arguments I think the discussion is important to
> >have.
> >
> >I suggest that instead of  tagging non/pre-standard items in the current
> >drafts
> >that they be put into a separate Informational document  - this is the
> >cleanest thing to do.
> >We (the IETF) do have a tradition of publishing company proprietary
> >protocols
> >but not as standard track documents.
> >
> >thanks,
> >---rob
> >
> >
> >
> >_______________________________________________
> >IP-Optical mailing list
> >IP-Optical@lists.bell-labs.com
> >http://lists.bell-labs.com/mailman/listinfo/ip-optical
> >
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
> 
> _______________________________________________
> IP-Optical mailing list
> IP-Optical@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/ip-optical
begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:mvissers@lucent.com
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard