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

[[e-mail]]

Hi Giovanni:
 
Thanks for your suggestions.
 
As you said, one way to move the flexi-grid forward may start from label 
encoding.
After the label is done, we can start signaling and routing extensions.

To make this clearer, we may take the RFC6205 (the wavelength label)
for an example. As we see, the time when the wavelength label become a 
working group
document (May, 2008) is earlier than that of the WSON framework doc 
(December 5, 2008). 
It is the same order when these two docs become RFC standards. So when we 
work on flexi-grid, we may
do as this sequence.

Besides, the flexi-grid label is keeping aline with G.694.1 V1.6 which has 
been exactly defined. 
While, some technologies illustrated in some flexi-grid framwork documents 
are not well defined in ITU-T. It may 
take a long time before everyone to reach a consensus. 


BR
Yao 


> [e-mail] 写于 2012-04-03 04:50:19:
> 
> > 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 theiscd 
(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-carrierquestions
> > >> (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 
withbytes 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
> > _______________________________________________
> > CCAMP mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ccamp
> >