[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [T1X1.5] RE: [IP-Optical] concatenation extensions in sonet/sdh
- To: Zhi-Wei Lin <zwlin@lucent.com>
- Subject: Re: [T1X1.5] RE: [IP-Optical] concatenation extensions in sonet/sdh
- From: Dimitri Papadimitriou <dimitri.papadimitriou@alcatel.be>
- Date: Fri, 25 May 2001 21:50:04 +0200
- 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:51:38 -0700
- Envelope-to: ccamp-data@psg.com
- Organization: Alcatel Bell - IPO NSG
Hi Zhi,
Still i don't understand why you want to upgrade all the
boxes when using FACC since it is a Line/MS point-to-point
mechanism ? What's your argument here ? I can use it for
instance for specific LTE-to-LTE "links" within the network.
Do you agree ? And the Eric's explanations provide you the
requested inter-working function. What do you think about ?
- Dimitri
Zhi-Wei Lin wrote:
>
> 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
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