Re: [CCAMP] New I-D for Flexi-grid labels

[[e-mail]]

Hi Fatai

See in line with <Fei>

Best

Fei



Zhangfatai <[e-mail]> 
2011-10-19 15:31

收件人
"[e-mail]" <[e-mail]>, Ramon Casellas 
<[e-mail]>
抄送
"[e-mail]" <[e-mail]>, "[e-mail]" 
<[e-mail]>
主题
RE: [CCAMP] New I-D for Flexi-grid labels






Hi Fei,
 
I think I am touching the tech closely.

Now, people can understand that your proposal (ie., bit rate in the 
Traffic Parameters) is not feasible, because each node cannot figure out 
how much spectrum bandwidth needs to be reserved after you clarified.

<Fei> I think you are misdirecting the WG experts and I never said "each 
node cannot figure out how much spectrum bandwidth needs to be reserved". 
Actually, there are a lot of ways to for the node to figure out the 
spectrum needs to be reserved. For example, a centralized path computing 
entity, PCE, can figure out the resources, and I tend to believe this will 
be a better idea. Of course,  the node can decide how much should be 
reserved based  the SENDER_TSPCE object (carrying bit rates), the signal 
attributes (the WG even does not have unanimous decision how to carry them 
in WSON now, see 
http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-02 section 4) 
and the local polices.  Ramon tends to agree with carrying the signal 
attributes in an "extended TSPEC", and I tend to see it as a independent 
object and do not change the usage of the SENDER_TSPCE object. Surely, 
these details need to be discussed in framework or signaling draft.

So, the spectrum width must be carried in the Traffic Parameters, because 
the signaling is used to reserve the spectrum and it is straightforward to 
carry the amount of the spectrum to be reserved.
 
<Fei> See above
 
 
Thanks
 
Fatai
 
From: [e-mail] [mailto:[e-mail]] 
Sent: 2011年10月19日 10:36
To: Zhangfatai; Ramon Casellas
Cc: [e-mail]; [e-mail]
Subject: RE: [CCAMP] New I-D for Flexi-grid labels
 

Hi Fatai 

You said "Do you have the formula?". Obviously you know that I do not have 
the exact formula, which needs to consider modulation format, FEC, bit 
rates, and the spectrum assignment is also related with routing. 

Surely, we need more discussion in CCAMP, ITU-T Q6 and related academic 
articles. 

Hope this clarify what happened and let us focus on the techniques. 

Best, 

Fei 


Zhangfatai <[e-mail]> 
2011-10-19 09:35 


收件人
"[e-mail]" <[e-mail]>, Ramon Casellas 
<[e-mail]> 
抄送
"[e-mail]" <[e-mail]>, "[e-mail]" 
<[e-mail]> 
主题
RE: [CCAMP] New I-D for Flexi-grid labels
 








Hi Fei, 
  
Ramon told the WG that himself does not have exact, concrete answers. 
  
I have to admit that I cannot have better understanding than Ramon on what 
Ramon said. 
  

It seems that you have the better undertanding than Ramon, so could you 
interpret how you can deduce the spectrum bandwidth based on all kinds of 
the information? 
  
Please don’t give me some examples, because if you say that it needs 
50GHz based on a specific example, some people will say it needs 62.5GHz. 
I.e., you should show the WG the consistent/standardized formula. 
  
Could you clarify a little more on your formula? 
  
  
  
Thanks

Fatai 
  
From: [e-mail] [mailto:[e-mail]] 
Sent: 2011年10月18日 17:41
To: Zhangfatai; Ramon Casellas
Cc: [e-mail]; [e-mail]
Subject: RE: [CCAMP] New I-D for Flexi-grid labels 
  

Hi Fatai 

I suggest you had better read Ramon's email carefully, and below is the 
exact word. 

I could imagine the sender descriptor tspec e.g. containing the rate 
(e.g. 10/40/100 Gbps) of the request. Depending on the chosen modulation 
format, FEC, guards and so on, a traffic request of 40 Gbps, can 
require, using e.g. OFDM 16-QAM say 20 GHz of optical spectrum. Another 
modulation may require 40 GHz. The optical spectrum will determine, 
given the slot width, the number of slots for that request. Selecting 
the slots (Spectrum Assigment) is somehow analog to WA (wavelength 
assignment) 


Best regards 

Fei 

Zhangfatai <[e-mail]> 
2011-10-18 17:33 
 


收件人
"[e-mail]" <[e-mail]>, Ramon Casellas 
<[e-mail]> 
抄送
"[e-mail]" <[e-mail]>, "[e-mail]" 
<[e-mail]> 
主题
RE: [CCAMP] New I-D for Flexi-grid labels

 
 









Hi Fei, 
 
You said:  “how much should be reserved is base on the modulation format, 
FEC, and the traffic parameters specified in the SENDER-TSPEC object.” 
 
How to figure out how much spectrum bandwidth on each node?  Do you have 
the formula? 
  

 
 
 
 
Thanks

Fatai 
 
From: [e-mail] [mailto:[e-mail]] 
Sent: 2011年10月18日 17:27
To: Zhangfatai; Ramon Casellas
Cc: [e-mail]; [e-mail]
Subject: Re: [CCAMP] New I-D for Flexi-grid labels 
 

Hi Fatai 

Some consideration from my side marked with <Fei> in your initial mail. 

Hope you like my interpretation and wish it can help clarify your puzzle. 

Best, 

