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

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 16 Oct 2011 20:40:03 +0100

Hi,

You are probably aware that Question 6 of Study Group 15 of the ITU-T has been
working on the "flexible grid" specification for selecting lambdas for use in
optical
signaling and switching.

This draft is a stake in the ground for defining a label for use in GMPLS that
can
encode a lambda selected from the flexible grid according to the specification
of
Q6/15.

As the draft observes, there is no intention for this document to become an RFC
before Q6/15 have finished their work, and I personally (as an author of the
draft) would expect that we would ask Q6/15 to comment on our encoding to
ensure we are interpreting the concept correctly and encoding all of the
parameters.

Since posting the draft
(http://tools.ietf.org/html/draft-farrkingel-ccamp-flexigrid-lambda-label-00)
Dan and I became aware that there was prior work in this area
(http://tools.ietf.org/html/draft-li-ccamp-flexible-grid-label-00). It was
certainly not our intention to compete with this other draft and so we are
talking with its authors with a view to merging our efforts. Watch out for a new
revision soon.

Cheers,
Adrian

---

From: Zhangfatai <[email-masked]>
Date: Mon, 17 Oct 2011 01:45:20 +0000

Hi Adrian and all,

You may be aware that we have done some work on this area and we have submitted some drafts about flexible grid.

The first one is about the GMPLS requirements of flexible grid, another one is about signaling draft for flexible grid.

We are trying to give an overview of flexible grid tech (including GMPLS requirements) to the CCAMPers and provide the signaling extensions for flexible grid control instead of only focusing on the label format.

You can see more details from:

http://tools.ietf.org/id/draft-zhang-ccamp-flexible-grid-requirements-00.txt

http://www.ietf.org/id/draft-zhang-ccamp-flexible-grid-rsvp-te-ext-00.txt

Any comments or suggestions are welcome.

Thanks
 
Fatai

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: 2011年10月17日 3:40
To: [email-masked]
Subject: [CCAMP] New I-D for Flexi-grid labels

Hi,

Since posting the draft

Cheers,
Adrian

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 17 Oct 2011 09:49:29 +0100

Hi Fatai,

Well there certainly seems to be a rush to make drafts in this area. So either it is really important or a good opportunity to write a draft.

We have just completed the work to merge the Yao Li's draft with the work Dan and I had done. And I have just posted this.
http://www.ietf.org/id/draft-farrkingel-ccamp-flexigrid-lambda-label-01.txt

It looks like the finer details of our draft are the same as those in Fatai's draft. That is, we all recognise the need for an additional parameter "m" to define the slot width. Additionally, we all recognise the need to define a new channel spacing value for 6.25 GHz.

There are two main difference between the approaches. In my view the differences can be handled separately.

1. Where is the m parameter carried?

draft-farrkingel suggests it belongs in the label
draft-zhang says it should be a traffic parameter

My view (obviously) is that m is an important feature of the switchable quantity and is not simply a description of the bandwidth. The negative of putting m in the label is that the label size is increased. 

The WG will need to discuss this.

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.

Again, the WG will need to discuss this.

Thanks,
Adrian

> From: Zhangfatai [mailto:[email-masked]]
> Sent: 17 October 2011 02:45
> To: [email-masked]; [email-masked]
> Subject: RE: [CCAMP] New I-D for Flexi-grid labels
> 
> Hi Adrian and all,
> 
> You may be aware that we have done some work on this area and we have
> submitted some drafts about flexible grid.
> 
> We are trying to give an overview of flexible grid tech (including GMPLS
> requirements) to the CCAMPers and provide the signaling extensions for flexible
> grid control instead of only focusing on the label format.
>

---

From: Zhangfatai <[email-masked]>
Date: Mon, 17 Oct 2011 09:34:42 +0000

Hi Adrian,

Thanks for your great summary, which captures all the things, :-)~~~

Yes, I agree with you that it seems to be a rush, so we held on this work until the rapporteur of Q6 sent the plan to the SG15 to consent the revised G.694.1 (i.e., flexible grid) in December. Obviously, this work in IETF depends on the progress of ITU-T SG15.

We would like to request the WG to review these drafts and share your comments.

Thanks
 
Fatai

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: 2011年10月17日 16:49
To: Zhangfatai
Cc: [email-masked]
Subject: RE: [CCAMP] New I-D for Flexi-grid labels

Hi Fatai,

Thanks,
Adrian

---

From: Ramon Casellas <[email-masked]>
Date: Mon, 17 Oct 2011 12:34:45 +0200

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

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

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

---

From: [email-masked]
Date: Mon, 17 Oct 2011 19:56:44 +0800

Hi Fatai, Adrain,Ramon, all:
 
I want to add my opinion in addition to Ramon's. I don't think it may be 
appropriate to carry the slot width in the SENDER_TSPEC or FLOWSPEC object 
mentioned in draft-zhang, as the two objects should be constant in the 
signaling procedure. However, according to my understanding, the label 
assignment should be a hop-by-hop action while the SENDER_TSPEC or 
FLOWSPEC objects are not. For a simple example of a establishing a LSP 
with O-E-O node, the slot width requirement before the O-E-O node may be 
different to the node after the O-E-O node, as different modulation 
format, FEC etc are chosen for different segment. So, as mentioned in 
draft-farrkingel, the slot width identified in the label seems to be a 
better solution and has a good alignment with ITU-T definition. 
 
I would like to see other opinions.

Best regards
Yao Li

Ramon Casellas <[email-masked]> 
发件人:  [email-masked]
2011-10-17 18:34

收件人
[email-masked]
抄送

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

Dear Fatai, Adrian, all

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

Thanks and best regards

Ramon

---

From: Iftekhar Hussain <[email-masked]>
Date: Mon, 17 Oct 2011 18:53:35 +0000

Hi Adrian,

FYI...Please note there is another draft on this topic which was not mentioned below

http://tools.ietf.org/html/draft-hussain-ccamp-super-channel-label-00

Regards,
Iftekhar
-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Sunday, October 16, 2011 12:40 PM
To: [email-masked]
Subject: [CCAMP] New I-D for Flexi-grid labels

Hi,

You are probably aware that Question 6 of Study Group 15 of the ITU-T has been working on the "flexible grid" specification for selecting lambdas for use in optical signaling and switching.

This draft is a stake in the ground for defining a label for use in GMPLS that can encode a lambda selected from the flexible grid according to the specification of Q6/15.

As the draft observes, there is no intention for this document to become an RFC before Q6/15 have finished their work, and I personally (as an author of the
draft) would expect that we would ask Q6/15 to comment on our encoding to ensure we are interpreting the concept correctly and encoding all of the parameters.

Since posting the draft
(http://tools.ietf.org/html/draft-farrkingel-ccamp-flexigrid-lambda-label-00)
Dan and I became aware that there was prior work in this area (http://tools.ietf.org/html/draft-li-ccamp-flexible-grid-label-00). It was certainly not our intention to compete with this other draft and so we are talking with its authors with a view to merging our efforts. Watch out for a new revision soon.

Cheers,
Adrian

---

From: Zhangfatai <[email-masked]>
Date: Tue, 18 Oct 2011 08:37:24 +0000

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?

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

Thanks

Fatai

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

Dear Fatai, Adrian, all

in-line, my views

|Grid |  C.S. |   m             |              n                |

shows the taken approach

point is required

assignment)

ones :-)

Thanks and best regards

Ramon

CCAMP mailing list

[email-masked]

---

From: Zhangfatai <[email-masked]>
Date: Tue, 18 Oct 2011 08:57:17 +0000

Dear Yao,

According to ITU-T definition, Flex-Grid still belongs to DWDM, however, [draft-farrkingel] introduces a new type of Grid. Why you said that [draft-farrkingel] has good alignment with ITU-T definition?

See more comments from my email to Ramon.

Thanks

Fatai

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 2011年10月17日 19:57
To: [email-masked]
Subject: Re: [CCAMP] New I-D for Flexi-grid labels

I want to add my opinion in addition to Ramon's. I don't think it may be appropriate to carry the slot width in the SENDER_TSPEC or FLOWSPEC object mentioned in draft-zhang, as the two objects should be constant in the signaling procedure. However, according to my understanding, the label assignment should be a hop-by-hop action while the SENDER_TSPEC or FLOWSPEC objects are not. For a simple example of a establishing a LSP with O-E-O node, the slot width requirement before the O-E-O node may be different to the node after the O-E-O node, as different modulation format, FEC etc are chosen for different segment. So, as mentioned in draft-farrkingel, the slot width identified in the label seems to be a better solution and has a good alignment with ITU-T definition.

Best regards
Yao Li

2011-10-17 18:34

收件人

[email-masked]

抄送

主题

Dear Fatai, Adrian, all

Thanks and best regards

Ramon

---

From: [email-masked]
Date: Tue, 18 Oct 2011 17:26:51 +0800

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 <[email-masked]> 
发件人:  [email-masked]
2011-10-18 16:37

收件人
Ramon Casellas <[email-masked]>, "[email-masked]" <[email-masked]>
抄送

主题

Dear Ramon,

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.

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

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: [email-masked] [mailto:[email-masked]] On Behalf Of 
Ramon Casellas
Sent: 2011年10月17日 18:35
To: [email-masked]
Subject: Re: [CCAMP] New I-D for Flexi-grid labels
 
Dear Fatai, Adrian, all

 

 

 

 

 

Thanks and best regards
 
Ramon

---

From: Zhangfatai <[email-masked]>
Date: Tue, 18 Oct 2011 09:33:08 +0000

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: [email-masked] [mailto:[email-masked]]
Sent: 2011年10月18日 17:27
To: Zhangfatai; Ramon Casellas
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] New I-D for Flexi-grid labels

Hi Fatai

Best,

Fei

2011-10-18 16:37

收件人

抄送

主题

Dear Ramon,

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

<Fei> See above

Thanks

Fatai

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

Dear Fatai, Adrian, all

Thanks and best regards

Ramon

_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: [email-masked]
Date: Tue, 18 Oct 2011 17:41:05 +0800

Hi Fatai

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

Best regards

Fei

2011-10-18 17:33

收件人
"[email-masked]" <[email-masked]>, Ramon Casellas 
<[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
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

Hi Fatai 

Best, 

Fei 

收件人

抄送

主题

Dear Ramon, 

  

  

  
<Fei> See above 

Thanks 
  
Fatai 

-----Original Message-----
  
Dear Fatai, Adrian, all 

  

  

  

  

  

Thanks and best regards 
  
Ramon

---

From: Ramon Casellas <[email-masked]>
Date: Tue, 18 Oct 2011 11:54:16 +0200

Dear Fatai, all

Please see inline. Apologies for the long mail

El 18/10/2011 10:37, Zhangfatai escribió:
> 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.
>

That's a good point. It is fine for me to start considering, as a 
whole,  aspects such as path computation, routing and signalling. And 
you are right that only defining the label without further consideration 
seems pointless.

I guess my main point was that, at least for me, I still have some 
concerns regarding data plane aspects that I would like to clarify. 
Maybe not in the basic flex-grid technology / concept itself, but in the 
network as a whole. For example, should we consider the equivalent of 
wavelength converters for elastic frequency slots or slices?. Is a 
"Flexi" Switch Capable LSP bounded by O/E/O conversions and remains only 
on the optical domain ? should we still work under the unbrella of LSC 
or define a new switching layer? what's the role of modulation formats, 
transceivers, and so on? - Hussain Iftekhar draft 
(http://tools.ietf.org/html/draft-hussain-ccamp-super-channel-label-00) 
considers that a label can correspond to several, non-necessary 
contiguous basic slots thus Hussain's and Adrian-Yao's drafts differ on 
the basic concept of a switchable entity. As you may guess, I don't have 
answers for these... :-) a common framework would be useful, nothing more.

Of course, this does not preclude to start work on CCAMP with an initial 
set of assumptions, mainly as an extended WSON, call it, for example, 
SSON :)  I would like, by no means, to object to work on this area :D

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

