Hi Chao,
From: du.chao@xxxxxxxxxx [mailto:du.chao@xxxxxxxxxx]
Sent: Thursday, January 14, 2016 11:33 PM
To: Jouni Korhonen
Cc: stds-1904-3-tf@xxxxxxxx
Subject: 答复: RE: Re: Draft v0.3 now available on the website
3) If there are many different flows come from a mapper,it's better to modify Figure 4. Are these different flows identified by flowID
which defined in mapper container's parameter?
4) How to describe the relationship between a mapper's flow and an ethernet link's flow? Whether there is such a situation that an ethernet link's flows comes from different mapper
[JiK:] Could you elaborate this a bit further what you mean..
[duchao] If a mapper's two flows belongs to different ethernet link and the flowID of these two flows are same.
[JiK:] Right. I spent some time going through this again and there are clarifications to be made. Just stating SA+DA pair is too restrictive. This is
what I was thinking:
* For the flowIDs to work properly, a mapper or a RoE endpoint instance receiving flows has to be the one “owning” the flowID space for those flows. This
would actually be independent of the used links ? not exactly what I stated earlier, since that would only work in a simple deployment case without getting overly complex.
* From a RoE packet sender point of view, destination+flowID pair is unique. From a receiver point of view its own “instance”+flowID is unique. That basically
means a single “mapper” or “RoE endpoint” has flowID space of 256 that it can assign to its peers to receive flows (remember that flows are unidirectional).
* Now what constitutes a source or destination address is not straight forward. It can be a MAC address or MAC+VLAN, etc.. as long as one or more of those
get RoE packets to a single “mapper” or a “RoE endpoint” instance. I rather associate the destination and source address to a specific mapper or RoE endpoint _instance_ independent of used addressing scheme. To put this into other words, a mapper or RoE endpoint
can send RoE packets with overlapping flowIDs to different destinations but can only receive non-overlapping flowIDs.
- Jouni
Then for a packetizer, the parameter fPackID will not be the same with the flowID in ROE head, So it's better to add a parameter to describe the flowID information.
And for a container's parameter set，it's better to change the
parameter name "flowID" to "fPackID"
|
Parameter |
Bits |
Name
|
Default
|
Description
|
||||||||||
|
Identifier
|
8 |
.fPackID
(.flowID)
|
0
|
Each flow packetizer in a given node has a unique identifier.
.flowID is generically used to describe the flow from either a mapper to a packetizer and a depacketizer to a demapper.
|
||||||||||
|
Encryption
|
4 |
.encypt
|
0
|
Selects/enables encryption on a given flow. 0x0 is no encryption
|
||||||||||
|
Compression
|
4 |
.compress
|
0
|
Selects/enables compression on a given flow. 0x0 is no compression
|
||||||||||
|
Associated Ethernet link
|
8 |
.ethID
|
0
|
Identifies the destination Ethernet link
|
||||||||||
|
Associated mapper
|
8 |
.mapperID
|
0
|
Identifies the source mapper
|
||||||||||
|
Packet length
|
16 |
.lenPack
|
0
|
Identifies the amount of data to packetize
|
||||||||||
|
Ordering information
|
See 4.4.5 Ordering information (orderingInfo) |
|||||||||||||
A single
(de)mapper[(de)mapperID].[containerID] parameter set is described as below:
{
.flowID
.lenSkip
.lenContainer
.modulo
.index
}
杜超 Du Chao
BBU系统部
/ 无线产品经营部
BBU R&D center / Product R&D-Wireless Product Operation
|
|
|
|
Jouni Korhonen <jouni.korhonen@xxxxxxxxxxxx>
2016/01/15 03:48
|
|
Hi,
Some initial comments inline.
From:
du.chao@xxxxxxxxxx [mailto:du.chao@xxxxxxxxxx]
Sent: Thursday, January 14, 2016 2:00 AM
To: Michael Johas Teener
Cc: Glen Kramer; Jouni Korhonen; Marek Hajduczenia; Richard Maiden;
stds-1904-3-tf@xxxxxxxx
Subject: 答复: Re: Draft v0.3 now available on the website
Some questions about the draft
1) For a Ethernet link , there are some different flows, these flows are identified by the flowid in the ROE head. For two flows belonged to different link，the
flowid can be same or not？
[JiK:] For a different SA/DA pairs the flowIDs can overlap.
2）For a mapper's output ,there are maybe many different flows or only one flow?
[JiK:] A mapper can output multiple flows. For example a flow per AxC.
3) If there are many different flows come from a mapper,it's better to modify Figure 4. Are these different flows identified by flowID
which defined in mapper container's parameter?
4) How to describe the relationship between a mapper's flow and an ethernet link's flow? Whether there is such a situation that an ethernet link's flows comes from different mapper
[JiK:] Could you elaborate this a bit further what you mean..
- Jouni
杜超 Du Chao
BBU系统部 /
无线产品经营部 BBU R&D center / Product R&D-Wireless Product Operation
|
|
|
|
Michael Johas Teener <Mikejt@xxxxxxxxxxxx>
2016/01/13 15:28
|
|
Discussions on the reflector are useful
--
Michael Johas Teener - Sr. Technical Director, Broadcom Corp
mikejt@xxxxxxxxxxxx /
m@xxxxxx - +1-831-824-4228
On Jan 12, 2016, at 11:40, Glen Kramer <gkramer@xxxxxxxxxxxx> wrote:
What I want is to have the discussion in advance now that the document is “available”. IMHO there is no reason to defer bringing up issues or ask for clarifications early ? if there are some .
GK: That is fine. You as the TF chair, or the TF altogether, need to decide how to structure this discussion. Do you want people to submit comments? Do you want people to bring it up on conference calls, do you want it to be discussed on the reflector?
Once this is decided, you need to announce it, so that everyone knows how to participate.
Glen
- Jouni
Once balloting starts, anyone can continue commenting, but the WG members who are in the ballot group also must submit ballots
Glen
From: Jouni Korhonen
Sent: Tuesday, January 12, 2016 10:46 AM
To: Marek Hajduczenia; 'Richard Maiden'; 'stds-1904-3-tf@xxxxxxxx'
Cc: Glen Kramer
Subject: RE: Draft v0.3 now available on the website
Hopes are after Feb meeting.. let’s see.
I would not mind seeing those comments already in advance. Discussing issues the early as possible benefits all.
- Jouni
From:
stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx]
On Behalf Of Marek Hajduczenia
Sent: Monday, January 11, 2016 7:07 AM
To: 'Richard Maiden'; 'stds-1904-3-tf@xxxxxxxx'
Cc: Glen Kramer
Subject: RE: Draft v0.3 now available on the website
A quick question ? when is the ballot expected to start? I have a few comments but mostly for clarification, so I assume that broader WG discussion would be need to resolve these.
Marek
From:
stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx]
On Behalf Of Richard Maiden
Sent: Thursday, January 07, 2016 7:02 PM
To: stds-1904-3-tf@xxxxxxxx
Cc: 'Glen Kramer' (gkramer@xxxxxxxxxxxx)
Subject: Draft v0.3 now available on the website
Hi All,
The v0.3 is now available on the website here
(thanks Glen). All/any comments/suggestions are welcome.
Cheers,
Richard
Richard Maiden
ALTERA (an Intel Company)
101 Innovation Drive
San Jose, CA 95134
Tel: +1 (949) 382-5402
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).
If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately.
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately.