[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [T1X1.5] RE: [IP-Optical] concatenation extensions in sonet/sdh
- To: "Bernstein, Greg" <GregB@ciena.com>
- Subject: Re: [T1X1.5] RE: [IP-Optical] concatenation extensions in sonet/sdh
- From: Maarten Vissers <mvissers@lucent.com>
- Date: Thu, 17 May 2001 23:14:15 +0200
- Cc: "'Lazer, Monica A, NNAD'" <mlazer@att.com>, "'Zhi-Wei Lin'" <zwlin@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: Thu, 17 May 2001 14:16:28 -0700
- Envelope-to: ccamp-data@psg.com
- Organization: Lucent Technologies
- Original-CC: "'Lazer, Monica A, NNAD'" <mlazer@att.com>, "'Zhi-Wei Lin'" <zwlin@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>
Greg,
I got the impression that there was some misunderstanding with respect
to your 2nd alternative. The "link" you refer to is (if my understanding
is correct) e.g. the connection between two adjacent SONET/SDH (cross
connect) equipments; e.g. a transoceanic connection.
If you do not want to have the need to ever perform bandwidth
defragmentation on this "link", arbitrary concatenation support in the
STM-N/OC-N line ports facing the transoceanic cable is the only
alternative in my opinion. Virtual concatenation is not intended to
support this requirement.
As I wrote in an earlier email this evening (at least in this timezone),
arbitrary concatenation used in this application can be treated similar
to standard contiguous concatenation, if the igress signals are only
standard contiguous concatenated signals and the basic signals (STS1,
VC-4). The transoceanic HOVC/STS link will simply have less "blocking".
In this application there is no need to reflect any arbitrary
concatenation capability in the signalling.
If you however want to have the SONET/SDH network support interworking
of STS-Xa and VC-4-Xa signals for other values of X than the contiguous
concatenated ones, the signalling specifications need to reflect the
arbitrary concatenated capabilities.
But to prevent inconsistency between transport plane and control plane
standards, either both standards need to include arbitrary concatenation
or have it both not included.
For the case the agreement in the transport plane standardisation is to
extend the current SONET/SDH networks with interworking capabilities for
STS-Xa (X=1..N) and VC-4-Xa (X=1..N) signals, the development of a
complete set of STS-Xa and VC-4-Xa requirements can be generated; e.g.
including
- STS-Xa/VC-4-Xa with LCAS to allow hitless capacity adjustment to be
supported,
- addition of multiplex structure identifier in the MSOH/LOH to support
AUG-X/STSG-X,
- payload mapping specifications
- virtual concatenation/arbitrary concatenation interworking functions
- etc.
Regards,
Maarten
"Bernstein, Greg" wrote:
>
> 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
> >
begin:vcard
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:mvissers@lucent.com
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard