[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [T1X1.5] RE: [IP-Optical] concatenation extensions in sonet/s dh
- To: "'Krishna Pattabhiraman'" <Krishna@coriolisnet.com>, "'Bernstein, Greg'" <GregB@ciena.com>, "'Lazer, Monica A, NNAD'" <mlazer@att.com>, "'Zhi-Wei Lin'" <zwlin@lucent.com>
- Subject: RE: [T1X1.5] RE: [IP-Optical] concatenation extensions in sonet/s dh
- From: Heiles Juergen <Juergen.Heiles@icn.siemens.de>
- Date: Fri, 18 May 2001 10:57:11 +0200
- Cc: "'Maarten Vissers'" <mvissers@lucent.com>, Anup Tirumala <Anup@jasminenetworks.com>, ccamp@ops.ietf.org, chickoo66@yahoo.com, ip-optical@lists.bell-labs.com, "t1x1.5" <t1x15@t1.org>, q11/15 <tsg15q11@itu.int>
- Delivery-date: Fri, 18 May 2001 01:57:51 -0700
- Envelope-to: ccamp-data@psg.com
Krishna,
your proposal applies to virtual concatenation I assume.
First concatenation of mixed size signals can get tricky due to the non-uniform distribution of the client signal over these signals, specially if the bandwidth factor between these signals is a non-integer number.
As one can use virtual cocnatenation of 7 STS-1-SPE instead of virtual cocnatenation of 2 STS-3c-SPE + 1 STS-1 SPE I don't see an advantage in your proposal.
Juergen
> -----Original Message-----
> From: Krishna Pattabhiraman [SMTP:Krishna@coriolisnet.com]
> Sent: Thursday, May 17, 2001 9:19 PM
> To: 'Bernstein, Greg'; 'Lazer, Monica A, NNAD'; 'Zhi-Wei Lin'
> Cc: 'Maarten Vissers'; Anup Tirumala; ccamp@ops.ietf.org; chickoo66@yahoo.com; ip-optical@lists.bell-labs.com; t1x1.5; q11/15
> Subject: RE: [T1X1.5] RE: [IP-Optical] concatenation extensions in sonet/s dh
>
> Hello Gents,
> I agree that arbitrary concatenation would be the most preferrable, however
> that requires change in the framers at the intermediate nodes along the
> path.
>
> How about this compromise option:
> Currently a SONET VC path has "same-sized" signals making up the
> concatenated streams - i.e.,
> For a HO vc stream VC-N-Xc,
> for all i, s.t., 1 <= i <= X, N is the same.
>
> I was wondering what stops us from making it more generic and allow N to be
> {1 or 3} This will provide much more flexibility with a little modification
> in the H4 header - where for each member stream, we assign a byte (or some
> bits) to identify whether this member stream is a
> STS-1 or STS-3c ....
>
> I see this especially useful when applied in the context of LCAS - where
> increase/decrease in BW could happen in STS-1 or STS-3c chunks? It also will
> be helpful in "path selection". For example, if we needed a STS-3c path
> across the network, and there were no single path available with that
> capacity, it may be possible to distribute it across 3 STS-1s. Of course,
> there is a mismatch in the capacity of a STS-3c and 3 STS-1s. Care has to be
> taken when we use one to replace the other.
>
> Of course, mixing is not possible for SDH, VC3 being in LO and VC4 being in
> HO requires Hi-LO crossconnect functions. I was thinking more about SONET.
>
> Support for mix VC scheme requires changes only at the end nodes of a path.
>
> Krishna
>
>
> -----Original Message-----
> From: Bernstein, Greg [mailto:GregB@ciena.com]
> Sent: Thursday, May 17, 2001 2:52 PM
> To: 'Lazer, Monica A, NNAD'; 'Zhi-Wei Lin'
> Cc: 'Maarten Vissers'; Anup Tirumala; ccamp@ops.ietf.org;
> chickoo66@yahoo.com; ip-optical@lists.bell-labs.com; t1x1.5; q11/15
> Subject: RE: [T1X1.5] RE: [IP-Optical] concatenation extensions in
> sonet/s dh
>
>
> Are we having fun for a Thursday, or what?
> Zhi, had me convinced that I should do a "start up" specializing in virtual
> concatenation for link bandwidth optimization, then Monica asked me about
> overhead use in arbitrary concatenation...
> Here are some more points:
> (1) Arbitrary concatenation (assuming standard sizes) is fairly minor
> tweak of standard contiguous concatenation, i.e., the framer just needs to
> be told the starting time slot (which has the pointer) and the remaining
> (arbitrary) time slots (which have the concatenation indication set). No
> path overhead is used for this process. It is strictly a line level
> operation, e.g., B3 is not recalculated. This is suitable for LTE equipment
> and has nice consequences for avoiding re-grooming.
> (2) Virtual concatenation is a whole new and useful feature that uses
> path level overhead, in particular the H4 byte. Hence the path level BIP B3
> needs to recalculated. This is more a PTE (path termination equipment) kind
> of thing to do. Not something that a typical switch would necessarily want
> to do for compatibility purposes. This was intended for a much more
> sophisticated application, i.e., a path level "bonding" or inverse>
> multiplexing, but it lacks path level transparency if used to avoid
> regrooming.
>
> Hope this puts some more gasoline (petrol) onto the fire.
>
> Greg B.
>
> Dr. Greg M. Bernstein, Senior Scientist, Ciena
> New phone: (510) 573-2237
>
>
> -----Original Message-----
> From: Lazer, Monica A, NNAD [mailto:mlazer@att.com]
> Sent: Thursday, May 17, 2001 11:01 AM
> To: Bernstein, Greg; 'Zhi-Wei Lin'
> Cc: 'Maarten Vissers'; Anup Tirumala;
> ccamp@ops.ietf.org; chickoo66@yahoo.com; ip-optical@lists.bell-labs.com;
> t1x1.5; q11/15
> Subject: RE: [T1X1.5] RE: [IP-Optical] concatenation
> extensions in sonet/s dh
>
> Why wouldn't the 2 boxes in option 2 use virtual
> concatenation instead of
> arbitrary concatenation, though?
>
> Monica A. Lazer
> Advanced Transport Technology and Architecture Planning
>
> 908 234 8462
> mlazer@att.com
>
>
> -----Original Message-----
> From: Bernstein, Greg [mailto:GregB@ciena.com]
> Sent: Thursday, May 17, 2001 12:27 PM
> To: 'Zhi-Wei Lin'
> Cc: 'Maarten Vissers'; Anup Tirumala; ccamp@ops.ietf.org;
> chickoo66@yahoo.com; ip-optical@lists.bell-labs.com; t1x1.5;
> q11/15
> Subject: [T1X1.5] RE: [IP-Optical] concatenation extensions
> in sonet/sdh
>
> To avoid re-grooming either virtual concatenation or
> arbitrary concatenation
> can help, but the implications are quite different.
> Say we have a particularly valuable (expensive) link that we
> can't or don't
> want to re-groom then we have two options:
> (1) Require that ALL end systems that could potentially
> use this link
> convert over to virtual concatenation from standard
> concatenation.
> (2) Or, install boxes at both ends of the link that
> support the
> arbitrary concatenation that we've been discussing.
>
> Which of these seems more realistic and practical?
> Greg B.
> Dr. Greg M. Bernstein, Senior Scientist, Ciena
> New phone: (510) 573-2237
>
>
> -----Original Message-----
> From: Zhi-Wei Lin
> [mailto:zwlin@lucent.com]
> Sent: Thursday, May 17, 2001 8:41 AM
> To: Bernstein, Greg
> Cc: 'Maarten Vissers'; Anup Tirumala;
> ccamp@ops.ietf.org; chickoo66@yahoo.com;
> ip-optical@lists.bell-labs.com;
> t1x1.5; q11/15
> Subject: Re: [IP-Optical]
> concatenation extensions in
> sonet/sdh
>
> Hi,
>
> some observations:
>
> in terms of re-grooming and such, I believe
> both virtual
> concatenation
> and arbitrary concatenation can perform
> this. One method is
> standardized, the other is proprietary.
>
> In terms of routing of the individual
> connections that make
> up the
> concatenated signal, virtual concatenation
> is more flexible
> than
> arbitrary concatenation, since you can put
> each component VC
> in
> different lines, and each component can be
> routed
> differently.
>
> In terms of interworking, yes the SIGNALLING
> can defnititely
> be made to
> interwork. However, the larger issue for
> interworking is
> support by the
> transport equipment themselves. Thus
> interworking involves
> TWO parts:
> signaling interworking and transport
> interworking. Having
> one without
> the other doesn't really help...
>
> Thus, in terms of solving real problems,
> either virtual or
> arbitrary can
> accomplish that, but IMO, virtual seems more
> flexible...and
> standardized...
>
> In terms of standards as fostering
> interoperability and
> stifling of
> innovation, in principle yes I agree. And
> therefore if
> > arbitrary
> concatenation should be standardized, it
> should be
> standardized in the
> correct standards body. As Maarten
> mentioned, the relevant
> standards
> bodies discussed arbitrary concatenation
> years ago, and
> decided
> (hopefully based on their expert technical
> opinion - I
> wasn't involved)
> not to include arbitrary but instead to
> include virtual.
> IMO, there must
> be good reasons, and from what I can tell, I
> see virtual as
> been more
> flexible so that is a pretty good
> reason...we at IETF, being
> protocol
> experts (and budding transport experts?)
> should not try to
> second-guess
> the decisions without fully understanding
> the
> ramifications...
>
> As for stifling innovation, anytime you
> standardize anything
> there is
> always some factor of development that gets
> fixed (is this
> something
> that should not be said in a public forum???
> -- sorry!!).
> Therefore
> there is always a tradeoff between
> innovation and
> standardization. I
> think the job of standards bodies is to try
> to balance these
> two factors
> such that the industry in general can live
> with the result
> without
> unduly burdening...
>
> agree?
>
> Zhi
>
>
>
> "Bernstein, Greg" wrote:
> >
> > A couple more points.
> > (1) GMPLS works well with arbitrary
> concatenations
> need to specify the
> > time slots since it provides a signaling
> protocol that can
> do just that,
> > i.e., GMPLS actually enables this feature
> to interoperate.
> > (2) Arbitrary concatenation offers a
> solution to a
> real problem, i.e.,
> > eliminates the need for re-grooming on
> lines that support
> it. For those who
> > have invested non-trivial amounts of money
> in transoceanic
> links this can be
> > a significant savings.
> > (3) The goal is interoperability and
> to solve real
> problems. We've got
> > a real problem and with a minor edit to
> the GMPLS SONET
> specification we can
> > have an interoperable method for solving
> it.
> >
> > To be precise in the definition of
> arbitrary
> concatenation:
> > As a concatenated signal within a single
> SONET Line (SDH
> MS), with
> > potentially arbitrary timeslots used for
> its components.
> >
> > The current main application is: avoiding
> the need for
> service impacting
> > re-grooming. Note that this applies to
> standard sized
> signals and is a per
> > link property.
> >
> > Other applications do exist and are
> somewhat competitive
> with non-LCAS
> > virtual concatenation since the
> implementation of
> arbitrary concatenation
> > for odd sized signals is simpler than that
> of virtual
> concatenation. Once
> > "odd" sized signals are used an entire
> path through the
> network must exist
> > that supports them.
> >
> > Folks I thought the role of standards
> organizations was to
> foster
> > interoperability that enables the industry
> to move forward
> rather than as a
> > means to stifle innovation. I think it is
> better for the>
> > marketplace to
> > decide which features are desirable.
> >
> > Greg B.
> >
> > Dr. Greg M. Bernstein, Senior
> Scientist, Ciena
> > New phone: (510) 573-2237
> >