LS/r on Application Codes for Wavelength Switched Optical Networks (reply to IETF-CCAMP-LS014)
|From Contact||Greg Jones|
|Liaisons referred by this one||
Application Codes for Wavelength Switched Optical Networks
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.