Hi Young and Julien, I missed this discussion in San Francisco but I tend to agree with (most of) Julien's comments. But if the PCE is expected to compute paths taking optical impairments into account it makes sense for a PCC to be able to set a "threshold" constraint, or minimum acceptable signal quality, although I find it a bit difficult to see under what circumstances anyone would be satisfied with anything else than "virtually zero" BER (or "error-free") for an optical path. In addition, some OSNR margin is usually required in order to allow for aging and other effects. In this case I think it might be better to specify the pre-FEC BER (or equivalent Q-factor if that sounds more related to the optical layer) and maybe in addition the desired OSNR margin.
Regards, Jonas > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of [email protected] > Sent: den 3 april 2009 17:18 > To: [email protected] > Cc: [email protected] > Subject: Re: [Pce] Comment on WSON Requirements > > Hi Young. > > If I understand correctly, your actual requirement is to find > a "threshold criteria" to request a route that is "healthy > enough" for the PCC. So why have you chosen the BER which > more relative to a digital client layer? Why not considering > a more optical criteria, like OSNR for instance? > > Have a good week-end, > > Julien > > > -----Original Message----- > From: Young Lee [mailto:[email protected]] > > Hi Julien, > > The reason why we put the BER threshold in the PCEP request > is to "approximate" if the optical path in consideration > would be "healthy" > enough > from the BER perspective. Please note that we have defined > two different computation types of IA-PCE functions in the > IA-WSON framework draft: > (i) > approximate approach; (ii) candidate approach. Approximate > approach is a quick way of estimating the affects of > impairment while the candidate approach is to give a list of > acceptable paths with more thorough data/model. > > The BER can be estimated in various ways given the > availability of other impairment parameters. In any IA-RWA > (approximate) type computation where we are given impairment > parameters to estimate the affects of impairments, we must > use some threshold criteria to accept/reject paths. The BER > parameter was our first attempt at providing some control > over this criterion. > > Best Regards, > Young > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] > > Hi Young. > > This is a try to resume our discussion started during the SF meeting. > Indeed, I still don't get the rationale behind adding the BER > as a requirement for PCEP request. > > First, I wonder what your intend is when requesting a BER > threshold at computation time while you can't really know it > before LSP provisioning. > Obviously, what we look for is a low BER, but the way I see > using BER in routing would be to request a 2nd route *after* > a poor BER measurement on a firstly established LSP. > Then, considering what you called a "BER estimation", I don't > clearly see how you intend to estimate (or model?) it. The > BER associated to an LSP is highly dependent on so many > parameters: link DGD at measurement time, performance of the > FEC used for the to-be-provisioned LSP , possible cross-talk > and thus impact of potential adjacent channels... > Furthermore, I > don't really understand why focusing on the measurable BER > range while a typical PMD (in)accuracy may just move us > between an acceptable route and an unacceptable one, the > latter being the very 1st problem we should try to solve. > Finally, I don't get the use of such feature. Even if we > could, why would I request a 10^(-6) maximum BER? I don't see > any room for anything else than "the best one", so do we > really need something else? I tend to see BER as a varying > quality feed*back*, not as an indicator that we can > accurately target at routing time. > > I completely agree that PCEP must support optical > requirements, but my concern is to understand actual needs > before loading the protocol. > Therefore, I look forward to reading some clarification on > those issues. > > Best regards, > > Julien > > _______________________________________________ > Pce mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/pce > > _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
