[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [T1X1.5] RE: [IP-Optical] concatenation extensions in sonet/sdh
- To: Dimitri Papadimitriou <dimitri.papadimitriou@alcatel.be>
- Subject: Re: [T1X1.5] RE: [IP-Optical] concatenation extensions in sonet/sdh
- From: Zhi-Wei Lin <zwlin@lucent.com>
- Date: Fri, 25 May 2001 15:31:33 -0400
- CC: "Lazer, Monica A, NNAD" <mlazer@att.com>, "'Bernstein, Greg'" <GregB@ciena.com>, "'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, 25 May 2001 12:32:07 -0700
- Envelope-to: ccamp-data@psg.com
- Organization: Lucent Technologies
Either way, box upgrades are needed.
So, again looking at the differences:
Virtual concat arbitrary concat
* Any combo of timeslot * Any combo of timeslot
* Each timslot can go on * All timeslot must go on
any # of fiber paths the same fiber path
* Only endpoints need * All boxes need to be
to be upgraded upgraded
* For interworking with * Since all boxes need to
contiguous concat, only be upgraded, this is
interworking point need already handled
to be upgraded
* Is already defined in * To support, there must be
standards detailed description of the
process so that transport-level
interworking is possible, not
just signal interworking
* Already has LCAS * LCAS type capability not yet
defined to allow any defined, but is also possible
increase or decrease
to timeslot to allow
growing and shrinking
bandwidth use without
disrupting traffic
Did I miss anything?? I like Rob's suggestion on how to handle the
standard versus "non-standard" features.
Zhi
Dimitri Papadimitriou wrote:
>
> Hi,
>
> Then you will use the S4 function VC-4-Xc to VC-4-Xv defined in
> G.783 (more precisely S4-Xc<->S4-Xv_I VC-4-Xc to VC-4-Xv concatenation
> interworking function - see section 12.5.2) at one edge and the inverse
> function at the other. However, the mechanisms are different in this
> case you access the POH while in the mechanism described by Greg you
> only use a function that converts VC-4-Xc to VC-4-Xa (FACC) you don't
> access the POH.
>
> Hope this help to understand the key difference.
>
> - Dimitri.
>
> "Lazer, Monica A, NNAD" wrote:
> >
> > It is not at all clear to me that those 2 are the only choices. You can do
> > virtual concatenation at the end-points of the valuable link if you want to
> > avoid having end systems do that. This would be the standards-compliant
> > variance of 2. Am I missing something?
> >
> > 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