Re: Flexible OTN / fractional 100GbE

["Mitcheltree, Harold B" <pete () ots utsystem edu>]

https://www.ekinops.com/products/flexrate-modules/aggregation-and-encryption-modules/pm-100g-agg


--Pete

PM 100G-AGG | Ekinops<https://www.ekinops.com/products/flexrate-modules/aggregation-and-encryption-modules/pm-100g-agg>
www.ekinops.com
100G aggregation module The EKINOPS PM 100G-AGG is a multiprotocol aggregation module that allows network operators to 
deliver a wide range of connectivity and managed services. Designed as a companio...



________________________________
From: NANOG <nanog-bounces () nanog org> on behalf of Brandon Martin <lists.nanog () monmotha net>
Sent: Wednesday, May 29, 2019 1:24:05 PM
To: nanog () nanog org
Subject: Re: Flexible OTN / fractional 100GbE

On 5/28/19 11:12 AM, Jérôme Nicolle wrote:
> OTN is important for this project because we'd need many of its features
> in terms of FEC, monitoring and low jitter.

Correct me if I'm wrong, but wouldn't "fractional" Ethernet services
require packet switching with corresponding jitter anyway?  It would be
1:1 switching which would keep the latency low, but you can't e.g. offer
a 60Gbps bandwidth on 100GbE handoff and just put that straight on OTN.
   You'd have to either packet switch (and queue due to the incoming
line rate being slower than the outgoing) it onto a FlexODU using GFP-F
at 60Gbps (I'm not sure if anything even supports this) or just take the
100GbE staight onto OTN at 100Gbps.

Now, you could obviously put two native 40GbE services onto a single
OTU-4 (along with a couple 10Gbps or single 20Gbps packet service)
without packet switching by just framing up both Ethernet services using
your choice of GFP-F or GFP-T, and it could be done without queuing
since the incoming and outgoing line rates are the same.

The former would probably still end up being better than straight
switched Ethernet, but it won't be the same as a straight re-framed
Ethernet signal on OTN.

FEC and enhanced monitoring are always nice, though.
--
Brandon Martin
> > This message is from an external sender. Learn more about why this <<
> > matters at https://links.utexas.edu/rtyclf.                        <<