> 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?
>
I agree with yout that the controled resource is the optical spectrum. 
The problem I see is that depending on other factors such as FECs, 
modulation formats and related, I think that there is not a one to one 
relationship between data rates and optical spectrum, depending on the 
choice of modulation format (a CBR data rate of 40 Gbps could end-up 
requiring e.g. 40 GHz or less?). Additionally, Yao's example showing 
that a given client of 40 Gbps sent over a flexi LSP which croses O/E/O 
nodes could end up "consuming" different "frequency slices" at each side 
of the O/E/O is a good one (I tend to think that developing  data plane 
technologies such as OFDM and similar will have an important role in 
flexi-nets).

This problem does not seem to occur in, say, packet switched networks in 
the sense that the controled resource (link bandwidth) and the traffic 
characterization are in the same "units" and the traffic trunk or 
aggregate is based on the statistical / asynchronous multiplexing with 
seemingly well defined rules.

To answer your question, the resource to be reserved is the optrical 
spectrum, which can be translated to a unsigned integer > 0 (m) of 
consecutive basic slots of a given, known in advance, size. My first 
impression is that, if a node knows m (and of course, grid, CS and n), 
it has  the basic information to  do the actual reservation and the 
cross-connect. This does not preclude that other information (notably 
TSPEC) could be used (locally, or globaly depending on aspects such as 
continuity constraint, transparency ...) to deduce m for a given client 
signal. A basic example can be given in the case of a centralized PCE 
that does the Routing, modulation, FEC assignment, and indicates the 
optical spectrum in GHz and then a distributed signaling performs the 
Spectrum Assignment (SA), where RSVP can collect the free slots and the 
egress node, knowing all the LSP parameters, can compute m and start the 
reservation upstream with m encoded in the label. This procedure can be 
repeated any time there is a O/E/O conversion (your requirement drafts 
refers to this as R+SA if I am not mistaken).

