Liaison statement
LS/r on Application Codes for Wavelength Switched Optical Networks (reply to IETF-CCAMP-LS014)

ITU-T Q6/15 thanks the CCAMP Working Group of IETF for their Liaison Statement,
dated 16 January 2015.

Q6/15 reviewed in its interim meeting in Berlin, 16-19 March 2015, CCAMP’s
document https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode/ and
the questions raised in the Liaison Statement.

Q6/15 would like to provide the following responses to the various questions:

• Are we capturing current application codes? In other words, are our
references correct and correctly used?
    o Recommendations ITU-T G.698.1, ITU-T G.698.2, ITU-T G.959.1 and ITU-T
    G.695 all are current Recommendations and regularly updated. Note, the
    application spaces for these Recommendations are quite different. ITU-T
    G.698.1 and ITU-T G.698.2 support metro applications over a DWDM network
    (e.g. optical add-drop multiplexers may be present). Whereas, ITU-T G.959.1
    is scoped to a point-to-point configuration and it may not be applicable
    for an optically switched network. o Therefore the answer to CCAMP’s
    question is “YES” with respect to the question if these are current
    application codes. Depending on the intended application scope of WSON, it
    is not clear to Q6/15 if the use is correct.

• Are there any application codes we are missing?
    o Q6/15 assumes CCAMP is referring to additional Recommendations and not
    individual application codes within the above mentioned Recommendations. o
    Q6/15 would suggest that CCAMP looks at other optical interface
    Recommendations like ITU-T G.693 or ITU-T G.698.3 to see if these fit the
    application space of CCAMP’s document.
• Is our set of references correct and have we included all of the application
codes in the references?
    o See response above.
• Have we captured all of the parameters of the application codes?
    o Q6/15 is not aware of any parameters missing.
•  In our attempt to capture the application codes into formats we can use in
our protocols, have we found all of the parameters that comprise the          
application codes?
    o Q6/15 is not aware of any parameters missing.
• Are the fields for each parameter of each application code appropriately
sized and with the correct ranges?
    o Q6/15 feels that these are OK for the current application codes.
    o With respect to the F suffix, which has been encoded as; “F (suffix): = 0
    No FEC Encoding suffix present, = 1 FEC Encoding suffix present”, the
    interpretation “An Optional F can be added indicating a FEC Encoding” is
    not clear. Note, in all of the application codes in question, FEC is not
    optional when it is present in the application code. F, when present in a
    code, indicates “this application requires FEC bytes as specified in [ITU-T
    G.709] to be transmitted.” Therefore, this is not any FEC, but a specific
    FEC code, which in this example is a ITU-T G.709 FEC and it is required to
    be always transmitted. This implies that using an application code
    containing the suffix “F”, the choice of a specific FEC is mandatory and
    that there is no choice in the type of FEC.
• In other words, will we be able to properly encode the application codes
defined today and their possible future extensions?
   o Q6/15 feels that your coding method may not be sufficiently future proof
   to cover possible extensions to existing Recommendations, of which 100G
   phase modulated signals in a future version of ITU-T G.698.2 is an example.
   While at this point Q6/15 does not know which extensions are going to be
   required, it cannot be excluded that a new application code

As Q6/15 further progresses with the work on the revision of its optical
interface Recommendations, we would be happy to inform CCAMP about the progress
made. Q6/15 looks forward to further exchanges of information with CCAMP.