Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Update during the CCAMP call on 2020-07-16
- Loading branch information
Showing
1 changed file
with
30 additions
and
5 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,9 +1,34 @@ | ||
Application Code: An application code represents a standard G.698.2 optical interface specification towards the realization of transversely compatible DWDM systems. Two transceivers supporting the same application code and a line system matching the constraints, defined in ITU-T G.698.2, for that application code will interoperate. | ||
Application Code: An application code represents a standard G.698.2 optical interface | ||
specification towards the realization of transversely compatible DWDM systems. | ||
Two transceivers supporting the same application code and a line system matching the constraints, | ||
defined in ITU-T G.698.2, for that application code will interoperate. | ||
|
||
Organizational Mode: An organizational mode represents a non-standard optical interface specification towards the realization of transversely compatible DWDM systems. Two transceivers supporting the same application code and a line system matching the constraints, defined by the organization which owns the mode, for that organizational will interoperate. These organizations can be MSA-Groups, Operators, System vendors, component vendors etc. | ||
Organizational Mode: An organizational mode represents a non-standard optical interface specification | ||
towards the realization of transversely compatible DWDM systems. Two transceivers supporting the same | ||
organizational mode and a line system matching the constraints, defined by the organization which owns | ||
the mode, for that organizational will interoperate. These organizations can be MSA-Groups, Operators, | ||
System vendors, component vendors etc. | ||
|
||
Interface Mode: An Interface Mode represents an optical interface configuration validated by the system vendors. The if-mode is an identifier for an explicit set of parameters. The if-modes specify the interface configurations only and do not define interoperability requirements. Each interface can support 1 or more if-modes and a single if-mode can support zero, one or more Application Codes and zero, one or more Organizational Modes. | ||
Explicit mode: The explicit mode allows to encode any subset of parameters to enable a controller entity | ||
to check for interoperability by means outside of this draft. It shall be noted that using the explicit | ||
encoding does not guarantee interoperability between two transceivers even in case of identical parameter | ||
definitions. The explicit mode shall therefore be used with care, but it could be useful when no common | ||
Application Codes or Organizational Modes exist or the constraints of common Application Codes or | ||
Organizational Modes cannot be met by the line system. | ||
|
||
Explicit mode: The explicit mode allows to encode any subset of parameters from the if-mode to enable a controller entity to check for interoperability by means outside of this draft. It shall be noted that using the explicit encoding does not guarantee interoperability between two transceivers even in case of identical parameter definitions. The explicit mode shall therefore be used with care, but it could be useful when no common Application Codes or Organizational Modes exist or the constraints of the common Application Codes or Organizational Modes cannot be met by the line system. | ||
Interface Mode: An Interface Mode represents an optical interface configuration. The if-mode is an identifier | ||
for an explicit set of parameters. The if-modes specify the interface configurations only and do not define | ||
interoperability requirements. Each interface can support 1 or more if-modes and a single if-mode can support | ||
zero, one or more Application Codes and zero, one or more Organizational Modes. | ||
|
||
Active-if-mode: The active-if-mode is the if-mode an optical interface is operating. The active-if-mode is a reference to one of the supported if-modes. The optical characteristics of the OTSi generated by the optical interface are defined by the active-if-model and by additional parameters that can be varied such as e.g active frequency. | ||
Active-if-mode: The active-if-mode is the if-mode an optical interface is operating. The active-if-mode is a | ||
reference to one of the supported if-modes. The optical characteristics of the OTSi generated by the optical | ||
interface are defined by the active-if-model and by additional parameters that can be varied such as e.g active frequency. | ||
|
||
Note - The topology model would use only Application Codes, Organizational Modes and Explicit Modes for path computation | ||
and selecting the proper configuration of the transponder. | ||
|
||
Open Issue: need to discuss where the translation between Interface Mode and Application Code/Organizational Mode/Explicit | ||
Mode happens (in the device controller or in the network controller or in the EMF). This impacts the interface YANG model used between the | ||
device and the network controller. The device controller is the controller inside the Network Element, which is exposing the | ||
interface YANG model. The network controller is not necessarily equivalent to the EMF. |