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

Re: Protection switching in GMPLS ==> supporting G.841?

To: Maarten Vissers <mvissers@lucent.com>
Subject: Re: Protection switching in GMPLS ==> supporting G.841?
From: Dimitri Papadimitriou <dimitri.papadimitriou@alcatel.be>
Date: Mon, 28 May 2001 11:01:49 +0200
CC: Yuri Landry <yurilandry@hotmail.com>, ccamp@ops.ietf.org, ip-optical@lists.bell-labs.com, tsg15q9@itu.int, t1x15@t1.org
Delivery-date: Mon, 28 May 2001 02:05:27 -0700
Envelope-to: ccamp-data@psg.com
Organization: Alcatel Bell - IPO NSG

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

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: Protection switching in GMPLS ==> supporting G.841?
Next by Date: GMPLS: waveband switching
Prev by thread: Protection switching in GMPLS ==> supporting G.841?
Next by thread: GMPLS last call
Index(es):
- Date
- Thread