Re: [CCAMP] Flexible Grids Presentations at the next IETF

[Ramon Casellas <[e-mail]>]

On 03/29/2012 11:10 AM, BRUNGARD, DEBORAH A wrote:
> All,
>          As discussed in yesterday's session, we are looking for the authors of
> the flexible grid related drafts to work on merging like drafts.  We are
> hopeful that we will be discussing the merged requirements/framework,
> routing, signaling, and LMP drafts at the next meeting.  If such merging
> does not occur before the next meeting, we (the chairs) will most likely
> use the session time to discuss issues preventing such merging and not
> schedule any individual presentations on the topic.
>


Dear Deborah, flexi-grid drafts (co)-authors, all

Following WG chairs suggestion and in order to move forward / integrate 
drafts, please find below (my own) summary of open issues / draft 
differences and possible choices.

Sorry for the length of the mail. Please, feel free to correct/add or 
comment. The list reflects in part my views and comments in past emails 
and private conversations, and mistakes are my own

Of course, stated for the gazillion-th, everything is conditioned by  
ITU-T data plane :-) -- which will definitely impact some of the points 
below, notably I and I-B)

that said:



I) Are non-contiguous frequency slots in scope?
===============================

a) No, we should focus on the  use case of having a contiguous frequency 
slot, defined by n and m.

b) Yes, it should be integral part of the data plane model

c) Yes, but it can be done using virtual concatenation (even at a later 
stage, when I.a is mature)

d) A new framework of multi-channel  (not in the sense of optical 
modulation formats) should be defined, generically (Igor?)

afaik 2 fwk drafts assume I.a and potentially I.c // 1 fwk draft assumes b



I-B) Optical Conversion
================

*) Does an LSP start and end at a given trail termination? is the 
equivalent of wavelength conversion (spectrum conversion) considered?

*) Does an LSP span O/E/O conversions or only transparent segments?

afaik, current drafts assume an LSP may span O/E/O


II) Switching capability Layer / Region
=========================

a) SSON as evolution of WSON, same LSC

      - an extension of WSON allowing heterogeneous requests

      - backwards compatibility with WSON? Interworking?

      - Potential problems with the max LSP bw per prio in the iscd (see 
routing)

      - Potential problems with having the same swcap but the label 
format changes w.r.t. wson (for some definitions of label encoding / format)

      - Will reuse a lot of work / procedures / encodings defined in the 
context of wson


b) A new SwCap may need to be defined

       - LSC swcap already defined ISCD which can not be modified

       - It may be problematic to have a the same swcap but different 
label formats. Role of LSP encoding type?

       - This may be necessary depending on the retained data plane model


* Notion of hierarchy?

        - There is no notion of hierarchy between WSON  and flexi-grid / 
SSON - only interop / interwork




III) Label format (see also V)
=========================

a) Assuming a data plane model I.a) "m" (the parameter that defines the 
slot width, as in m*12.5 GHz) "m" is inherent part of the label

            - It is part of the switching

            - It allows encode the "lightpath" in a ERO using Explicit 
Label Control

            - Still maintains that feature a cross-connect is defined by 
the tuple (port-in, label-in, port-out, label-out), allows a kind-of 
"best effort LSP"



b) Assuming a data plane model I.a) "m" is not part of the label but of 
the TSPEC

            - Needs to be in the TSPEC to decouple client signal traffic 
specification and management of the optical spectrum

            - Does not need to be in the label, since it is carried in 
the TSPEC / flowdescriptor flowspec. Having in both places is redundant 
and open to incoherences, extra error checking

            - Does not need to be in the label, it is in the TSPEC and 
for OTN it was decided to remove tspec-related params out of the label


c) Assuming a data plane model I.a) "m" is both path of the label and 
the TSPEC

            - It reflects both the concept of resource request / 
allocation / reservation and the concept of being inherent part of the 
switching


d) Different label format, since the data plane model is different  
(I.b, I.d)




IV) Requirements/Framework documents
==========================

*) Two of the framework drafts are quite similar, based on I.a) - main 
difference is  III.a) and III.b)

      - they could be merged if a final decision on the label format was 
made (also merged stating the different options, as Lou said)


  *) Point raised regarding the multi-carrier / single-carrier questions 
(as optical modulation formats)

      - Yes,  both: the management of the optical spectrum (once the 
"frequency range" or "m" is allocated) should not imply whether we 
consider only single carrier or multi carrier. As long as the client 
singal uses the allocated frequency slot whether the transceiver uses a 
single carrier (i.e. qam) or multi-carrier (o-ofdm) are both covered

      - No,  only single carrier



V) Signalling / RSVP-TE
==========================

* At least two signaling drafts could be aligned once we have a common 
definition of a label (III,a,b,c)


* Open issue with Sender Descriptor SENDER_TSPEC and flow descriptor 
FLOWSPEC:

a) should contain "m" - this decouples client signal data rates, 
modulation, fec, etc. from the optical spectrum management

b) having "m" in the tspec is problematic in the case of O/E/O - 
wavelength / spectrum converters since it can imply that m changes along 
the path
     (could be a problem or not, there is also the ADSPEC)

c) client signal tspec (e.g. intserv token bucket tspec) should/could be 
"piggybacked" in the tspec that carries "m"

d) It is not clear whether the "span" of an LSP should cover O/E/O 
elements, (trail termination) thus even if all-optical conversion is 
deployed TSPEC will not change

e) for data rates 40/100/400 Gbps with advanced modulation formats 
(coherent O-OFDM, polmux, etc) all optical conversion may not be ready 
in a near future?



Routing
==========================

*) Routing "Labels"

a) having the label format III.b) unifies "signaling labels" and 
"routing labels"

b) routing "label format" and "signaling label format" may be different

c) There is no such thing as "routing labels": A path computation entity 
(being an ingress, intermediate node or a PCE) basically needs (other 
than ROADMs and transceivers capabilities and limitations) a TE link 
characterization by means of the knowledge the status and availability 
of central (nominal) frequencies (n parameters) in the operating band. 
It happens that in WSON, labels uniquely identify wavelengths, but this 
may not be the case in SSON. In other words, disseminating labels in 
WSON is a "short hand" for disseminating wavelength identifiers, but the 
same idea does not need to apply in SSON: the requirement of knowing the 
central frequencies does not map to knowing the labels, except for some 
of the proposed label formats. In order to disseminate the status of 
central frequencies, efficient encodings may use a combination of bitmap 
encoding or "group" them. This is where the use of something like "m" to 
convey a "range" may be beneficial, but this is only from the point of 
view of encoding (labelsets)


* Max LSP bandwidth per prio / unresv b per prio

      - At data rates of GBps / TBps, encoding bandwidths with bytes per 
second unit and IEEE 32-bit floating may be problematic / non scalable. 
Potential problems in CSPF may

      - This field is not relevant since there is not a 1-to-1 mapping 
between bps and Hz, since it depends on the modulation format, fec, 
either there is an agreement on assuming best / worst case modulations 
and spectral efficiency.



Hope this helps

Ramon