Bonjour Huub,

I don't feel comfortable with OPUflex(GFP) and ODUflex(GFP).

We can map ETH frames, for example, 2 Gbit/s in the OPUflex(GFP)payload.

I would suppose we have an overhead attached to this payload. What is it?

The OPUflex(GFP) is associated to ODUflex(GFP).

- It seems we don't have an overhead at this step.
- Is ODTU2.3 payload exactly similar to this ODUflex(GFP)?

Cordialement,
Michelot

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bonjour Huub,

I am really sorry to waste your time, the previous post cannot be modified. After writing it, suddendly I found some elements.

I would suppose we have an overhead attached to this payload. What is it?

There is no exemption in the format. The OPUflex and ODUflex formats are same as OPUk and ODUk. Only periodicity differ.

For OPUflex, we can see section 17.4 : mapping of GFP frames into OPUk (k=0,1,2,3,4,flex). The OPUk unities have a general format.

- It seems we don't have an overhead at this step (for ODUflex).

It was my confusion by interpreting the figure 7-5. In fact, the writing of "ODU OH" means "ODUflex OH". Probably there was no sufficient place to note this. Of course, after understanding, we see the relation just below "ODU (ODUflex)"! I have problems
of view.

- Is ODTU2.3 payload exactly similar to this ODUflex(GFP)?

I see that the nominal bandwidth of ODTU2.ts for example is the TS bandwidth in OPU2. The numeric value in table 7-7 is rounded.

On the other hand the value of nominal bandwidth of ODU2.ts is exact, not rounded, a little bit lower than ODTU2.ts.

It is mentionned that this exact value is to easy the clock generation. Have you pleased a word for that.

Thousand forginesses,
cordialement,
Michelot

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bonsoir Michelot,

You wrote:

I am really sorry to waste your time, the previous post cannot be
modified.

Indeed, that is impossible on usenet, even deleting the post is
difficult.

After writing it, suddendly I found some elements.

Very good.

I would suppose we have an overhead attached to this payload. What
is it?

There is no exemption in the format. The OPUflex and ODUflex formats
are same as OPUk and ODUk. Only periodicity differ.

Correct.

For OPUflex, we can see section 17.4 : mapping of GFP frames into
OPUk (k=0,1,2,3,4,flex). The OPUk unities have a general format.

Indeed.

- It seems we don't have an overhead at this step (for ODUflex).

It was my confusion by interpreting the figure 7-5. In fact, the
writing of "ODU OH" means "ODUflex OH". Probably there was no
sufficient place to note this. Of course, after understanding, we see
the relation just below "ODU (ODUflex)"!

Again, correct.

I have problems of view.

No, the figure is not clear.

- Is ODTU2.3 payload exactly similar to this ODUflex(GFP)?

I see that the nominal bandwidth of ODTU2.ts for example is the TS
bandwidth in OPU2. The numeric value in table 7-7 is rounded.

On the other hand the value of nominal bandwidth of ODU2.ts is exact,
not rounded, a little bit lower than ODTU2.ts.

Although it is not mentioned in the table, or note, this
value is also rounded.

It is mentioned that this exact value is to easy the clock
generation. Have you pleased a word for that.

I do not understand how this would make clock generation easier.
The GFP mapping automatically adjusts any clock difference.

Cordialement, Huub.


--
reply to hhelvooort with 2 'o's ================================================================
http://www.van-helvoort.eu/ ================================================================
Always remember that you are unique...just like everyone else...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bonsoir Huub,

Many, many thanks.
Cordialement,
Michelot

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)