RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for LSP encoding type

[Heiles Juergen <Juergen.Heiles@icn.siemens.de>]

Dimitri,

removal of the Sonet/SDH version was the out come of the Paris Sonet/SDH editing session. But it didn't make it into the main document.
My proposal was also to use the same signal type values for identical Sonet/SDH signals as it would make interworking easier. This was rejected with the argument of the proxy function that is needed in any case.

Regards

Juergen

> -----Original Message-----
> From:	Dimitri Papadimitriou [SMTP:dimitri.papadimitriou@alcatel.be]
> Sent:	Saturday, May 26, 2001 12:11 PM
> To:	Brungard, Deborah A
> Cc:	'John Drake'; 'Yuri Landry'; ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com; tsg15q11@itu.int; t1x15@t1.org; Eric Mannie
> Subject:	Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for LSP encoding type
> 
> Hi all,
> 
> Back to question on the LSP EncType concerning SDH/Sonet, when 
> proposed it was to enable specific inter-working between capabilities
> provided in v2000 and not in v1996 of SDH (for instance the in-band 
> FEC P1/Q1 and REI M0/M1) this distinction was proposed mainly for 
> on-demand Transparency service usage (introduced in the SDH/Sonet 
> GMPLS document). I guess you agree with me that v2000 include a lot 
> of differences compared to the v1996.
> 
> Now since the SDH/Sonet extensions draft does not make this distinction 
> anymore in response to lighter Transparency services, I suggest to keep
> only two LSPEncType codepoints one for SDH and one for Sonet making the
> assumption that versions are backward compatible as it should be the 
> case. Do you agree with the proposed change ? I propose this otherwise
> changes into the SDH/Sonet draft won't be minor anymore.
> 
> Your question on inter-working between Sonet and SDH is valid, the 
> proposal up to now is to use a "proxy" function making appearing the
> connection for the SDH side as an SDH LSP and as an Sonet connection
> for the other side by enabling the corresponding "modification" at the 
> entity performing the interworking function. Since this is not
> completely
> defined into the document i propose to indicate as well that more
> details will be provided in next releases or even in a specific
> document concerning this issue.
> 
> What do you think about ?
> 
> Regards.
> - Dimitri.
> 
> "Brungard, Deborah A" wrote:
> > 
> > All,
> > 
> > (I've changed the subject field to signal a "switch" of topics - and kept
> > q11 and t1x15 lists as the mail is related to their subject areas)
> > 
> > I also had some questions/comments on the LSP encoding types- section 3.1.1-
> > 
> > can someone explain why different values are used for different versions of
> > T1.105 and G.707? The later versions contain updates to include OC-768 and
> > new functions e.g. FEC, J0 support of 16-byte in addition to previous 1-byte
> > version, etc. One can not assume equipment supports all functions described
> > in any of the versions; one can only assume if the function is supported, it
> > is supported as defined. Example, equipment "supporting" T1.105 '95 may not
> > support J0 or support both 1-byte and 16-byte J0. Also, G.707 includes
> > "SONET" functionality. One code seems sufficient for SDH/SONET. Any
> > "supporting" details/references can be addressed in the technology specific
> > documents.
> > 
> > Similar comment for PDH - E1 services are supported in the U.S. and 45M are
> > supported in Europe. One code can be used: PDH.
> > 
> > For the digital wrapper code, reference is OTN(G.709). OTN is not just the
> > digital wrapper - G709 defines a hierarchy: optical and electrical. Reading
> > the attached mail, on waveband switching and assigning Lambda as an LSP
> > type, LSPs need to distinguish Lambda LSPs of "undefined" structure and
> > Lambda LSPs of G.709 signals. G.709 (OTN) defines wavelength connection
> > functionality for OTN signals - it is different from today's SONET/metro WDM
> > equipment(referred to as pre-OTN). G.709 Lambdas (OCh) can be covered in the> 
> > OTN technology specific document.
> > 
> > Probably should include LSP ranges for future items (and proprietary?).
> > 
> > Suggest the following as LSP types: packet, ethernet, PDH, SDH (inc. SONET),
> > OTN (G.709), Lambda (pre-OTN), Fiber, xxx (future).
> > 
> > The G-PID has discrete values for DS1, DS3 whereas only one value for all
> > STSs - a reason? Same for bandwidth encoding - one value for STS-1, no
> > others supported, and no SDH VC-4. The G-PID seems to be redundant info with
> > the technology specific parameters - is there a reason to support this in
> > the generalized label request?
> > 
> > Regards,
> > Deborah Brungard
> > AT&T
> > 
> > -----Original Message-----
> > From: John Drake [mailto:jdrake@calient.net]
> > Sent: Friday, May 25, 2001 10:25 AM
> > To: 'Yuri Landry'; 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
> > 
> > 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 << File: Card for Dimitri Papadimitriou >>