[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [T1X1.5] RE: [IP-Optical] concatenation extensions in sonet/s dh
Hi,
it seems I missed a lively discussion due to early knock off work. Instead I had a lively babysitter job at home;-)
Greg, one question about arbitrary concatenation configuration below.
Juergen
> -----Original Message-----
> From: Bernstein, Greg [SMTP:GregB@ciena.com]
> Sent: Thursday, May 17, 2001 8: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.
[Juergen Heiles] How will you tell the framer the starting time slot and the remaining timeslots? Via TMN cnfiguration or GMPLS signaling? Not in-band using some SOH? If you also want to support the STS Group, AUG or partially transparent signal type defined in GMPLS you need the in-band information.
> (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
> >
>
> _______________________________________________
> IP-Optical mailing list
> IP-Optical@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/ip-optical