| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi, Thanks for the input. See my initial comments inline. From: Lars Ellegaard [mailto:le@xxxxxxxxxxx]
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) -----Original Message----- 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 |