Fei 

Zhangfatai <[e-mail]> 
发件人:  [e-mail] 
2011-10-18 16:37 
 
 


收件人
Ramon Casellas <[e-mail]>, "[e-mail]" <[e-mail]> 

抄送

主题
Re: [CCAMP] New I-D for Flexi-grid labels


 
 
 









Dear Ramon, 

Thanks for your comments. 

Firstly, from control plane perspective, label definition cannot exist 
without routing or signaling. If there is no Flex-Grid tech in data plane, 
there is no need to define label format for Flex-Grid, so we have the same 
assumption that there will be Flex-Grid tech ready for the industry. Based 
on this assumption, if we define label format, we should have an overall 
perspective to figure out how to define an appropriate label format in the 
environment of signaling or routing. 

Let's focus on the tech stuff. 

I have some questions from your comments, especially from your penultimate 
paragraph of the first point. 

A big question came from me: What information should be carried in the 
Traffic Parameters based on [draft-farrkingel]? 

We know that RSVP is “Resource” ReserVation Protocol. 

What is resource in the Flex-Grid? I think the answer is “Frequency” or 
“Spectrum”. How much resource should be reserved? What information 
should be based on when each node reserves the resource? What is the role 
of the Traffic Parameters? 

<Fei> The resources in the flex-Grid are spectrum bandwith, and how much 
should be reserved is base on the modulation format, FEC, and the traffic 
parameters specified in the SENDER-TSPEC object. IMHO, the traffic 
parameters carried in the SENDER-TSPEC is the data bit rates, and the 
usage is not changed and should not be changed. 


So, could you clarify what information should be carried in the Traffic 
Parameters? 

<Fei> See above 


Thanks 

Fatai 


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of 
Ramon Casellas
Sent: 2011年10月17日 18:35
To: [e-mail]
Subject: Re: [CCAMP] New I-D for Flexi-grid labels 

Dear Fatai, Adrian, all 


I am somehow reluctant to state my opinion, given the lack of a standard 
data plane and a common view of what an elastic/flexigrid/... optical 
network is, including the role of modulation formats, FECs, etc... 

This is somehow not problematic for the case of the label definition 
which maps ITU SG15 Q6, but it may be if work is started for signalling, 
routing or path computation 

In any case, FWIW and for the sake of discussion, please find below, 
in-line, my views 



El 17/10/2011 10:49, Adrian Farrel escribió: 
> Hi Fatai, 
> 
> 1. Where is the m parameter carried? 
> 
> draft-farrkingel suggests it belongs in the label 
> draft-zhang says it should be a traffic parameter 

In my humble opinion, I think it belongs to the label / label encoding, 
some arguments for this could be: 


* much like in WSON the label identifies directly the wavelength and the 
switched resource, in SSON / EON the label should identify the switched 
resource, identified by the involved slots, i.e. base slot and slot 
count, the "slice" or frequency range 
 All drafts have chosen to align with current encoding of LSC labels, 
RFC6205, based on a 32 bit format. If 64 bit is problematic, alternative 
methods could be proposed, e.g., such as (this was proposed before the 
notion of "identifier" was introduced in WSON) 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|Grid |  C.S. |   m             |              n                | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


* It seems to me that having m in the label itself will ease the 
processing of SUGGESTED_LABEL, RECOVERY_LABEL, and, notably, 
UPSTREAM_LABEL, which  should include m. This does not require support 
for asymmetric bandwidth, and m is required for the upstream label 
processing / cross-connect during the Path message 

* In waveband switching in, say RFC3473, the generalized label 
identifies (by mean of start/end) the involved wavelengths. I am aware 
that waveband switching and elastic channel is not exactly the same, but 
shows the taken approach 

* In ERO / RRO processing, using Explicit Label Control, I would need 
the number of slots that are switched. This is helpful say, for 
centralized/PCE based RSA. 

* If using say, a LABEL_SET object, each entry in the LABEL_SET could be 
a potential label to be selected, knowing m here eases operation. 
Similar, a simplistic identification of a  "cross-connect" is determined 
by in_port - in_label / out_port - out_label. The knowledge of m at this 
point is required 

I could imagine the sender descriptor tspec e.g. containing the rate 
(e.g. 10/40/100 Gbps) of the request. Depending on the chosen modulation 
format, FEC, guards and so on, a traffic request of 40 Gbps, can 
require, using e.g. OFDM 16-QAM say 20 GHz of optical spectrum. Another 
modulation may require 40 GHz. The optical spectrum will determine, 
given the slot width, the number of slots for that request. Selecting 
the slots (Spectrum Assigment) is somehow analog to WA (wavelength 
assignment) 

This are just my subjective views, open. I would also like to see other 
ones :-) 



> 2. Is a new Grid value needed? 
> 
> draft-zhang says flexigrid is from the DWDM grid and so should use the 
existing DWDM value. 
> 
> draft-farrkingel suggests it would be clearer to assign a new value so 
that the label can be easily distinguished from the fixed grid cases. 
Note, however, that the draft-farrkingel approach could use the DWDM grid 
value without any change to the label format proposed in the draft. 
I agree with the latter approach. 



Another question that has arisen in private discussions, which I 
forward, is whether you think a new switching type should be defined 
(other than LSC)  -- I don't have a clear opinion on this -- 


Thanks and best regards 

Ramon 

_______________________________________________ 
CCAMP mailing list 
[e-mail] 
https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp