Subject: Comments on draft-bernstein-ccamp-wson-signaling-02.txt

From: "Bardalai, Snigdho" <[email-masked]>
Date: Sat, 19 Jul 2008 08:08:17 -0500

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.
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. 
3. Basic WSON signaling should be in alignment with G.872 and G.709 concepts.
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?

Thanks,
Snigdho

---

From: Greg Bernstein <[email-masked]>
Date: Mon, 21 Jul 2008 09:27:19 -0700

Hi Snigdho! I've got some questions on your comments and I'll take a 
stab at some answers...

Regards

Greg

Bardalai, Snigdho wrote:
> 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).
>
> 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. 
> 3. Basic WSON signaling should be in alignment with G.872 and G.709 
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...

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

---

From: "Bardalai, Snigdho" <[email-masked]>
Date: Mon, 21 Jul 2008 12:22:41 -0500

Hi Greg,
 
Please see my responses.
 
Thanks,
Snigdho

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Greg Bernstein
Sent: Monday, July 21, 2008 11:27 AM
To: Bardalai, Snigdho
Cc: Ccamp (E-mail)
Subject: Re: Comments on draft-bernstein-ccamp-wson-signaling-02.txt

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, 

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.

--> 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. 

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.

--> 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 

--

---

From: Young Lee <[email-masked]>
Date: Mon, 21 Jul 2008 13:57:27 -0500

Hi Snigdho, 

See my response in-line. Thanks. 

Young

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Bardalai, Snigdho
Sent: Monday, July 21, 2008 12:23 PM
To: Greg Bernstein
Cc: Ccamp (E-mail)
Subject: RE: Comments on draft-bernstein-ccamp-wson-signaling-02.txt

Hi Greg,

Please see my responses.

Thanks,

Snigdho

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Greg Bernstein
Sent: Monday, July 21, 2008 11:27 AM
To: Bardalai, Snigdho
Cc: Ccamp (E-mail)
Subject: Re: Comments on draft-bernstein-ccamp-wson-signaling-02.txt

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, 

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.

[Young] (b) actually does not deal with "distributed" wavelength
assignment." Perhaps, we have to clarify some of the wordings used in the
current draft to avoid misunderstanding. The main focus of (b) is how to
permit simultaneous bi-directional wavelength assignment. It defines a
signalling mechanism for same wavelength bidirectional lightpath to reduce
setup times and lowers blocking probability. The exact wavelength to use
hop-by-hop can be assigned by the PCE or by the NE. 

As for (c), we are asking the WG as Greg said before if we should retain it
or not --- This is an optional feature for sure. 

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

---

From: Greg Bernstein <[email-masked]>
Date: Tue, 22 Jul 2008 09:07:46 -0700

Hi Snigdho, Young and all.  A few clarifications and comments below

Greg

