Re: [STDS-802-16] [TG Relay] [Forwarding ad-hoc]Agenda for the 3rd CC
Hi, T.M and all,
I have no personal intention at all. Just try to put it more straightforward for those proposed text.
Thanks for T.M's modification, I think it's acceptable to clarify this fact. But except the content itself, I would like to know:
1. Should the bandwidth allocatioin of Tunnel packet mode for centralized scheduling be delivered by RS Access MAP message and RS relay message MAP also, if centralized scheduling is used for tunnel packet mode. By no means, I can see it's not by using these messages. So should we also extend it to this mode?
Beside, these two message are said to use RS basic connection, so it is the RS basic CID. Is there any problem if it is used in tunnel? Shouldn't we use the tunnel CID for tunnel burst mode within these messages ? I am not sure how it works with different CIDs. Could you please give us a detailed description on that.
2. I understand these two messages RS Access MAP message and RS relay message MAP can be only used in non-transparent RS while in transparent case it it decided by DL-MAP. By adding TM's clarification it is equal to say that the tunnel burst mode is exclusively for non-transparent RS only. Which is still not very clear to me related with transparent RS and tunnel mode is whether transparent RS can be used for more than two hop case or not? From Kan's contribution, I can see maybe he's thinking it is possible but some other persons maybe have different understanding. And based on this understanding, we should incur another question is it possible for tunnel mode also used in transparent RS?
I think these two questions is very fundalmental issue otherwise if people have no common sense, there will be lots of comments and repeated work to be done. Could someone give me the answer if it aleady known to everyone or should we just first figure it out?
If my understanding is worong, please kindly piont it out to me.
3. In the text of RS Access MAP message and RS relay message it explictly says that it is for centralized scheduling to use this message for resource allocation, so I can also understand it includes the meaning to do the bandwidth allocation for tunnel burst or even tunnel packet and CID based mode. So I am afraid whether it is appropriate to propose it again in the section
6.3.3.8.1.
4. Rakesh, some minor editorial problems here in Forwarding comments_r4, it reads:" All MPDUs from a connection that is assigned to traverse a tunnel must be transmitted through that tuunel." I suggest to change must to shall. Second, in your revised subclause
6.3.3.8.1, line 6 there is a typo : it should be T-CID or MT-CID.
I do appreciate if any of you kindly provide me any of your thoughts on the above issues.
Junhong
On 11/9/07, TMLin@itri.org.tw <
TMLin@itri.org.tw> wrote:
Dear all
According to Wei-Peng's quick remedy, I modified the texted for
clarification for Tunnel Burst mode.
Please reference the attached file.
Any further comments are welcome.
BR
T.M.
---------------- Original Message ----------------
> Rakesh Taori <
rakesh.taori@samsung.com> 2007/11/09 上午 09:46:43
wrote:
收件人: "Kanchei(Ken) Loa" <loa@iii.org.tw
>,STDS-802-16@LISTSERV.IEEE.ORG
副本抄送: "'Guo-Qiang Wang'" <
guoqiang@nortel.com>,Hyunjeong Kang
<hyunjeong.kang@samsung.com>,"
tao@merl.com"
<tao@merl.com>,"
Ranga.Reddy@us.army.mil"
< Ranga.Reddy@us.army.mil>,"
yukihiro.takatani.ee@hitachi.com"
<yukihiro.takatani.ee@hitachi.com >,"
Peng.yan@huawei.com"
<Peng.yan@huawei.com>,"'Hang Zhang'"
<
hazhang@nortel.com>,"mchion@zteusa.com"
<
mchion@zteusa.com>,"chen.yuqin@zte.com.cn "
<
chen.yuqin@zte.com.cn>,"qu.hongyun@zte.com.cn"
<
qu.hongyun@zte.com.cn >,"shashi.maheshwari@nsn.com"
<
shashi.maheshwari@nsn.com>,"tmlin@itri.org.tw "
<
tmlin@itri.org.tw>,"yousuf.saifullah@nsn.com"
<
yousuf.saifullah@nsn.com >,"nakatsugawa@jp.fujitsu.com"
<
nakatsugawa@jp.fujitsu.com>," hcyin@nmi.iii.org.tw"
<
hcyin@nmi.iii.org.tw>,"okuda@jp.fujitsu.com"
<
okuda@jp.fujitsu.com>,"wei-peng.chen@us.fujitsu.com"
<
wei-peng.chen@us.fujitsu.com>,"'Gamini Senarath'"
<gamini@nortel.com>,"
dcomstock@huawei.com"
<
dcomstock@huawei.com>," Jerry.sydir@intel.com"
<
Jerry.sydir@intel.com>,"junhongh@gmail.com" <
junhongh@gmail.com>,JungJe
Son <jungje.son@samsung.com>,"'Mike Hart'"
< Mike.Hart@ukbroadband.com>,"'Peiying Zhu'" <
pyzhu@nortel.com>
主旨: [TG Relay] [Forwarding ad-hoc]Agenda for the 3rd CC
(Apologies to those who receive this twice. Sorry)
Hi! All
Here's an agenda proposal for the 3rd Conf call. We will discuss any
changes to this at the beginning of the call
(1) Discussion on the Agenda
(2) Verification of Previous Minutes/agreements (1st and 2nd Call)
(2a) Take Input from TM Lin
(2b) Any other inputs?
(3) Go through discusion of Tunnel QoS
Haihong/GQ to summarize the current discussions including Wei-Peng's
questions.
(4) Go through Section
6.3.1.3 (Comments 81 through 85)
Discuss the issue of Tunel Direction, Tunnel COnnection and Tunnel
Connection ID.
(5) Updated Feature Matrix
Based on GQ's updated slide
(6) Discussion on Burst Based Forwrading:
Follow-up for Ken's e-mail
(7) Remaining Comments
Regards
Rakesh
--------------
Hi! All
Here are the detais of the 3rd conf call as agreed towards the end of our
2nd call:
Day: Friday GMT 02:00 - 04:00 (=Tuesday 6-8 pm PST, 8-10 pm Central, 9-11pm
EST. Wed 11am-1pm Korea/Japan, Wed 10am -12pm China).
Bridge#: +1-613-763-0170
Passcode: 3935345#
G.Q: I believe you already confirmed the bridge. Right? If not, kindly do
so.
Thanks and Regards
Rakesh Taori.
本信件可能包含工研院機密資訊，非指定之收件者，請勿使用或揭露本信件內容，並請銷毀此信件。
This email may contain confidential information. Please do not use or disclose it in any way and delete it if you are not the intended recipient.