[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [IP-Optical] concatenation extensions in sonet/sdh
Hi Paul,
I'll have to disagree. I thought the discussion thus far have been what
is arbitrary and what is virtual, its capabilities, how to handle
support, what actions need to be taken to allow support.
I don't see that as hurling dung in Greg's direction. If this were the
case or if some folks interpret it that way, then let me be the first to
apologize to Greg (sorry!). There was no intention in my part to hurl
dung (I think that's disgusting, yuk...I'll have to go wash my hands
just thinking about it ;-)
As for transparency and the rest, right. So as you said, the question we
should ask ourselves is:
1) Should we add extensions to GMPLS for capabilities not standardized
2) Should we pre-empt standards and add capabilities that are not yet
standardized
3) If 2) is yes, should we add capabilities that we "think" will be
standardized. What about capabilities where we have no opinion or we
think will not be standardized (folks, bring out your crystal ball!)
4) Should we stick strictly with standards-compliant capabilities and
include extensions to allow ease of extending the signalling mechanism
(Deborah's point). Add these in the future once it is standardized.
OK. Now let's hurl some dung in some other direction other than Greg!
;-)
Zhi
Paul Bonenfant wrote:
>
> We seem to be hurling generous amounts of dung
> in Greg's general direction for proposing that
> GMPLS handle "non-standard" SONET/SDH features.
> This begs a question (well, at least one)...
>
> Mind you, I've not been _actively_ engaged in
> the T1X1 & ITU discussions of late, but where,
> for example, is the the notion of "transparency"
> defined in T1X1/ITU SONET/SDH specs, c.f. the
> discussion of various transparency flags in
> section 2.1 of draft-ietf-ccamp-gmpls-sonet-sdh-00?
>
> By the same arguments, should this too be removed
> from the spec and left to "proprietary" extensions,
> until such time as the experts have validated its
> applicability (as opposed to, let's say, the market)?
>
> Paul
>
> -----Original Message-----
> From: Bernstein, Greg [mailto:GregB@ciena.com]
> Sent: Thursday, May 17, 2001 5:58 PM
> To: 'Steve West'; 'Stephen Trowbridge'
> Cc: 'Zhi-Wei Lin'; '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
>
> Why don't we just remove the contiguous arbitrary concatenation from the
> GMPLS specification since it's not standard and doesn't offer any value
> that I can see. Anything else could be left for peoples proprietary
> extensions:-)
>
> Greg B.
> Dr. Greg M. Bernstein, Senior Scientist, Ciena
> New phone: (510) 573-2237
>
> -----Original Message-----
> From: Steve West [mailto:Swest@turinnetworks.com]
> Sent: Thursday, May 17, 2001 12:52 PM
> To: 'Stephen Trowbridge'; Bernstein, Greg
> Cc: 'Zhi-Wei Lin'; '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
>
> Greg:
>
> It seems that you have a scheme that allows better
> utilization of a link by
> including a new type of concatenation hardware, just at the
> ends of that
> link. If I understand, the concatenation method allows you
> to remove the
> requirement for "contiguous" sts1/columns in the SONET/SDH
> payload, by
> "leap-frogging" over columns that are in-use and thus
> "in-the-way" ?
>
> If my read is right, why not also present this "leap-frog"
> arbitrary
> concatenation scheme to the relevent standards authorities
> (ANSI/ETSI/ITU),
> so that the experts there can validate its applicability?
>
> Steve West
>
> -----Original Message-----
> From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com]
> Sent: Thursday, May 17, 2001 11:39 AM
> To: Bernstein, Greg
> Cc: 'Zhi-Wei Lin'; '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
>
> There is no intent in any of the standardization bodies to
> stifle
> innovation. Standards are contribution driven, and what you
> find
> in the documents as written are the product of those
> contributions.
>
> If the desire is to extend current SONET/SDH with an
> arbitrary
> concatenation feature, there is no problem to contribute to
> T1X1
> and/or ITU-T to propose this extension. This is the correct
> way to
> approach it. The INCORRECT way is to confuse the market by
> producing
> an IETF version of SONET/SDH specs that is different from
> T1X1/ITU-T.
>
> Let me add some background on how we ended up with the
> current
> situation recommending virtual concatenation in SONET/SDH:
>
> 1. Contiguous or Arbitrary concatenation requires
> implementation
> of the concatenation method at every NE along the chosen
> path
> through the network to provide a service. At the time we
> began
> these discussions, we had the problem that ATM wanted to use
> VC-4-4c (STS-12c), but there were still a lot of OC-3/STM-1
> links in the network and NEs that didn't support trails
> bigger than VC-4 (STS-3c). By now, of course, VC-4-4c
> (STS-12c)
> and even VC-4-16c (STS-48c) are becoming pretty ubiquitous,
> but as has been observed in previous emails, it will be a
> long time before you replace all of the 2.5G links in the
> network, so contiguous/arbitrary concatenation to greater
> than VC-4-16c/STS-48c is still a problem for some time to
> come. The endpoints in a network always seem to evolve ahead
> of and faster than links and equipment in the core network
> can be replaced, so it was important to define a
> concatenation
> method that could be implemented only by the endpoints.
>
> 2. Contiguous/arbitrary concatenation is not as elgant for
> lower order paths as for higher order paths. We saw in
> a few equipments the VC-2-5c mapping to put 4 x 34 Mbps
> into an STM-1, but most equipment does not provide the
> ability to concatenate lower order paths. For certain
> payloads, lower order paths fit better, e.g., 5 x VC-12
> to carry 10Mb Ethernet.
>
> 3. Different payloads to not fit ideally into "standard"
> multiples found in contiguous concatenation (4, 16, 64,
> 256 VC-4 or 3, 12, 48, 192, 768 STS-1). 10 Mb Ethernet
> fits into 5 x VC-12. 1Gb Ethernet fits into 7 x VC-4, etc.
>
> 4. As paths are set up or taken down in a network, there is
> a tendency for capacity to become fragmented. Contiguous/
> arbitrary concatenation cannot always take advantage of
> free timeslots along a span if they are not adjacent on
> the same fiber or if they are on different fibers.
>
> 5. LCAS was easier to envision in a virtual concatenation
> environment. Many of the new services are not inherently
> constant bit rate, and it can be useful to dynamically
> add or remove components of the bundle to adjust link
> capacity. It is also useful to be able to handle failures
> of individual components of the concatenated trail by
> just reducing the capacity rather than by having to
> protection switch the entire path.
>
> Virtual concatenation was designed to solve all of the above
> problems. Arbitrary concatenation is another way to solve
> problem (3) above, but it doesn't solve the others. Given
> that virtual concatenation is standardized to solve all
> of the problems, it reduces the pressure to implement
> arbitrary concatenation throughout the network to solve
> only problem (3).
>
> If problem (3) is the only one you are trying to solve,
> arbitrary concatenation has the advantage of not requiring
> so much buffer space at the endpoints to accomodate
> differential delay. But with trends in memory costs, this
> is not so much of an issue, and this needs to be traded
> off against the need to provide support for the contiguous/
> arbitrary rate and all associated protection mechanisms at
> EVERY NE along the chosen path in the network in order for
> this to work.
>
> If there is a significant market for applications where
> solving (3) is vital but (1,2,4,5) are not so important,
> then it may be worth pushing arbitrary concatenation as
> a way to optimize how those services are provided over
> what you get with virtual concatenation.
>
> Regards,
> Steve Trowbridge
>
> "Bernstein, Greg" wrote:
> >
> > 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