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

Re: [IP-Optical] Re: Protection switching in GMPLS ==> supporting G.841?

To: Dimitri Papadimitriou <dimitri.papadimitriou@alcatel.be>
Subject: Re: [IP-Optical] Re: Protection switching in GMPLS ==> supporting G.841?
From: Stephen Trowbridge <sjtrowbridge@lucent.com>
Date: Tue, 29 May 2001 09:11:28 -0600
CC: Maarten Vissers <mvissers@lucent.com>, Yuri Landry <yurilandry@hotmail.com>, ccamp@ops.ietf.org, ip-optical@lists.bell-labs.com, tsg15q9@itu.int, t1x15@t1.org
Delivery-date: Tue, 29 May 2001 08:12:02 -0700
Envelope-to: ccamp-data@psg.com
Organization: Lucent Technologies

Dimitri,
ITU-T has an ongoing work program as well - it is not just a
set of static documents that never change.
In terms of protection, the current document, as you observe,
was developed to support SDH. However, as we define additional
layer technologies, it is clear that we have no need to reinvent
the wheel. The plans for G.841 are to split it into a series of
Recommendations, first by seperating out the generic aspects of
various protection architectures (e.g., SNC, shared protection
rings, etc.), and then developing a series of much smaller
documents describing the application of particular protection
architectures to different transport layer technologies.
I don't think this work needs to be complete and final for us
to be able to discuss how the protection architectures from G.841
apply to other layer technologies.
Regards,
Steve Trowbridge
Chairman, ITU-T WP 3/15

Dimitri Papadimitriou wrote:
> 
> Hello Maarten,
> 
> To which part of the document do yo refer here ? I suppose it
> is the section 7 of the GMPLS Signalling. G.841 is dedicated
> to "TYPES AND CHARACTERISTICS OF SDH NETWORK PROTECTION
> ARCHITECTURES" so it is a technology dependent document.
> 
> The main difference comes from the "objective" of these
> protection: in section 7 you describe the type of link
> selected in order to provide LSP link protection. G.841
> covers as indicated in the scope of the document:
> 
> "Protection schemes are classified as:
> - SDH trail protection (at the section or path layer);
> - SDH subnetwork connection protection (with inherent monitoring,
>   non-intrusive monitoring, and sub-layer monitoring)."
> 
> So this this document described the protection schemes while
> the scope of the GMPLS-SIG is only to determine the signalling
> extensions in order to provision link-protected LSP. If you
> have some doubts we could probably review this section together.
> What do you think about ?
> 
> - Dimitri.
> 
> Maarten Vissers wrote:
> >
> > 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

Prev by Date: Re: GMPLS Last Calls
Next by Date: RE: [IP-Optical] Re: Proposed text for the concatenation
Prev by thread: RE: [IP-Optical] RE: [T1X1.5] RE: Proposed text for the concatenation
Next by thread: RE: [IP-Optical] RE: GMPLS Last Calls
Index(es):
- Date
- Thread