openconfig/public

Media channel of wavelength router

Djib84 opened this issue · 6 comments

Djib84 commented

While reviewing the Yang file of the wavelength-router, I'm having some difficulty understanding the granularity of a media channel. For instance, if we consider a degree 2 ROADM (LINE 1 and LINE 2) consisting of a transponder, a coupler, a WSS card, and two line WSS cards (see attached diagram). My question is: if we want to represent a transmission between the input of the coupler (PE) and the output of WSS line L1 (PS1), should a single media channel be defined between these two ports even if there are multiple cards? Or should a media channel be represented for each card encountered between the coupler and WSS LINE 1?

Thank you in advance for your feedback

MC

ejbrever commented

I think it would depend on the boundaries of the device that is being managed. If a single device contains multiple WSS's, then I'd expect a single media channel. Essentially I've seen the media channels map 1:1 with how media channels (a.k.a. crossconnects) are configured on a given device natively. In theory, a media channel generically connects two ports together, so if there was an implementation that supported the extra granularity to configure every WSS, then the model could support it, but I'm not sure that provides much value.

The connectivity model usually also comes into play here as if a device contains many WSS's, amplifiers, etc, the device might first require that it understands how things are physically connected so that it can open spectrum appropriately across the mulitple WSS's.

I should also note media channels are unidirectional, so there'd be a single media channel for the arrow drawn, however, in practice, there would almost for sure be a second media channel in the reverse direction.

Djib84 commented

Thank you for your feedback, it's much clearer to me now.

Best regards

ejbrever commented

Great thanks.

Djib84 commented

Thank you again for your feedback, but I have additional questions regarding media channel configuration. Therefore, i am reopening this issue to maintain the continuity of my inquiries. I apologize if this does not follow the usual process.

My additional questions are as follows (with the associated schema below):

  • In the representation, Transponder, coupler, WSS, WSS Line 1, WSS Line 2 are platform components (Line Cards)
  • Line Cards contain ports components.
  • Ports components of line cards are connected through transport-line-connectivity (intra and extra card)
    We understood that the wavelength router manages a set of ADD/DROP/INGRESS/EGRESS ports

  1. Does it mean that the ports eligible to media channel setting must be defined as optical ports with type ADD, DROP, INGRESS, EGRESS ? And is it sufficient ?

  2. Can we declare all ports at boundaries of our ROADM system as ADD/DROP/INGRESS/EGRESS ports (see fig 1), even if they are not belonging to the same line card ?

  3. When the SDN orchestrator wants to setup a media channel, does it check that both chosen ports are “connectable” ? Must these ports be directly linked through one transport-line-connectivity or can they be indirectly linked through several transport-line-connectivities (see fig 1) ?

  4. We understood that amplifier ports were also defined as INGRESS/EGRESS ports. In that case, how does SDN orchestrator manage to distinguish ports of the ROADM (eligible for media-channel setting) and ports of amplifiers?

image

ejbrever commented

No problem, here are my thoughts on the questions:

  1. In many (all?) implementations I believe that would be how things work. However, there are no hard restrictions and a device implementation could approach this differently. For example, if an implementation allowed configuring the WSS block in your diagram explicitly. I haven't seen an implementation like that, but the model doesn't prevent it.

  2. That seems reasonable to do. There is nothing to say those types cannot be used elsewhere though. For example, if you had two stages of amplifiers with two cards, there would likely be an INGRESS port on each of those cards even though only one is on the boundary of the ROADM.

  3. The implementations I've seen support cascaded connections that could traverse through multiple connections (i.e. Raman -> EDFA -> WSS). As for the SDN orchestration, that is a different layer from OpenConfig, but it certainly seems like a good type of validation to do there :)

  4. How the SDN orchestration works is a little outside the scope of OpenConfig, but port eligibility for a media channel isn't a "hard coded" attribute anywhere (perhaps its something to add if you are interested in proposing). In my experience we've had to work with the vendors to understand their implementation. At least at my company this ties heavily into a general philosophy though. We don't query live devices in the field and then figure out what the configuration should look like. The reality is we design quarters (and even years) in advance. As a result we have an approach where our design systems have to understand this detail long before a device is ever in the field. This is because we purchase gear for specific capacity. At least in the optical space that's been how I understand most operators have to approach this as well.

Djib84 commented

Thank you very much for your answer.

Best regards