| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Marek, More stuff inline. From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Jouni, inline as well
Marek From: Jouni Korhonen [mailto:jouni.korhonen@xxxxxxxxxxxx]
Marek, Thank you again for your feedback. See my responses inline. From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Jouni, It is not clear what you mean by "common Ethernet Types" - is the implication that a single Ethertype is used? [Jouni Korhonen]
Actually, I do not know.. To me it is rather obvious that at least one Ethernet type is needed but should there be more, would be for the TF / WG to decide. At the moment
we do not know for sure. PAR step 6.1.B is rather clear on this. [mh1007] Ethertypes are very scarce resource, and I would suggest to focus on the use of one Ethertype if possible. It will be a simpler sell versus getting more than 1. There
are other ways to differentiate subtypes, if needed. See how OAM does that via vendor-specific extensions. That seems to work quite well and takes away a burden from burning through Ethertypes too quickly. [Jouni Korhonen]
Ok. Fine with me. What if the TF / WG sees they need more? Would then reserving more than one unacceptable given the PAR says we need one? IQ needs expansion - it is not a commonly used acronym.
[Jouni Korhonen]
Ok. No problem expanding all occurrences of IQ. I am not sure "
The unified encapsulation format allows for future development also on other transport technologies than Ethernet." Is pertinent to this PAR.
[Jouni Korhonen]
I think I see your point. What we wanted to stress here is that once we got a solid solution for Ethernet, the threshold for using the same solution for other transports could
be rather low. Unified format has its benefits, for example, reusing the same building blocks in products. [mh1007] I think the major aspect you want to address right now is mapping into Ethernet. I would address Ethernet application first and should additional mappings become necessary,
get a new PAR and add it. I always prefer focused projects that clearly state what they try to achieve, versus “save-the-world” projects with open-ended PARs. Just a personal opinion, though.
[Jouni Korhonen]
This PAR only intends to work on Ethernet application. I (and the rest of the PAR group) agree on it. That’s why 5.4.Yes says “allows for future development” i.e. we acknowledge
the fact that other transports are for the future and would naturally need either a new PAR or work to be moved to more appropriate SDO. - Jouni Regards Marek -----Original Message----- Marek, Trying to address your comment for the text in 5.4.Yes: "This standard enables the transfer of IQ user-plane data, vendor specific data, and control and management (C&M) information channels across an Ethernet-based packet-switched network. The standard fosters
interoperability among implementations by defining framing, the encapsulation of the information, and common Ethernet Types. The unified encapsulation format allows for future development also on other transport technologies than Ethernet." - Jouni > -----Original Message----- > From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx] > Sent: Monday, October 06, 2014 10:07 PM > To: Jouni Korhonen; Glen Kramer; 'STDS-1904-WG@xxxxxxxxxxxxxxxxx' > Subject: RE: Radio over Ethernet draft PAR for the IEEE 1904
> pre-review & discussion > > Jouni > > I think the text in 5.2 and 5.4.Yes should be clarified to avoid the
> use of the term "header", if possible, and break long sentences into
> shorter, more informative statements. > > Note also that a typical term is "payload" and not "pay-load" > > Marek > > -----Original Message----- > From: Jouni Korhonen [mailto:jouni.korhonen@xxxxxxxxxxxx] > Sent: Monday, October 6, 2014 2:57 PM > To: Marek Hajduczenia; Glen Kramer; 'STDS-1904-WG@xxxxxxxxxxxxxxxxx' > Subject: RE: Radio over Ethernet draft PAR for the IEEE 1904
> pre-review & discussion > > Marek, > > Thank you for reviewing the PAR. Comments pointing out ambiguity in
> the text are very important. > > It is not the intention to touch the Ethernet header, by adding
> /removing / changing existing fields. Since this seemed not to crystal
> clear we better clarify the PAR text on this. Could you point at which
> part of the text exactly gave you this impression? > > Headers the PAR mentions are what you refer as " a simple mapping of
> data received from RF interface into payload of an Ethernet frame". > > Thanks, > Jouni > > > -----Original Message----- > > From:
stds-1904-wg@xxxxxxxx [mailto:stds-1904-wg@xxxxxxxx]
On Behalf > > Of Marek Hajduczenia > > Sent: Monday, October 06, 2014 9:36 PM > > To: Glen Kramer; 'STDS-1904-WG@xxxxxxxxxxxxxxxxx' > > Subject: RE: Radio over Ethernet draft PAR for the IEEE 1904
> > pre-review & discussion > > > > Glen, et al., > > > > I do not have immediate issues with PAR, but it is not clear at this
> > time what the scope of the work would be. PAR mentions
> > "encapsulation of digitized radio In- phase Quadrature (IQ) pay-load
> > and related control data into an Ethernet packet including the
> > necessary encapsulation header within the encapsulating Ethernet
> > frame", which to me reads like a simple mapping of data received
> > from RF interface into > payload of an Ethernet frame. > > However, in different locations PAR refers to Ethernet headers,
> > which might be interpreted as implied changes to already defined
> > Ethernet header, by adding / removing / changing existing fields. I
> > am not sure whether that is the intent of the authors, but some more
> > details on what they are trying to achieve would be welcome, perhaps
> > in a form of a Power Point deck showing details of needed mapping
> > and intended changes > (if any) to Ethernet framing. > > > > > > The only reason why I bring it up is that we (1904WG) do not control
> > Ethernet frame structure, and while we can specify how data is
> > mapped from RF interface into Ethernet payload, changing the
> > structure of Ethernet headers would imply close cooperation with 802.3. > > > > Regards > > > > Marek > > > > -----Original Message----- > > From:
stds-1904-wg@xxxxxxxx [mailto:stds-1904-wg@xxxxxxxx]
On Behalf > > Of Glen Kramer > > Sent: Monday, October 6, 2014 2:16 PM > > To:
STDS-1904-WG@xxxxxxxxxxxxxxxxx > > Subject: FW: Radio over Ethernet draft PAR for the IEEE 1904
> > pre-review & discussion > > > > Dear Colleagues, > > > > I have received the following request for Radio-over-Ethernet (RoE)
> > project to be formed under 1904 WG. The draft PAR is attached. > > We will vote on this PAR at the next meeting. Meanwhile, I encourage
> > everyone to review and discuss the draft PAR on the reflector. Feel
> > free to contact PAR authors with any questions, or if you want your
> > name to be added as a supporter. > > > > If approved, this PAR will become 1904.3 project. > > > > Thank you, > > Glen > > > > -----Original Message----- > > From: Jouni Korhonen > > Sent: Monday, October 06, 2014 12:00 AM > > To: Glen Kramer > > Cc: Zongying He; Jay (James) Teborek;
duanran@xxxxxxxxxxxxxxx;
> >
cuichunfeng@xxxxxxxxxxxxxxx;
liu.qiong@xxxxxxxxxx;
> >
Patrice.Plante@xxxxxxxxxx;
zhang.boshan@xxxxxxxxxx;
> >
satoru.matsushima@xxxxxxxxxxxxxxxx;
tero.mustala@xxxxxxx;
> >
huangjinri@xxxxxxxxxxxxxxx;
Peter.AshwoodSmith@xxxxxxxxxx > > Subject: Radio over Ethernet draft PAR for the IEEE 1904 pre-review
> > & discussion > > > > Dear chair of the IEEE 1904 ANWG, > > > > Please see the attached draft version of the PAR for Radio over
> > Ethernet > > (RoE) standardization effort that we (the individuals in the CC
> > list) seek to pursue under the IEEE 1904 ANWG. We welcome a review
> > and comments from > > 1904 members on the current draft version of the PAR. We intend to
> > present this PAR in the forthcoming 1904 meeting in Wuhan to drive
> > our cause, which means we also ask for a presentation slot in the
> > forthcoming > 1904 meeting agenda. > > > > Should there be any additional backup material prior the meeting,
> > please let us know. If there are any other matters we should be
> > aware of > just let us know. > > > > Best regards, > > Jouni (on behalf of the PAR preparation team) > > > > > > -- > > Jouni Korhonen > > CTO Office, Networking > > Broadcom |