| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hello All, I wonder if it is safe to be agnostic on the synchronisation mechanisms and assume that it will be provided by A N Other. While reuse of existing tools (e.g. IEEE1588, SyncE) will be
preferred to reinventing the wheel, which tools are used and how they are deployed may impact other decisions. For example calculations on Packet jitter vs packet/frame size should include the impact of 1588 (as a second high priority stream alongside the
RoE user plane data). Regards Peter Peter Turnbull ADVA Optical Networking SE is a European stock corporation ("Societas Europaea") with registered offices at Maerzenquelle 1-3, D-98617 Meiningen,
Germany * CEO: Brian L. Protiva, Chief Officers: Dr. Christoph Glingener, Ulrich Dopfer * Chairman of the Supervisory Board: Nikos Theodosopoulos* AG Jena HRB 508155 * VAT No.
DE 175 446 349 From: stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx]
On Behalf Of Jouni Korhonen 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 |