[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatena tion
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