---snip---
>     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.
>
>     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.
>
-----> 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...
>
>     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.
>
>      
>
>     assignment." Perhaps, we have to clarify some of the wordings used
>     in the current draft to avoid misunderstanding. The main focus of
>     (b) is how to */permit simultaneous bi-directional wavelength
>     assignment. It /**/defines a signalling mechanism for same
>     wavelength bidirectional lightpath to reduce setup times and
>     lowers blocking probability. The exact wavelength to use
>     hop-by-hop can be assigned by the PCE or by the NE. /*
>
------> 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.
>
>     As for (c), we are asking the WG as Greg said before if we should
>     retain it or not --- This is an optional feature for sure.
>
>     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.
>>
>     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. 
>     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?
>
>     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.
>
------->  "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).

---

From: "Bardalai, Snigdho" <[email-masked]>
Date: Tue, 22 Jul 2008 14:38:56 -0500

Hi Greg,
 
Responses below.
 
Snigdho

-----Original Message-----
From: Greg Bernstein [mailto:[email-masked]]
Sent: Tuesday, July 22, 2008 11:08 AM
To: Young Lee
Cc: Bardalai, Snigdho; 'Ccamp (E-mail)'
Subject: Re: Comments on draft-bernstein-ccamp-wson-signaling-02.txt

Greg

---snip---

Bardalai, Snigdho wrote: 

Hi Greg et al, 

-----> 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...
[Bardalai, Snigdho] Is specification of the STM-256 modulation scheme a WSON specific issue? Should this not be addressed generally from a GMPLS perspective? 

[Young] (b) actually does not deal with "distributed" wavelength assignment." Perhaps, we have to clarify some of the wordings used in the current draft to avoid misunderstanding. The main focus of (b) is how to permit simultaneous bi-directional wavelength assignment. It defines a signalling mechanism for same wavelength bidirectional lightpath to reduce setup times and lowers blocking probability. The exact wavelength to use hop-by-hop can be assigned by the PCE or by the NE. 

------> 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.
[Bardalai, Snigdho] This seems to an general GMPLS issue wrt specifying the "label set" for the reverse direction traffic. Again, why is this specific to WSON?

As for (c), we are asking the WG as Greg said before if we should retain it or not --- This is an optional feature for sure. 

------->  "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).
[Bardalai, Snigdho] Why is it necessary to encode additional "optical/physical" parameters for O-E-O regeneration? What is the basis of your assumption? 

Thanks, 
Snigdho 

--

---

From: Greg Bernstein <[email-masked]>
Date: Wed, 23 Jul 2008 08:30:08 -0700

Hi Snigdho, responses below.

--Snip--
>
>     -----> 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...
>     [Bardalai, Snigdho] Is specification of the STM-256 modulation
>     scheme a WSON specific issue? Should this not be addressed
>     generally from a GMPLS perspective?
>
--->     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".
>
>>         /*--snip--*/
>>
>     ------> 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.
>     [Bardalai, Snigdho] This seems to an general GMPLS issue wrt
>     specifying the "label set" for the reverse direction traffic.
>     Again, why is this specific to WSON?
>
---> 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.
>
>>         --snip--
>>
>     ------->  "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).
>     [Bardalai, Snigdho] Why is it necessary to encode additional
>     "optical/physical" parameters for O-E-O regeneration? What is the
>     basis of your assumption? 
>
---> 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).

---

From: "Bardalai, Snigdho" <[email-masked]>
Date: Wed, 23 Jul 2008 11:05:25 -0500

Hi Greg,
 
Responses.
 
Snigdho

-----Original Message-----
From: Greg Bernstein [mailto:[email-masked]]
Sent: Wednesday, July 23, 2008 10:30 AM
To: Bardalai, Snigdho
Cc: Ccamp (E-mail)
Subject: Re: Comments on draft-bernstein-ccamp-wson-signaling-02.txt

--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".
[Bardalai, Snigdho] Why not extend RFC4328? G.709 allows STMx over OCh. 

--snip--

---> 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.
[Bardalai, Snigdho] Could this be part of an extension of RFC4328 ??? 

--snip--

---> 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).
[Bardalai, Snigdho] Sorry, my question was not clear. What is preventing us from using the "signal type" for this purpose? 

-- 

    

--

---

From: Greg Bernstein <[email-masked]>
Date: Thu, 24 Jul 2008 11:38:49 -0700

Hi Snigdho, I think we should meet and discuss in Dublin, face to face 
discussions are sometimes easier than e-mail, but see below for one last 
comment.
Regards

Greg

Bardalai, Snigdho wrote:
-- snip--
>
>     ---> 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
>     [Bardalai, Snigdho] Sorry, my question was not clear. What is
>     preventing us from using the "signal type" for this purpose?
>
--> The same "signal type" such as an OTUk, STM, or an Ethernet might 
use different (a) modulation type, (b) modulation parameters, or (c) FEC 
(which can also affect the bit rate).  Or do you mean a generalization 
of the "signal type" to include these new fields for a "light path" (or 
whatever we choose or are allowed to call it). And this information is, 
in effect, lower layer information and hence appropriate to the WSON 
discussions.