> So, could you clarify what information should be carried in the 
I am sorry I don't have exact, concrete answers, just food for thoughts 
and rough ideas. To some extent I had this question even in WSON. What 
the purpose of say, a token-bucket TSPEC / FLOWSPEC in WSON? It is 
advised to have just peak rate? Isn't the actual reserved element a 
wavelength, regardless of the actual client signal?
My "preliminary" view is that the TSPEC could contain, as a bare 
minimum, the data rate (in Gbps) of the client signal which is required 
to deduce "m". This information can be used, say, by a PCE to deduce the 
optical spectrum (in GHz), knowing the modulation format selected for 
the path,  based on physical impairments, physical distance, OSNR / SER 
requirements and so on. It follows that those parameters could be 
conveyed in the "extended" TSPEC: optical spectrum, FEC, modulation 
format, helping WA / SA that happens at each regeneration point to 
deduce "m" which is encoded in the label for each "transparent" segment.

Thank you for the insightful question. Your view on this issue would be 
very useful to come up to some consensus on what would be the 
information and encoding in the TSPEC.

Thanks and best regards
Ramon

---

From: [email-masked]
Date: Tue, 18 Oct 2011 18:45:17 +0800

Hi Fatai:

   [draft-farrkingel] introduces a new type of Grid. I think this can make 
it clearer when analyzing the label for fixed usage or flexible.

Whereas, introducing of this type of Grid will be communicated to the 
ITU-T for comment. This draft is an initial version, and will be revised 
according to the ITU-T discussion.

