All,
The use cases that came out of last meeting show various example deployments and starts to nail down the RoE-functionality.
I find it equally important to explicitly state the assumptions made on the underlying Ethernet network.
No good to design an RoE-function that doesn’t have a network to support it (and vice versa).
Examples:
• What are the networking tools supposed to be used (such as 1588, SyncE, “not” GNSS, 802.1Q or TSN?, etc.)
[Jouni Korhonen]
We’ll assume we got time, sync and a working clock distribution in place. We are not going to state which one. We can at most give a guidance which tools are desirable. The same goes for the rest as well. .1Q is a safe assumption but not all deployments have to rely on its presence.
• What are the parametric requirements of the network (we can start out with qualitative statements)
[Jouni Korhonen]
Give an example what parametric requirements you are after.
• The use case ppt shows one switch here and there – is that the limit? How flexible does the network have to be? What is the delay limit and how is/can this be budgeted?
[Jouni Korhonen]
We do not state a limit for the number of switches.. that will vary & evolve anyway. The delay budget depends on what has been allocated for the front-haul in general (e.g. in CPRI case ~100us one way). How you divide that between nodes on the path is not imho for us to define.
• Is this a peering or overlay arrangement ? I mean, do we foresee that RoE frames are somehow processed (e.g. monitored) on the path, or is the path completely transparent? The answer to this may impact the type/size of time stamp used.
[Jouni Korhonen]
Good question. I do not have an answer right now.
- Jouni
Thanks,
Lars
(Lars Ellegaard, Princ. Eng,
Vitesse Semiconductor)
Quick minutes and the slides I used attached. Note that I added one more slide to list all function combination without any network drawn into the picture.
Start:
~8AM PST - ~8:46AM PST
Present (sorry if I missed someone or mistyped the name):
Pedro Batista
Jouni Korhonen
Bomin Li
Peter Turnbull
Philippe Sherier
Steinar Bjoernstad
Zakaria Tayq
Kevin Bross
Peter Ashwood-Smith
Satory Matsushima
Discussion:
The call concentrated on agreeing the baseline and assumptions for
the CPRI mapper and RoE encapsulation/decapsulation functions
and their placement in the system.
The attached powerpoint concludes the combinations for functions.
It should be noted that the mapper also contains the RoE encap/decap
function. However, the RoE encap/decap can be deployed as standalone
function (assume that RE and/or REC are the "native" RoE compliant
devices).
The mapper & encap/decap functions can be part of the switch,
RE, REC or be standalone frontends or "sidecards".
We aim to define 1:1 translation between CPRI frame format and
native RoE encapsulation.
CPRI rates 1 to 7 are of interest (because the use 8B/10B line
coding).
Next steps:
* Look into the RoE header itself.
* Agree on the basics for the AxC to RoE flow mapping e.g. only
one AxC per Ethernet packet etc.
* Agree RoE encapsulated packet properties e.g. whether the
payload always has static size (after the flow/link has been
established) etc.
* Study how CPRI rates affect RoE encapsulated packet sizes..
Contributions are welcome.. I'll send out the next agenda next week.
--
Jouni Korhonen, Ph.D, Associate Technical Director CTO Office, Networking, Broadcom Corporation
O: +1-408-922-8135, M: +1-408-391-7160