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

[Lou Berger <[e-mail]>]

Ramon,
	Thanks for getting things started.  Keep in mind that you don't have to
have 100% agreement to merge documents.  As part of a merge process, a
document can contain sections with multiple, and even conflicting,
alternatives.  Sometimes during such a process authors will even find
they actually have greater alignment than they at first realize.

Lou

On 3/29/2012 12:57 PM, Ramon Casellas wrote:
> 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
> 
> 
> 
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
> 
> 
> 
>