Actually, what I want to say with respect to “[draft-farrkingel] has good 
alignment with ITU-T definition “is that the slot width parameter m 
should be carried in the label not in the 
SENDER_TSPEC or FLOW objects. This has been stated in my last email.

Best regards 
Yao Li  

2011-10-18 16:57

收件人
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
抄送

主题

Dear Yao,
 
According to ITU-T definition, Flex-Grid still belongs to DWDM, however, 
[draft-farrkingel] introduces a new type of Grid. Why you said that 
[draft-farrkingel] has good alignment with ITU-T definition?

 
Thanks
 
Fatai
 
[email-masked]

 

Best regards 
Yao Li 

收件人
[email-masked] 
抄送

主题

Dear Fatai, Adrian, all

Thanks and best regards

Ramon

---

From: Dan Li <[email-masked]>
Date: Wed, 19 Oct 2011 08:39:30 +0800

Right now ITU-T only defines G.694.1/2 which reflects the DWDM and CWDM, and Flex Grid is under DWDM's definition. So I think it may be more clear if we can still keep two categories of the lambda label as defined in RFC6205 already.

Dan

  ----- Original Message ----- 
  From: [email-masked] 
  To: Zhangfatai 
  Cc: [email-masked] 
  Sent: Tuesday, October 18, 2011 6:45 PM
  Subject: Re: [CCAMP] New I-D for Flexi-grid labels

  Hi Fatai: 

     [draft-farrkingel] introduces a new type of Grid. I think this can make it clearer when analyzing the label for fixed usage or flexible. 

  Whereas, introducing of this type of Grid will be communicated to the ITU-T for comment. This draft is an initial version, and will be revised according to the ITU-T discussion. 

  Actually, what I want to say with respect to “[draft-farrkingel] has good alignment with ITU-T definition “is that the slot width parameter m should be carried in the label not in the 
  SENDER_TSPEC or FLOW objects. This has been stated in my last email. 

  Best regards 
  Yao Li   

        Zhangfatai <[email-masked]> 
        2011-10-18 16:57 
       收件人 "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>  
              抄送  
              主题 RE: [CCAMP] New I-D for Flexi-grid labels 

  Dear Yao, 

    
    
  Thanks

  Fatai 

     

  Best regards 
  Yao Li 

              收件人 [email-masked]  
              抄送  
              主题 Re: [CCAMP] New I-D for Flexi-grid labels 

       

  Dear Fatai, Adrian, all

  Thanks and best regards

  Ramon

------------------------------------------------------------------------------

---

From: Zhangfatai <[email-masked]>
Date: Wed, 19 Oct 2011 01:35:33 +0000

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

Sent: 2011年10月18日 17:41

Hi Fatai

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

Best regards

Fei

2011-10-18 17:33

收件人

"[email-masked]" <[email-masked]>, Ramon Casellas <[email-masked]>

抄送

"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

主题

Hi Fei,

Thanks

Fatai

Hi Fatai

Best,

Fei

2011-10-18 16:37

收件人

抄送

主题

Dear Ramon,

<Fei> See above

Thanks

Fatai

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

Dear Fatai, Adrian, all

Thanks and best regards

Ramon

---

From: [email-masked]
Date: Wed, 19 Oct 2011 10:35:31 +0800

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

2011-10-19 09:35

收件人

Hi Fei,

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.

 
Thanks
 
Fatai

Hi Fatai 

Best regards 

Fei 

收件人

Hi Fei, 

  

Thanks

Fatai 

Hi Fatai 

Best, 

Fei 

收件人

抄送

主题

Dear Ramon, 

 

 

 
<Fei> See above 

Thanks 
 
Fatai 

-----Original Message-----
 
Dear Fatai, Adrian, all 

 

 

 

 

 

Thanks and best regards 
 
Ramon

---

From: Zhangfatai <[email-masked]>
Date: Wed, 19 Oct 2011 07:31:39 +0000

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.

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.

