[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [T1X1.5] RE: [IP-Optical] concatenation extensions in sonet/sdh
- To: "Lazer, Monica A, NNAD" <mlazer@att.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 19:55:11 +0200
- CC: "'Bernstein, Greg'" <GregB@ciena.com>, "'Zhi-Wei Lin'" <zwlin@lucent.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 11:00:18 -0700
- Envelope-to: ccamp-data@psg.com
- Organization: Alcatel Bell - IPO NSG
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