|
Hi Snigdho, responses below. --Snip-- ---> GMPLS is a general approach that includes a base set of protocols plus extensions. STM-256's are handled with the SONET/SDH extensions detailed in RFC4606. From a layering perspective I'd argue against modifying RFC4606 since that document and its predecessor dealt with the digital (TDM) signals and their multiplexing structure. Hence I'd think it more prudent to model the fact that a given digital signal (STM, or Ethernet say) can have more than optical modulation or FEC schemes at an appropriate "optical layer".-----> What is a "WSON signal" is a key question we are trying to nail down hear and with the framework draft. Sorry to lead you astray with the "wireless" backhaul application. We are primarily concerned with digital signals as is the case for G.872 and G.709. However specification of the signal type such as STM-256 is not sufficient anymore since the same signal type may employ different modulations. In ITU-T G.959.1 (March 2006) they introduce general signal classes to differentiate this, i.e., NRZ 40G and RZ 40G. This ITU-T spec and many others including G.872 lay the foundation for what we need to characterize a "WSON signal" for our purposes... ---> Extensions to GMPLS protocols may or may not be specific to a technology or an application area. However the demand for an extension to GMPLS must stem from some concrete requirement. Hence when we look at GMPLS RSVP-TE signaling as specified in RFC3473 you see that it is updated by RFC 4003,RFC 4201,RFC 4420,RFC 4783,RFC 4873,RFC 4874,RFC 4974,RFC 5063,RFC 5151. And these are all the extensions available for use in "GMPLS RSVP-TE". You'll see another example of this in Dublin where the VCAT/LCAS draft needed some kind of call object, similarly for some Ethernet service stuff and it turns out that the MRN draft has a CALL_OPS defined which the other drafts will use.------> Let me clarify this a bit. GMPLS signaling utilizing the "label set" feature already supports distributed wavelength assignment. However this technique encounters a problem when we attempt to use it for bi-directional signals per current GMPLS standards. See the Framework document for more details. Hence this requirement is really a request to fix something that is broken not add a whole new class of functionality. ---> Hmm, I thought this was clear from the above: "When we encounter OEO devices such as wavelength converters or regenerators many of these can accomodate multiple signal types but need this basic low level information to determine compatibility." By including such information as modulation type, modulation parameters, and bit rate in signaling we can configure the devices along the path. For example a 3R regenerator or OEO based wavelength converter is needs timing (bit rate) information (see ITU-T G.872 Annex A).-------> "bit rate" is a standard GMPLS/MPLS-TE signaling parameter, though it is actually specified in bytes per second and specified as a 32 bit IEEE floating point number so this isn't a new parameter for GMPLS. I'm looking at "necessary" "optical/physical" parameters since we know the signal types such as OTUk, STM-x, GigE, etc... When we encounter OEO devices such as wavelength converters or regenerators many of these can accomodate multiple signal types but need this basic low level information to determine compatibility. ITU-T G.872 Annex A tells us what information we must have to determine compatibility with a particular level of regenerator (and hence we can use this for OEO based wavelength converters too).
-- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 |