Thanks

Fatai

Sent: 2011年10月19日 10:36

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.

Best,

Fei

2011-10-19 09:35

收件人

抄送

主题

Hi Fei,

Thanks

Fatai

Hi Fatai

Best regards

Fei

2011-10-18 17:33

收件人

抄送

主题

Hi Fei,

Thanks

Fatai

Hi Fatai

Best,

Fei

2011-10-18 16:37

收件人

抄送

主题

Dear Ramon,

<Fei> See above

Thanks

Fatai

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

Dear Fatai, Adrian, all

Thanks and best regards

Ramon

---

From: Ramon Casellas <[email-masked]>
Date: Wed, 19 Oct 2011 09:32:43 +0200

El 19/10/2011 9:31, Zhangfatai escribió:
>
> Hi Fei,
>
> 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.
>
> 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.
>

Dear Fatai,

You raise a valid and good point, and I understand your arguments. By 
decoupling the "m" parameter and adding it to the TSPEC, it is easier to 
deduce the spectrum slice to reserve. The mapping TSPEC-FLOWSPEC in 
diret and this does not require the node to be aware of more complex 
details such as the modulation format, FECs, i.e. the  relationship 
between actual data rates (bps) and spectrum (Hz), which, as you know, 
is not a simple mapping.  I could agree to the approach if the WG 
decides it is indeed the best alternative.

However, thinking about your suggested approach, I wonder about 
subsequent questions, which I add here to favor constructive discussion:

- How would a given intermediate LSR update the link status via OSPF-TE 
in what concerns attributes such as unreserved bandwidth per priority 
once a reservation is succesful ?
   Doesn't a node need also (some) of such details ? It is probably too 
early to discuss routing, and it may be that by disseminating a bitmap 
encoded slot status is enough and somehow "obsoletes" bandwidth in terms 
of "bytes / second".
   Note that I don't know either for both approaches :-) and I may just 
be missing something, just wondering wheter the nodes will need more 
information anyway and the simplicity of the approach is lost in the 
sense that, at some point, the mapping Hz <-> bps is needed.

  Another option I have considered when thinking about this is that 
OSPF-TE no longer disseminates unreserved bandwitdh per priority in the 
Link TLV but unreserved spectrum per priority in (Hz) plus 
wavelength/slot availability.

- If the elastic LSP crosses an O/E/O, in which the node uses different 
slot count m1 and m2 for both sides, that would mean that the 
SENDER_TSPEC in the sender descriptor and the FLOWSPEC in the flow 
descriptor need to change at those "regeneration" points. If we agree 
that those objects can be changed (at worst case at every hop), then I 
have no other objection. Note that the same problem would appear if the 
FEC / modulation format is encoded in the TSPEC.

In short, probably an interesting approach to consider, in line with 
what you propose, is that the control plane in an elastic-enabled 
network no longer considers data rates, but manages all resources (at 
routing, path computation and signalling) in terms of optical spectrum,  
that is, TSPEC has m, PCEP is extended to include such TSPEC, OSPF-TE... 
etc  leaving the actual client mapping / adaptation at the edges of the 
network, at the endpoint / transceiver level.

Your comments on this are most welcome,

Thanks and best regards
Ramon

---

From: [email-masked]
Date: Wed, 19 Oct 2011 16:29:12 +0800

Hi Fatai

See in line with <Fei>

Best

Fei

2011-10-19 15:31

收件人

Hi Fei,

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

Hi Fatai 

Best, 

Fei 

收件人

Hi Fei, 

  

  
Thanks

Fatai 

Hi Fatai 

Best regards 

Fei 

收件人

Hi Fei, 

 

Thanks

Fatai 

Hi Fatai 

Best, 

Fei 

收件人

抄送

主题

Dear Ramon, 

<Fei> See above 

Thanks 

Fatai 

-----Original Message-----

Dear Fatai, Adrian, all 

Thanks and best regards 

Ramon