[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [IP-Optical] GMPLS: waveband switching

To: Maarten Vissers <mvissers@lucent.com>
Subject: Re: [IP-Optical] GMPLS: waveband switching
From: Dimitri Papadimitriou <dimitri.papadimitriou@alcatel.be>
Date: Mon, 28 May 2001 11:31:52 +0200
CC: John Drake <jdrake@calient.net>, "'Yuri Landry'" <yurilandry@hotmail.com>, ccamp@ops.ietf.org, ip-optical@lists.bell-labs.com, tsg15q11@itu.int, t1x15@t1.org, q16/15 <tsg15q16@itu.int>
Delivery-date: Mon, 28 May 2001 02:33:44 -0700
Envelope-to: ccamp-data@psg.com
Organization: Alcatel Bell - IPO NSG

Hi Maarten,

I think the previous e-mail from John combined with the proposal 
made last week in order to join our efforts in order to improve
the document on G.709 solve the problem. 

Today the "waveband switching" (and i agree with you it is not a 
new networking layer) has been proposed in the last version of this
document. Please take a look on what has been proposed there and
tell me if it aligned with your expectations.

Regards,
Dimitri. 

Maarten Vissers wrote:
> 
> 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:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:dimitri.papadimitriou@alcatel.be
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

Prev by Date: RE: [IP-Optical] Re: Proposed text for the concatenation
Next by Date: RE: [T1X1.5] RE: Proposed text for the concatenation
Prev by thread: RE: Dead of GMPLS ?
Next by thread: GMPLS: waveband switching
Index(es):
- Date
- Thread