[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Protection switching in GMPLS ==> supporting G.841?
All,
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.
Regards,
Maarten
Yuri Landry wrote:
>
> 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
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