[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Dead of GMPLS ?
Hello Guo-Qiang,
> If one non-SONET/SDH-standard feature could decide the death or the
liveness
of GMPLS, it is the reason I strongly suggest you guys remove this feature
to a separate document to keep GMPLS alive. Up to now, all the arguments we
have
seen are focusing on non-SONET/SDH-standard issue, not on lambda switching
and fiber switching.
No, please read the included e-mails and the e-mails that I was referred to,
they are talking about waveband switching, etc..
We are now speaking about removing waveband switching, about where to put
protection/restoration, and about scanning all the GMPLS drafts to see what
should be removed (see the three e-mails from Maarten).
I am discussing the general principle of moving all non-standard related
features to separate documents. If you want to do it for technology A, to
stay consistent you have to do it also for technology B, C, etc.
Of course you have to remove lambda switching since this is proprietary
(what are the parameters to control, to signal, etc... we don't know yet) -
It is too early in this draft to speak about that before knowing how exactly
the transmission plane will look like. There is no value of having a
standardized control plane to control proprietary networks (as I
understood).
My list of features to remove contains at least:
- SDH/SONET transparency.
- SDH/SONET arbitrary concatenation, flexible concatenation.
- AUG-X, TUG, STS Groups signal types and LSP capabilities.
- All kinds of end-to-end protection/restoration for any layer, except the
IP layer.
- The Waveband switching object and its concept.
- The concept of LSC and FSC layers, i.e. concept of lambda and fiber
switching.
- The label set object (only used for lambda issues).
- LSP encoding type, bandwidth encoding and GPID have to be simplified
accordingly.
- MPLS extensions to control G.709 (since multiplexing, etc is not yet
defined).
- etc...
Something else to add to this list ?
Rgds,
Eric
-----Original Message-----
From: Guo-Qiang Wang [mailto:guoqiang@nortelnetworks.com]
Sent: Monday, May 28, 2001 4:24 PM
To: Mannie, Eric; 'Maarten Vissers'
Cc: 'Yuri Landry'; ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com;
tsg15q11@itu.int; t1x15@t1.org; q16/15; John Drake
Subject: RE: Dead of GMPLS ?
Hi,
If one non-SONET/SDH-standard feature could decide the death or the
liveness
of GMPLS, it is the reason I strongly suggest you guys remove this feature
to a separate document to keep GMPLS alive. Up to now, all the arguments we
have
seen are focusing on non-SONET/SDH-standard issue, not on lambda switching
and fiber switching.
Regards,
G.Q Wang
Technical Manager
Emerging Network Technology
Nortel Networks
Tel: (613)765-4195 (ESN 395-4195)
Fax: (613)768-1140
guoqiang@nortelnetworks.com
-----Original Message-----
From: Mannie, Eric [SMTP:Eric.Mannie@ebone.com]
Sent: Monday, May 28, 2001 9:08 AM
To: 'Maarten Vissers'
Cc: 'Yuri Landry'; ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com;
tsg15q11@itu.int; t1x15@t1.org; q16/15; John Drake
Subject: Dead of GMPLS ?
Hello Maarten,
E-mail 1:
>Let's review the series of GMPLS
^^^^^^
>draft documents to identify the non/pre-standard items and then move
>those items into separate Informational documents.
^ ^^^^^^^^^^^^^^^^^^^^^^^
E-mail 2:
> Yuri started the discussion on wavebands some days ago. Wavebands are
> yet undefined in the transport plane.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
E-mail 3:
>Triggered by Yuri's email, I would like to offer another area for closer
>look: protection switching. The standardised SDH protection switching
>schemes are specified in G.841 with further support in G.783.
>
>When reading the protection switching text some time ago in the GMPLs
>draft I noticed several extensions to be described beyond those in
>G.841.
>
>My request is to review the latest text against G.841/G.783, identify
>the extensions and (as now proposed by several of us) move those
>extensions into a separate Informational document.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The transmission plane for optical networks is not standardized: DWDM
systems are proprietary and don't interoperate.
So I guess that we have to remove the concept of optical switching (lambda
switching, fiber switching, waveband switching) from GMPLS if we want to
follow your model of thinking. We also have to remove any end-to-end
protection/restoration and all non standardized SDH/SONET behaviors (even if
they don't change the standards) as you said.
Everything will become informational, except may be a very small root
specification (that will not be allowed to speak about any optical
switching).
Since the IETF will not have any standard (track) RFC, ITU-T will have to
claim that there is no existing standard and do one...
What is the benefit of moving all the interesting signaling features to
informational RFC's ? If we don't have signaling standards why should we
continue to work on GMPLS ? Why should we spend so much energy of
informational documents that have no standard value ? That will be an easy
marketing message "GMPLS: don't pay attention to it, it is only
informational, you need a standard".
Either GMPLS is dead, or we accept that GMPLS ALLOWS TO CONTROL STANDARDIZED
AND NON STANDARDIZED DATA/TRANSMISSION PLANES.
Regards,
Eric
-----Original Message-----
From: Maarten Vissers [mailto:mvissers@lucent.com]
Sent: Monday, May 28, 2001 11:03 AM
To: John Drake
Cc: 'Yuri Landry'; ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com;
tsg15q11@itu.int; t1x15@t1.org; q16/15
Subject: [IP-Optical] GMPLS: waveband switching
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