Hi Snigdho!
I've got some questions on your comments and I'll take a stab at some
answers...
Regards
Greg
Bardalai, Snigdho wrote:
Hi Greg et al,
I have a few comments on this draft
proposal.
1. I believe basic WSON signaling extensions
should be separated from signaling based RWA solutions. The reason is the
scope of each problem is different.
There are three basic requirements in the signaling draft (a)
characterization of WSON signals, (b) bi-directional distributed wavelength
assignment for WSON signals, and (c) an option for specifying the distributed
wavelength assignment method to be used at each node. Items (a) and (c) were
from Young and my original draft and (b) was from Sugang, Hiroki and Dan
King's draft which the chairs mentioned we should merge with ours. Is item (c)
bothering you? Or the combination of (a) with (b) and (c). We wanted the
WG's opinion on item (c).
[Bardalai, Snigdho] May I ask what is a "WSON
signal" ? Somewhere below you mention a "wireless" application, what
application is this, what std. is it based on? It seems we are assuming
something about the data-plane here. If that is not clearly defined how can we
discuss about characterization? On the other hand I can completely understand
what (b) and (c) is refering to.
Hence, I believe the scope of (a) is different from (b) and (c).
(b) and (c) are addressing some specific issues of distributed
(signaling based) RWA.
The
other concern is compliance to such a document. Typically there will be a
choice between distributed (signaling based) or centralized (PCE/routing
based) RWA, but (a) would be required to be supported for both RWA
approaches. Hence I would consider (a) to be a basic requirement. I believe
that we are mixing too many things here.
2. I believe we have not yet established what
level of client layer characterization should be included in an OCH layer
LSP. For that matter the definition of "Lightpath" is not yet completed and
agreed.
--> In the e-mail I sent concerning the WSON
Framework document I brought up the issue of "lightpath" definition. In
a more detailed reading of G.709 and G.872 I got the impression that OCh is a
bit too restrictive. In G.709 it is defined from 3R to 3R. Now we want
to include wavelength converters even if we are not currently dealing with
impairments and most wavelength converters are regenerators (2R or 3R) with
tunable lasers. G.872 doesn't consider the wavelength of the optical signal
part of its characteristic information hence an OCh can go through a
wavelength converter and they give an example in Appendix I.
[Bardalai,
Snigdho] Thanks for the clarification.
3. Basic WSON signaling should be in alignment
with G.872 and G.709 concepts.
Agree. Note that
RFC4328 covers the standard G.709 digital hierarchy. For signals not in the
G.709 digital hierarchy the concepts and terminology of G.709/G.872 still
apply (with some caveats): the OCh (optical channel), OMS (optical multiplex
section), OTS (optical transmission section), and Physical Media Layer (the
optical fiber itself). It seems that G.709 and G.872 have slightly different
notions of what an OCh is (G.709 seeming more restrictive).
Now from the
practical side of things there are standards at the ITU-T that actually talk
about characterizing the signals like G.696.1. To determine receiver
compatibility we can run into trouble with a higher layer signal designation
such as STM-256 since different modulation (RZ, NRZ) maybe used. Hence the
ITU-T started defining signal classes by (a) modulation, (b) modulation
parameters (if any), (c) bit rate, and (d) FEC.
4. If optical impairments is not in the current
scope why do we need to encode "analog bit rate", will the client layer
signal type (i.e. SONET/SDH or ODUk etc.) not be sufficient for your
purposes?
--> Do you mean "analog bandwidth"?
Although G.872 are aimed at transport of digital signals, I recall a request
from someone to include some minimum ability to deal with "analog signals" for
an application where wireless signals were put over the fiber without much
processing.
If you meant "bit rate" for a digital signal compatibility with
the receiver and any OEO based wavelength converters...
[Bardalai,
Snigdho] I meant "bit rate". I don't think bit-rate, mod and FEC is
sufficient for OEO based digital signal compatibility, which means information
such as encoding type, signal type etc. is necessary. Given that I cannot
understand why we need to include the "analog bit rate", because based on
signal type information it is possible to derive the bit-rate. Also, without
completely understanding the wireless application it is not possible to say if
we do require the analog bandwidth, so I will defer my comment on that till I
understand what you are refering to.
Thanks,
Snigdho
--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237