Bonjour Huub,

I'm sorry, I have again a question.

Suppose the mapping of ETH frames in OPU2.

The ETH frames are delineate by GFP (to detect start / end of the ETH frame). Also, GFP convert the ETH traffic from VBR to CBR.

I would say that GFP is synchronous to the ETH frames.

Suppose we have OPU2, then ODU2 and OTU2.

So, we have to adapt the GFP/ETH timing to OPU2/ODU2/OTU2. Can we use GMP for that?

Best regards,
Michelot

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

Bonjour Michelot,

You write:

I'm sorry, I have again a question.

No problem. It is G.709 that causes the issue.

Suppose the mapping of ETH frames in OPU2.

The ETH frames are delineate by GFP (to detect start / end of the ETH
frame). Also, GFP convert the ETH traffic from VBR to CBR.

Correct, GFP does this by inserting idle frames, or idle
characters if it does not receive enough data frames.
So GFP is always faster than the client ETH signal.

I would say that GFP is synchronous to the ETH frames.

No, GFP is synchronous to the OPUk.

Suppose we have OPU2, then ODU2 and OTU2.

So, we have to adapt the GFP/ETH timing to OPU2/ODU2/OTU2.
Can we use GMP for that?

No need for adapting, see above and clause G.709/17.4

Cordialement, Huub.



--
reply to hhelvooort with 2 'o's ================================================================
Always remember that you are unique...just like everyone else...

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

Bonsoir Huub,

Many thanks for the reply.

I have to retain that:

(1) GFP is always faster than the client ETH signal
(2) GFP is synchronous to the OPUk
(3) So, no need for adapting

Cordialement,
Michelot

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