[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for LSP encoding type
Hello,
Thanks for your comments. This is one very important issue that
you raise here. Let's try to evaluate in a first time the criteria
that we have to take into account here:
- The purpose in the document was to define an LSP EncType per
networking layer or more precisely per group of functional
networking layer (i.e. ODUk and OCh)
- I agree that today SDH/Sonet is a flat LSP EncType space (would
be very difficult for me to say that LOVC and HOVC are separated
since included into a flat LSP EncType space - they don't appear
as "two layers" in GMPLS but as TDM-LSPs a VC-11 as a VC-4-256c
distinction is made through the use of the signal type)
- Today GMPLS-SIG introduce a distinction between non-standard DW
and lambda layer (assumption is made here that the non-standard DW
is a switching layer) without describing the stacking of these
two layers i assume that when using lambda it is only with a framing
procedure (that can be non-standard as well)
- So that i tried to use the previous encoding as an analogy to make
things appearing more "natural" by defining two layers even if for
the common understanding by ITU-T/T1 people a common G.709 is more
appropriate
Am i missing any other criteria ? If you think so please tell me.
Now we take a common LSP EncType, then Signal Types have to be specified
to include ODU1, ODU2, ODU3 and OCh's and the multiplexing mechanism
specified for each Signal Type.
It doesn't seem to change fundamentally the functions if we take
a common LSP EncType. Let me however the needed time to think more
extensively about this proposal and discuss with other people
involved into the document today (others are welcome) to decide
about this. I will keep you informed about these changes.
Regards,
Dimitri.
"Brungard, Deborah A" wrote:
>
> Thanks Dimitri for your response (and draft-gmpls-g709). In the draft,
> though, it refers to 3 code points for DW (1 for g709, 2 for prop.) and 2
> code points for Lambda (1 for g709, 1 for non-OTN). Whereas in the current
> mpls-generalized only 1 for DW and 1 for Lambda is provided. Is the
> intention to assign additional codes later to support these variations?
>
> Separate from the assignment of code points, the use of the term digital
> wrapper (as you note in your draft on gmpls-g709)can have several
> interpretations. The term was used in the introduction of the concept in the
> standards bodies but it was never used in any of the standards (drafts or
> approved). The preference would be to have a separate code point for G709;
> and not confuse it with non-standard "wrappers" or lambdas. The G709 layers
> include the lambda layer (OMS). To align with the other code points (e.g.
> SDH/SONET) which include all the layers, it would be simpler to include all
> the layers for G709 with one code point.
>
> Proposal:
> code point for G.709
> code point for digital wrapper (non-standard)
> code point for lambda (non-standard)
>
> OK?
>
> Regards,
> Deborah
>
> -----Original Message-----
> From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be]
> Sent: Friday, May 25, 2001 12:21 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
> Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for LSP
> encoding type
>
> Hello,
>
> You concerns on G.709 OTN have been addressed in the corresponding
> technology specific document (new version to be published very soon).
>
> In order to make the distinction between the electrical and optical
> hierarchy through the corresponding networking layers (i.e. ODUk and
> OCh), we defined a G.709 DW (the ODUk layer) and G.709 OCh. While
> taking into account non-standard DW and Lambda (i.e. pre-OTN when
> using the ITU/T1 terminology).
>
> Hope this clarifies the situation at least for this specific point.
>
> 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
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