| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Jouni, Thank you for your response. I agree with you that there is a difference between a standard and an implementation/solution (which I think you’re saying implicitly). I may have tilted
too much to the solution-side. Nevertheless, please see inline marked [LE]. Thx Lars From: Jouni Korhonen [mailto:jouni.korhonen@xxxxxxxxxxxx]
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. [LE] Right. We assume frequency and time is synchronised “somehow”. The network consist of 0-through-N more or less synchronised Ethernet bridges causing more or less jitter/PDV (these are also assumptions
or border conditions, BTW). The amount of jitter/PDV will certainly influence the jitter buffer design, but that is out of scope for this standard. Now, the delay from BBU to RRH must be measured accurately. There are several ways to do that – 1588, Y.1731, new_RoE_method, CPRI-method. So the delay parameter can be an input to the ROE function, or
it can come out of a process from within the RoE function. The former approach places some assumptions on the underlying network. • 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. [LE] Here I was thinking of for example number of switches, which directly ties into jitter. Per statements above that example is out of scope. • 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. [LE] Right. Some principal guidance would probably be good, though. Like the principal ingredients. • 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 |