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

[Giovanni Martinelli <[e-mail]>]

I know there was a sort of sub-ccamp meeting and probably results will 
circulate soon but I'd love to share my personal opinion here as well 
... (since not so much time left for mic during wg meeting).

- as someone is going to merge frameworks I would probably try not to 
rewrite wson framework with just some replacements (s/wson/sson/ or 
s/rwa/rsa/). As heard from someone I agree there's need of common 
understanding and terminology but I would lean toward  not rewrite what 
already in ITU doc (apart from what needed for quick understanding).

- On the same line I would probably echo Adrian message on the this list 
few weeks back and focus in getting first some foundations (e.g. label).

Cheers
G



On 3/29/12 13:42 , Lou Berger wrote:
> 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
>>
>>
>>
>>
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp