Additional setting attributes for transmission mode description #131
Comments
|
I think we can go with Suggestion (a). |
|
Thank you for the proposal. I have a few questions. Q1. How would the new attribute work together with the existing attribute? For example, FEC-type, which is already defined as TAI_HOST_INTERFACE_ATTR FECT TYPE. I'm personally fine to deprecate TAI_HOST_INTERFACE_ATTR_FEC_TYPE and use the new attribute instead, though. Q2. Can you please elaborate on the values of new attribute? For example, FEC-type returns a string as FEC literal? Or an integer that well-defined/arranged standardized FEC mode? |
I will do this. Thanks. @mikiohr Q1. We should keep the existing attributes. The following is my understanding. FEC type in host interface Q2. There are not so many FEC variations, for now, so we can list the possible FEC types as follows. /** @brief The FEC types */
typedef enum _tai_network_interface_fec_type_t
{
TAI_NETWORK_INTERFACE_FEC_TYPE_UNKNOWN,
TAI_NETWORK_INTERFACE_FEC_TYPE_SC_FEC,
TAI_NETWORK_INTERFACE_FEC_TYPE_CFEC,
TAI_NETWORK_INTERFACE_FEC_TYPE_OFEC,
} tai_network_interface_fec_type_t; |
|
The following table lists the standardized transmission modes that correspond to the existing specifications by OpenROADM [1,2], CableLabs [3,4], ITU-T[5,6,7,8], IEEE[9], and OIF[10]. Note that, each line represents a transmission mode.
In the table, several specifications relate to a single transmission mode because they are equivalent in the context of DSP's operational mode. For example, 100G with SC FEC transmission mode corresponds to OpenROADM, CableLabs, ITU-T, and IEEE specifications. These specifications have the same modulation format, baud rate, symbol mapping, frame format, pilot symbols, etc., and thus are equivalent in the viewpoint of DSP's operational mode. Regarding the transmission mode description, three out of the above four attributes (line rate, modulation format, FEC type, and baud rate) are sufficient to specify the mode uniquely. Since baud rate is, technically speaking, a continuous variable and may be ambiguous, I suggest using line rate, modulation format, and FEC type to specify the transmission mode (please refer to pull request #130). [1] OpenROADM, OpenROADM MSA Specification ver 5.0 https://openroadm.org, 2021 |
|
@toru-mano Thanks a lot for the information. This information is helpful. In #130, you created line rate enums every 100G up to 800G. Some standardization bodies are now thinking 800G, but is anybody thinking 500G, 600G, or 700G? Maybe we should consider making the line rate attribute a continuous variable in this case? ( I'm also considering FlexE + a line rate that is not dividable by 100 here ) I think the realistic approach is to limit the enums only to already standardized modes. ( that means 100G, 200G, 300G, and 400G ) I also think we need a way to add custom enum values to TAI attributes. TAI already supports adding custom attributes to a TAI object. Examples,
When generating metadata of a TAI library, we can include these custom attribute definitions by using https://github.com/Telecominfraproject/oopt-tai/blob/master/meta/Makefile#L7 We need similar support to custom enum values to easily add proprietary values to the TAI attributes. |
|
@toru-mano One more comment. I think we should investigate how the OpenROADM YANG model supports multiple DSP modes. TAI acts as an intermediate between the NOS management system (e.g. YANG) and hardware registers (e.g. C-CMIS). |
|
Few comments about the use of codes to describe compatibility. Application Codes have been used in the past to easily identify and buy modules conforming to a "performance class" like QSFP-100G-LR4 for 10km in a data center. This classification relies on assumptions about the fiber (10km) and defines the minimum requirements that a module must meet to qualify. There are other aspects too. The maximum residual chromatic dispersion for above ITU-T module is 2500 ps/nm, but 9000 ps/nm for OpenROADM (SC-FEC). Both are compatible but only up to 2500ps/nm. This is only one example and looking at OpenROADM there are probably another ~10 parameters that would need to be added to the table. As far as I can tell, very little thought has been spent so far to try to encode 'compatibility' in a reasonable manner. For example https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-dwdm-if-param-yang-05 allows to define a list of identifiers for a set-of-parameters. Other MSA and standards do not. Compare this to the table in #131 (comment). The table also suggests that a given set of parametars (first 4 columns) can be matched with a list of codes (last column). Two Modules that match the same line of the table are compatible with each other under the condition that the limits defined by the labels (=ITU, OpenROADM, ...) are met. E.g. if Transponder A 100G-SC setting claims compatibility with ITU-T and OpenROADM, then it can be paired with another transponder B that claims compatibility to OpenROADM 100G-SC up to a CD of 9000ps/m. However if Transponder B declares compatibility only for ITU (remember these are 6 codes already) then they are compatible under the condition that a residual CD is <2500ps/nm can be met. Note: all this is not primarily a TAI issue, but TAI is affected by the lack of clarity about how to encode compatibility. Going forward my suggestion is to look for a model where:
My 2c |
|
@toru-mano Thank you for updating the proposal. Let me leave a few comments from software implementation point of view, I mean, off-the-shelf or embedded controller point of view. A controller might want to use the proposed attributes like the following:
I'm happy if you clarify the missing and reusable existing attributes/values for capability announcement. |
|
@ggrammel Hi Gert, thanks for your input. In the last TAI workshop, @toru-mano mentioned the necessity of more netif read-only TAI attributes to expose the performance or capability of the transceiver like chromatic dispersion tolerance. This is the first step to add minimum configuration attributes to configure the transceiver. Going forward we can discuss what needs to be added to TAI to cover what is specified in the standards. The IETF draft says
Current TAI also takes the same approach. The different transceivers having the same TAI configuration doesn't mean they have the data plane interoperability. I think we should consider enhancing TAI to support this YANG model. @toru-mano Could you also look into this model as well as the OpenROADM model? |
|
Thank you all for your many comments. I will reply in order. @ishidawataru, Regarding the OpenROADM's DPS modes, AFAIK, the current public YANG model does not yet have an element corresponding to the mode. I think there must be some discussion, and I'm going to check it. @ggrammel, thank you for your insight (I will check the materials you listed). @mikiohr, thank your for the comments on software implementation of controller. I'm a little concerned that every time we add a new attribute for the mode description, we need to update the TAI adapter and controller (TAI adapter host). This will break backward software compatibility. Let's say we add a new attribute @ishidawataru, |
|
@ishidawataru, @mikiohr The point I wanted to highlight is that the view of what is "compatible" is often a little distorted by the closed-system idea that both Transponders need to be exactly the same and has a unique identifier. Both assumptions are misleading. There is also a little issue with the proposal #131 (comment) . There is certainly a need to retrieve possible values and min/max ranges from the TAI adapter. On the sytem it does not identify which combination is allowed. E.g. is a module supporting an SC-FEC in combination with 8-QAM and 28.0 GBaud? My take is that some entity needs to define a number of "templates" for allowed combinations so that an operator can easier identify what to choose. IOW "template" would be pretty much one line in the table. Here the issue is rather where to attach that table. On the host or in the module? |
|
I agree that we need a way to provide "templates" for the allowed configuration combinations and I think the TAI adapter is a good place to hold that information. The template may be implemented as a TAI attribute of the network interface. ( I think we want to support a use case where the TAI adapter host only specifies In order to support this, we may need to distinguish what is explicitly configured by a user and what is decided automatically by the TAI adapter host. ( similar to BTW I opened a PR that adds TAI capability API that might solve some of the issues posted in previous comments. |
|
@ishidawataru the idea to implement a template on the adapter looks good to me in general. The issue is how to configure the template. Option-1 is to embed the template as part of the software which may be doable for stable standards. However any update or addition of templates would require a SW update which is operationally unwelcome. My preference would be to let vendors deliver with a list of supported templates and allow operators to define their own as an add-on. Option-2 would be to distinguish between implementation templates and mode templates. The implementation templates describe what the implemented transponder is able to do and is defined by the implementor, whereby the template is located in the TAI adapter. The mode-templates are held by the network-controller and describe which templates are used for networking and can be defined by the user. It would be up to the network-controller to map a mode template to an implementation template. In other words, this would add another column to the table adding an identifier to the configuration set. That identifier and the set would be held by the TAI host adapter. A network-controller would have a list of operation modes such as e.g. OpenROADM, CableLabs, ITU-T, IEEE which can individually be more restrictive by definition and maps those to the implementation template. In either case, there is the issue how the TAI-Adapter understands which mode options are allowed for a particular module. Option-1 would allow operators that wish to benefit from cost&feature reduction to define their own mode in the adapter (needs YANG extensions) Option-2 doesn't have that possibility and would simply report the parameter set by an implementation and leaves it up to the network-controller to perform the right mapping. |
|
@ggrammel I like the idea of distinguishing implementation templates and mode templates. I think we can make this list ordered by preference of the module. Then TAI adapter host or network controller can map these implementation templates to mode templates.
I think what we want to do is to minimize the additional information that the network controller needs as much as possible.
TAI adapter is basically developed per module. When developing the TAI adapter, the developer should have access to the module and the datasheet of the module to know which modes are supported.
I agree. This is the reason why I want to make the implementation template list ordered by preference. This arrangement can also be used to support backward compatibility. |
|
@ishidawataru For avoiding unnecessary confusion, it might be better to have an explicit preference field or similar in the template entry; I'm not confident that every serialization format in the globe preserves the order of elements in array/map/etc. |
|
@mikiohr I think we can consider adding it at a later point if really needed. TAI is a C interface, that can preserve the order of elements in an array. Out of curiosity, do you know any serialization format that might not preserve the order of elements? |
|
@ishidawataru Fair enough.
In general, map or associated array might not. For simple array/list/vector, hm, I saw a few JSON implementations that broke the order of elements in a past. |
|
I have compiled a list of issues and suggestions (Sub issue 1 to 4) that have been mentioned so far to organize my thoughts. I would appreciate it if you could let me know if there are any omissions or shortcomings. I have also found another issue (Sub issue 5), which I will list here, and like to hear your though. Sub issue 1We need a way to get supported transmission modes (or valid combinations of setting attributes that specify the mode) from the TAI adaptor. Suggestion 1Add an attribute that represents a list of supported transmission modes like below. Sub issue 2Since the TAI adaptor host (or network controller) and TAI adaptor will use different mode descriptions (referred to as implementation templates and mode templates in the above comments), we need a way to translate them. They exist in the different abstraction layers; TAI adaptor operates on hardware registers while adaptor host (or network controller) mainly operates on the abstracted network data model, e.g., Yang model. Suggestion 2Let the TAI adaptor host (or network controller) convert their descriptions (or mode templates) to the TAI adaptor's descriptions (implementation templates). This is because there will be multiple network controllers, and if the TAI adaptor tries to translate descriptions (or templates), it must know all the descriptions used by the network controllers. To support network controller developers, we may provide a table like #131 (comment) explaining which attributes' combinations correspond to the standardized mode. For example, we can provide information like "if you want to use OpenROADM 400G, then use the following parameter combinations." Sub issue 3Due to the lack of information or software compatibility, some controllers may specify only a part of attributes, e.g., only the line rate values. Suggestion 3Define the supported modes (or implementation templates) Sub issue 4We need a way to retrieve parameters like CD dispersion tolerance and receiver OSNR tolerance to provide compatibility or check the optical path feasibility. Suggestion 4Add new read-only attributes to obtain those parameter values. I will make another issue to discuss what kind of parameters are required. To find what parameters should be included, we can consult existing specification materials such as OpenROADM, ITU-T G.698.2, IETF Yang mode, and so on. Sub issue 5 (new one)I have overlooked the OpenZR+[1] specification and found that OpenROADM and OpenZR+ share the line rate, modulation format, and FEC type but use different baud rates. This is because OpenROADM supports both OTN and Ethernet client signals, while OpenZR+ only supports Ethernet signals and uses more straightforward client signal mapping. Since they use different client signal mapping methods, we need to distinguish them.
[1] OpenZR+ Specifications, version 1.0, 4 September 2020, http://openzrplus.org/site/assets/files/1075/openzrplus_1p0.pdf Suggestion 5Add another setting attribute. Possible candidates are the following.
My first thought is client mapping. This is because baud rate is a continuous variable and may be ambiguous, and the name of the standard organization does not directly connect to the transponder's operation. |
|
Regarding the implementation template and TAI capability API, as I understand, currently, there is no good C struct to represent the implementation template, i.e., a combination of attributes. Closest one is Leave it as future work, make an appropriate C struct, or allow the list of the list? Any other possible way or comments? |
|
@toru-mano Thank you for summarizing the discussion.
I agree.
You're right. I think allowing a list of lists in |
|
@toru-mano, Thank you for your great work! I think you address all issues incl. client-signal-mapping and it's time to clean up your draft proposal in the first comment for landing. |
|
@ishidawataru Thank you for your comments. I updated the first comment #131 (comment) to include the transmission mode table and added the column corresponding to the client signal mapping type. So /** @brief The client signal mapping type */
typedef enum _tai_network_interface_client_signal_mapping_type_t
{
TAI_NETWORK_INTERFACE_CLIENT_SIGNAL_MAPPING_TYPE_UNKNOWN,
TAI_NETWORK_INTERFACE_CLIENT_SIGNAL_MAPPING_TYPE_OTU4,
TAI_NETWORK_INTERFACE_CLIENT_SIGNAL_MAPPING_TYPE_FLEXO,
TAI_NETWORK_INTERFACE_CLIENT_SIGNAL_MAPPING_TYPE_ZR,
} tai_network_interface_client_signal_mapping_type_t;I tentatively used the term @mikiohr Thank you for your suggestion. I update the first comment. |
I chose the corresponding specification's title as the client mapping name. That is "OUT4-LR", "FlexO-LR," and "ZR." They correspond to ITU-T G.709.2 "OUT4 long-reach interface", ITU-T G.709.3 "Flexible OTN long-reach interface," and OIF400ZR/OpenZR+. Also, I made a corresponding pull request #137. |
|
@ishidawataru Thank you for the comments. I'm thinking of adding an attribute that represents implementation templates (or supported transmission modes).
I took a look at the memory allocation code. I agree that extending it to include custom attributes, etc., would make the code more complex. I thought it would be better to avoid making such complex changes just for transmission modes. I also took a look at the capability API and felt that this API is more natural to be called on create-and-set attributes. On the other hand, the implementation template is a read-only attribute. So, for example, how about simply expressing the supported transmission modes as follows? The implementation template(s) is a list of templates. Each template is represented as a list of enum values (not So attribute looks like below. /**
* @brief The list of implementation templates
*
* @type #tai_attr_value_list_t #tai_s32_list_t
* @flags READ_ONLY
*/
TAI_NETWORK_INTERFACE_ATTR_IMPLEMENTATION_TEMPLATES,We can specify the implementation tempaltes in C as follows (We may need some padding depending on the memory allocation). const int templates[][4] = {
{TAI_NETWORK_INTERFACE_LINE_RATE_100G, TAI_NETWORK_INTERFACE_MODULATION_FORMAT_DP_QPSK,
TAI_NETWORK_INTERFACE_FEC_TYPE_SC_FEC, TAI_NETWORK_INTERFACE_CLIENT_SIGNAL_MAPPING_TYPE_OTU4_LR},
{TAI_NETWORK_INTERFACE_LINE_RATE_200G, TAI_NETWORK_INTERFACE_MODULATION_FORMAT_DP_QPSK,
TAI_NETWORK_INTERFACE_FEC_TYPE_OFEC, TAI_NETWORK_INTERFACE_CLIENT_SIGNAL_MAPPING_TYPE_FLEXO_LR},
{TAI_NETWORK_INTERFACE_LINE_RATE_400G, TAI_NETWORK_INTERFACE_MODULATION_FORMAT_DP_16_QAM,
TAI_NETWORK_INTERFACE_FEC_TYPE_CFEC, TAI_NETWORK_INTERFACE_CLIENT_SIGNAL_MAPPING_TYPE_ZR},
};In this method, the order is critical. The first value must be line rate, and the second value must be modulation format and so on. So we should explicitly state the relationship between the order and attribute (maybe in the header file). One way to remove this restriction is making a new C struct that can hold list of |
|
@toru-mano I think it's not that difficult to support attr-list of attr-list if we put the following restriction.
It may look over-engineering to do this just for transmission modes. However, I want to take this approach to support adding custom attributes to this list. TAI adapter may want to add its custom attributes to this list to return modes that can't be expressed with the official attributes. Using
I feel the complexity of doing this is almost equal to enhancing |
|
@toru-mano After thinking more, I realized that supporting internal // taitypes.h
typedef struct _tai_enum_list_t {
tai_attr_id_t id;
uint32_t count;
int32_t *list
} tai_enum_list_t;
typedef union _tai_attribute_value_t {
...
tai_enum_list_t enum_list;
} tai_attribute_value_t;
//tainetworkif.h
typedef enum _tai_network_interface_attr_t
{
...
// @type #tai_attr_value_list_t #tai_enum_list_t
// @flags READ_ONLY
TAI_NETWORK_INTERFACE_ATTR_IMPLEMENTATION_TEMPLATES,
} tai_network_interface_attr_t; |
|
@ishidawataru I overlooked the importance of supporting custom attributes or proprietary transmission modes and now understand your intention. I will play the devil's advocate. Another possible implementation is the following (if current meta and other libraries support types such as // taitypes.h
// Tuple of enum id and its value
typedef struct _tai_enum_tuple_t {
tai_attr_id_t id;
tai_int32_t s32;
} tai_enum_tuple_t;
typedef struct _tai_enum_tuple_list_t {
uint32_t count;
tai_enum_tuple_t *list
} tai_enum_tuple_list_t;
typedef union _tai_attribute_value_t {
...
tai_enum_list_t enum_tuple_list;
} tai_attribute_value_t;
//tainetworkif.h
typedef enum _tai_network_interface_attr_t
{
...
// @type #tai_attr_value_list_t #tai_enum_tuple_list_t
// @flags READ_ONLY
TAI_NETWORK_INTERFACE_ATTR_IMPLEMENTATION_TEMPLATES,
} tai_network_interface_attr_t;This implementation is closer to the original presentation, that is, a list of combinations of attributes. However, it is slightly tricky to parse the structure since the order may be inconsistent, and each length may be different. I think both are OK, but |
|
@ishidawataru After reviewing both codes, I preferred |
|
@toru-mano Thank you. As commented in #138, I'd like to actually implement this in our TAI implementations to see the validity of the proposal before merging. BTW, I just added custom enum value support to metadata generation code. #139 |
This issue suggests adding new setting attributes for transmission mode description enhancement.
Transmission modes and their descriptions
This issue defines a transmission mode as a transponder's operational mode corresponding to an optical interface specification (e.g., OpenROADM 400G) such as OpenROADM, CableLabs, ITU-T, IEEE, and OIF specification.
A transmission mode specifies the transponder's parameters, including line rate, modulation format, FEC type, etc. To configure the transponder properly, we have to uniquely describe and specify a transmission mode because a transponder may support multiple transmission modes.
An issue on mode description
Currently, we specify a transmission mode with host interface signal rate
TAI_HOST_INTERFACE_ATTR_SIGNAL_RATEand network interface modulation formatTAI_NETWORK_INTERFACE_ATTR_MODULATION_FORMAT, and other configuration parameters are automatically selected. However, we have two different standardized transmission modes, OpenROADM 400G[1] and OIF 400ZR[10], that have the same signal rate and modulation format. To distinguish them, we need to use custom attributes.Standardized transmission modes
The following table lists the standardized transmission modes that correspond to the existing specifications by OpenROADM [1,2], CableLabs [3,4], ITU-T[5,6,7,8], IEEE[9], OIF[10], OpenZR+[11]. Note that, each line represents a transmission mode.
In the table, several specifications relate to a single transmission mode because they are equivalent in the context of DSP's operational mode. For example, 100G with SC FEC transmission mode corresponds to OpenROADM, CableLabs, ITU-T, and IEEE specifications. These specifications have the same modulation format, baud rate, symbol mapping, frame format, pilot symbols, etc., and thus are equivalent in the viewpoint of DSP's operational mode.
The client mapping name corresponds to the title of the corresponding specification title. That is, "OTU4-LR" refers to the client signal mapping method described in ITU-T G.709.2 "OUT4 long-reach interface." "FlexO-LR" refers to the client signal mapping method described in ITU-T G.709.3 "Flexible OTN long-reach interface." "ZR" refers to OIF 400ZR and OpenZR+.
A suggestion to resolving the issue
General idea
DPSs internally have transmission mode descriptions, but different DSPs use different descriptions. This issue suggests hiding such vendor-specific descriptions and providing a common method, or standard-setting attributes, to describe transmission modes.
Description by attributes combination
This suggestion adds new setting attributes and specifies a transmission mode as a combination of attributes.
The following is an example code.
In this example, we will specify a transmission mode as a combination of
TAI_NETWORK_INTERFACE_ATTR_LINE_RATE,TAI_NETWORK_INTERFACE_ATTR_MODULATION_FORMAT,TAI_NETWORK_INTERFACE_ATTR_FEC_TYPE,TAI_NETWORK_INTERFACE_ATTR_CLIENT_MAPPING.Related sub-issues
This section summarizes related sub-issues to deal with transponders that support multiple transmission modes.
(These sub-issues and suggestions have been discussed so far in this issue. I will update if needed)
Sub-issue 1
We need a way to get supported transmission modes (or valid combinations of setting attributes that specify the mode) from the TAI adaptor.
Suggestion 1
Add an attribute that represents a list of supported transmission modes like below.
Unfortunately, there is no good C struct to represent the implementation template. One possible way is allowing a list of lists in
tai_attr_value_list_tto represent the implementation template.Sub-issue 2
Since the TAI adaptor host (or network controller) and TAI adaptor will use different mode descriptions (referred to as implementation templates and mode templates in the comment #131 (comment)), we need a way to translate them. They exist in the different abstraction layers; TAI adaptor operates on hardware registers while adaptor host (or network controller) mainly operates on the abstracted network data model, e.g., Yang model.
Suggestion 2
Let the TAI adaptor host (or network controller) convert their descriptions (or mode templates) to the TAI adaptor's descriptions (implementation templates). This is because there will be multiple network controllers, and if the TAI adaptor tries to translate descriptions (or templates), it must know all the descriptions used by the network controllers.
To support network controller developers, we may provide a table like #131 (comment) explaining which attributes' combinations correspond to the standardized mode. For example, we can provide information like "if you want to use OpenROADM 400G, then use the following parameter combinations."
Sub-issue 3
Due to the lack of information or software compatibility, some controllers may specify only a part of attributes, e.g., only the line rate values.
Suggestion 3
Define the supported modes (or implementation templates)
TAI_NETWORK_INTERFACE_ATTR_IMPLEMENTATION_TEMPLATESas an ordered list as in sub-issue 1 and use the first template that matches the given attribute values.Sub-issue 4
We need a way to retrieve parameters like CD tolerance and receiver OSNR tolerance to provide compatibility or check the optical path feasibility.
Suggestion 4
Add new read-only attributes to obtain those parameter values. I will make another issue to discuss what kind of parameters are required. To find what parameters should be included, we can consult existing specification materials such as OpenROADM, ITU-T G.698.2, IETF Yang mode, and so on.
References
[1] OpenROADM, OpenROADM MSA Specification ver 5.0 https://openroadm.org, 2021
[2] OpenROADM, OpenROADM MSA 5.0 W-Port Digital Specification https://openroadm.org, 2021
[3] CableLabs, P2P Coherent Optics Physical Layer 1.0 Specification https://www.cablelabs.com/specifications, 2020
[4] CableLabs, Physical Layer 2.0 Specification https://www.cablelabs.com/specifications, 2020
[5] ITU-T, G.709/Y.1331 Interfaces for the optical transport network, 2020
[6] ITU-T, G.709.1/Y.1331.1 Flexible OTN short-reach interfaces, 2020
[7] ITU-T, G.709.2/Y.1331.2 OTU4 long-reach interface, 2018
[8] ITU-T, G.709.3/Y.1331.3 Flexible OTN long-reach interfaces, 2020
[9] IEEE802.3ct-2021, IEEE Standard for Ethernet Amendment 13:Physical Layers and Management Parameters for 100 Gb/s Operation over DWDM Systems, 2021
[10] OIF, Implementation Agreement 400ZR, 2020
[11] OpenZR+ Specifications, version 1.0, 4 September 2020, http://openzrplus.org/site/assets/files/1075/openzrplus_1p0.pdf
The text was updated successfully, but these errors were encountered: