Hi all,
Ahead of the meeting in the morning, I would like to clarify/simplify a few things – highlighted when considering an implementation. As of today we have the specification allows for 256 (de)mappers and each can feed/receive from any of
up to 256 ports. Problem statement: From an implication perspective this is unrealistic that 2^16 mappers would be allowed. What is proposed is that a maximum of 256 (de)mappers. The following clarification is proposed.
·
A maximum of 256 (de)mappers are provided for, likewise, a maximum of 256 (de)packetizers are provided for
o
Clearly additional mappers could be supported though multiple RoE instances
·
The ratio of (de) mappers / (de)packetizers is 1:1
·
(de)mappers / (de)packetizers should be merged into one entity. (de)Mapper.
·
A (de)mapper would then have a single input port and single output port.
·
A given implementation should call out how many of which particular (de)mappers – and types, are supported
·
The new hierarchy diagram would look something like this (see below)
·
A (de)packer can be associated with any (but only one) Ethernet link (a single ethID)
·
A CPRI port can be associated with any mapper (but only one) (CPRI) link (a single cpriID)
·
In the case of transmission, a mapper has a unique (instance name) flowID. flowID=mapperID. (redundancy here)
·
In the case of reception, the RoE instance must translate from a logically received flowID into a physical fDepackID instance (flowID/=fDepackID)
·
m,p,n,q are a single value between 0-255.
·
mapperType is enumerated as [0,1,2,3] as [tunneling, agnostic, aware & native]
In summary, from a DL perspective, a mapper has an input from a single IQ (CPRI) port. This mapper extracts the containers defined for this mapper’s containers and packetizes the data and control for a single output port with a unique flowID
and routes it to a particular Ethernet link (ethID).
From a UL perspective, a single ethID link provides data and control from a given flowID. The received flowID is translated to the RoE’s fDepackID space, depacketized and then pushed into the appropriate IQ (cpriID) link & container.
Additional proposal: since there is a 1:1 relationship between (de)packetizers and (de)mappers, the two entities should be merged as a single entity each with a single input and output bus.
Thanks,
Richard
Richard Maiden
ALTERA (an Intel Company)
101 Innovation Drive
San Jose, CA 95134
Tel: +1 (949) 382-5402