Telecominfraproject / oopt-tai

TIP OOPT - Transponder Abstraction Interface
BSD 3-Clause "New" or "Revised" License
45 stars 30 forks source link

Move frequency related attributes to network interface attribute #13

Closed ishidawataru closed 6 years ago

ishidawataru commented 6 years ago

https://github.com/Telecominfraproject/oopt-tai/blob/master/inc/taimodule.h#L152-L185

I think we should move these attributes as network interface attribute. My understanding is that a network interface represents one optical device which transports one lambda. In this case, if we have several network interfaces inside one module, each network interface has its own min/max laser frequency.

@scott-emery WDYT?

scott-emery commented 6 years ago

These values come from the CFP_MSA's CFP NVR 4 register page. See page 81 of http://www.cfp-msa.org/Documents/CFP_MSA_MIS_V2p6r06a.pdf. While these attributes are listed for the module, not individual network interfaces, I don't see any problem moving them to the network interface object.

Most implementations will simply report the same values for all network interfaces. But if there is, in the future, a module which supports multiple network interfaces with different capabilities, TAI will be able to handle it.

ishidawataru commented 6 years ago

I think we need a more concrete definition for module and network interface.

In Cassini case, I tend to think module represents plug-in-unit and network-interface represents CFP2 transceiver. In this case, it is more natural to put CFP MSA attributes into network-interface.

Also, we could think about a plug-in-unit which has two CFP2 cage. In this case, we can insert transceivers with different capabilities.

scott-emery commented 6 years ago

When working with a module with a single network interface it is sometimes difficult to separate what is a property of the network interface and what is a property of the module. Cassisni complicates things even more, because it has plug-in modules which accept plug-in modules.

For the DCO modules, I would say a TAI module is the CFP2 module. Since most of these modules have a single network interface it is difficult to distinguish between a module attribute and a network interface attribute. It might help to refer to the CFP MSA MIS. There are attributes which was global, and there are attributes which are "arrays", one element for each network interface.

For the ACO modules the boundary is not quite as clear, since the DSP is external to the CFP2 module. In this case, I would say that the TAI module is the combination of the CFP2 module and the DSP. Again, it is easiest to understand what is a network interface attribute vs. a module attribute if you refer to a module which has multiple network interfaces.

ishidawataru commented 6 years ago

it is sometimes difficult to separate what is a property of the network interface and what is a property of the module

What do you think is the benefit to have two notions, module and network interface? If it is unclear how to split two things, I think we can merge these into one.

How about putting everything related to emitting one lambda ( laser + 1ch of DSP ) into one network interface like below?

module network interface host interface
AC400 1 2 = ( 1 Tunable Laser + 1 Channel of DSP ) * 2 4
Cassini DCO PIU 1 1 = CFP2DCO 2
Cassini ACO PIU 1 1 = CFP2ACO + DSP 2

I'm thinking about putting every attributes related to tributary (netif, hostif mapping) into module attribute.

scott-emery commented 6 years ago

What do you think is the benefit to have two notions, module and network interface?

There really are some attributes which are specific to the module. For example, the temperature. No matter how many network interfaces exist, the module has a temperature, and that is a property of the module, not the network interface. The serial number is another good example of a module attribute.

How about putting everything related to emitting one lambda ( laser + 1ch of DSP ) into one network interface like below?

That sounds perfect!

dileepbk commented 6 years ago

@ishidawataru

Also, we could think about a plug-in-unit which has two CFP2 cage. In this case, we can insert transceivers with different capabilities. This means we need to add Optical Channel. For AC400 there will be two Optical Channel, but one Network Interface. In future, when more than one CFP2 cage are supported in a module, then Network Interface count will be more than one. Now it will be set to 1.

ishidawataru commented 6 years ago

@dileepbk

This means we need to add Optical Channel.

I was thinking about adding one more object like optical channel but not for supporting PIU with two CFP2 cages.

I think module and network interface object is enough to represent PIU with two CFP2 cages.

PIU = module, CFP2 = network interface

Same for AC400.

AC400 = module, pair of one laser and one channel of DSP = network interface

dileepbk commented 6 years ago

I think module and network interface object is enough to represent PIU with two CFP2 cages. Agreed, that Network Interface Object will represent CFP2 cages. How are we representing the dual-channel of AC400 ? If with Network Interface Object, then fine.
In future, for Dual CFP2 and Dual-Channel, the two tier does not work. Then need to add Optical Channel AC200 does not have this feature.

ishidawataru commented 6 years ago

Agreed, that Network Interface Object will represent CFP2 cages.

Not necessarily.

Please see the table in https://github.com/Telecominfraproject/oopt-tai/issues/13#issuecomment-401180344

As for Cassini ACO module

network interface = CFP2ACO + DSP

In future, for Dual CFP2 and Dual-Channel, the two tier does not work.

In this case, we would have two network interfaces. Each network interface represents one CFP2 and one channel.

BTW you need one line space to make indentation work properly :)