Subject: [16ng] Call for comments on 16ng BoF

From: Soohong Daniel Park <[email-masked]>
Date: Tue, 13 Sep 2005 10:36:38 +0900

Hello folks,

I and some of related people are trying to propose a new BoF at upcoming 64th IETF and the specific tasks are in progress. This issue aims to assist in doing a WiBro (IEEE 802.16) task. Here is existing charter of this BoF.

http://daniel.vsix.net/kwisf/wibrov6/charter.html 

Please make comments on this stuff and don't hesitate to ask further question.

This charter and mailing list will be officially available in the IETF, WiMAX Forum, 802.16 and related groups soon. Hopefully, I will send it to the IESG, if the status of charter and discussion are fully mature before cutoff.  

Regards,

Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics.

---

From: Myung-Ki Shin <[email-masked]>
Date: Tue, 13 Sep 2005 15:20:39 +0900

Technical comments ...

In addition, as for the neighbor discovery issues, 
current ETRI Wibro implementation (IPv4) does not use ARP.
Thus, IPv6 ND issues would be the same as ARP ones.

I think like 3gpp, (at least) some ND messages can be 
unncessary in certain cases. There are no link layer addresses.
Therefore, address resolution and next hop determination 
are not needed.   

Miminum recommendatation could be NUD (Neighbor unreachability
detection), which is performed only for neighbors to
which unicast packets are sent.

So, a more interesting one is to point out supporting 
multiple interface with different ND characteristics in a host(MSS). 
(e.g., 802.11 + 802.16 both support) 

Any thought ?

Myung-Ki,

Myung-Ki Shin wrote:
> 
> Daniel,
> 
> I think it would be the good start for the BoF.
> 
> I'm also trying to make a draft on "A consideration of IPv6 in
> IEEE802.16 networks".
> 
> So, I can share my idea with you.
> 
> As for the charter, we need to discuss about the scope and goal more ...
> Also, we should define problems clearly before sending the proposed
> charter to IESG.
> (I couldn't see the problems beyond ND in the proposed charter)
> 
> See comments below.
> 
> Soohong Daniel Park wrote:
> 
> ---- cut here ----------
> IPv6 over IEEE 802.16(e) Networks (16ng)
> 
> => I think the wg name 16ng has too broad meaning. Also,
>    to make a wg in IETF, it's better to include IP issues
>    in the name rather than 16xxx.
> 
>    I prefer a 6xxx, e.g., 6wiman, ..
> 
> Last Modified: 2005-09-10
> 
> Chair(s):
> 
> Soohong Daniel Park<[email-masked]>
> TBD
> 
> Internet Area Director(s):
> 
> Mark Townsly<[email-masked]>
> Margaret Wasserman<[email-masked]>
> 
> Mailing Lists:
> 
> General Discussion: [email-masked]
> To Subscribe: http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
> Archive: http://eeca16.sogang.ac.kr/pipermail/16ng
> 
> Description of Working Group:
> 
> Broadband Wireless Access Network was invented to overcome the low
> bandwidth wireless communication which was not appropriate for the user
> requirements such as high quality data/voice service, fast mobility,
> wide
> coverage and etc. To achieve these requirements, the IEEE 802.16 Working
> Group on Broadband Wireless Access Standards develops standards and
> recommended practices to support the development and deployment of
> broadband Wireless Metropolitan Area Networks. In addition, IEEE 802.16e
> supports mobility over IEEE 802.16 as an amendment of the IEEE 802.16
> specification.
> 
> Recently, much work is in progress by the WiMAX Forum. In particular,
> its
> NWG (Network Working Group) is responsible for the IEEE 802.16(e)
> network
> architecture (e.g., IPv4, IPv6, Mobility, Interworking with different
> networks,
> AAA, etc). The NWG is thus taking on work at layers above those defined
> by IEEE 802 standard (typically limited to the physical and link layers
> only).
> 
> IEEE 802.16(e) is significantly different from existing wireless access
> technology
> such as IEEE 802.11, and there are lots of considerable aspects to be
> resolved by
> IETF when applying Internet Protocol for IEEE 802.16(e) link.
> Expecially,
> IPv6 Neighbor Discovery does not work over IEEE 802.16(e) link. A key
> assumption made by Neighbor Discovery's actual protocol is that the link
> technology underlying a given IP interface is capable of native
> multicasting.
> This is, however, not true of IEEE 802.16(e) network although it belongs
> to
> IEEE 802 protocol not Non-Broadcast Multicast Access networks like ATM
> and Frame relay. Eventually, IEEE 802.16(e) requires convergence
> protocols
> to emulate the desired service on the network entiry such as BS and IPv6
> features will be limited. In addition, the characteristics of IEEE
> 802.16e
> link-layer operation require an amendment of existing Fast Handover
> Mobile
> IPv6 scheme (RFC 4068).
> 
> The principal objective of this working group is to make sure what
> limitation
> and consideration happen to IPv6 adoption over IEEE 802.16(e) network
> and
> propose available solutions. In addition, this working group arguments
> and
> optimizes the IEEE 802.16(e) protocol for use in support of IPv6
> Neighbor
> Discovery. In addition, the working group will work and coordinate with
> WiMAX
> Forum especially NWG and such related groups.
> 
> In the case of IPv6, it remains a future work of current WiMAX Forum
> specification to be begun next year. However, WiMAX Forum does not
> define any new Internet Protocols by itself regardless of protocol
> limitations.
> Consequently, Internet Protocol limitations should be resolved by IETF.
> 
> => General comments on description of wg
> 
>    Maybe, IESG will ask the relationship of WiMAX Forum and its future
> works e.g., standards,
>    since some WiMAX forum works are mentioned here.
> 
>    In my opinion, we define a more specific scope to
>    eliminate dependency with WiMAX Forum.
> 
>    Also, if we focus on general IPv6 issues (not, mobility or
> *IP-related-
>    -specific* issues in IEEE802.16),
>    I suggest to follow-up the general steps for Internet Area's (IP over
> xxx) WG.
> 
>    1) define problems and goal
>    2) produce one document to describe them
>    3) if some changes or extensions are required to current IP specs,
>       document seperated drafts to update each issues ...
> 
>    One proposal could be (of course we need to investigate each issue
> first
>    to figure out what problems are or not) ...
> 
>    * Basic IP issues - ND, Transmission of packets, Path MTU,
> addressing, ..
>    * Mobility - Interworking with FMIP6, L2/L3 mobility interworking
> ...
>    * Multicast
>    * Security
>    * Multiple interface with different properties (e.g., 802.11 + 802.16
> both support)
>    * Interworking with different networks
> 
> The scope of this working group is as follows;
> 
> Note; this working group is only focusing on IPv6 since IPv4 issues are
> under
> control. Whereas at least some of the valuable efforts on IPv4 could be
> documented
> in IETF as an individual process.
> 
>   => What does mean "IPv4 issues are under control" ?
>      We need to describe the reason clearly ..
> 
> -  Produce ¡°Problem Statements for IPv6 over IEEE 802.16(e) Networks¡±
> to sense the problem and limitation of IPv6 adoption over IEEE 802.16(e)
> networks.
> [Informational RFC]
> 
> -  Produce "Fast Handover Mobile IPv6 over IEEE 802.16e Networks" to
> define
> the fast handover scheme for mobile IPv6 (RFC 3775) over IEEE 802.16e
> link.
> [Informational RFC]
> 
> -  Product "IPv6 over IEEE 802.16(e)" to define the transmission of IPv6
> over
> IEEE 802.16(e) link for use in support of IPv6 Neighbor Discovery.
> [Standard RFC]
> 
> This working group will reuse existing specifications whenever
> reasonable and
> possible.
> 
> Goals and Milestones:
> 
>   Dec 05
> 
>                          Submit Internet-Daft on problem statements to
> IESG for consideration of publication as Informational RFC
>   Feb 05
> 
>                          Submit Internet-Draft on FMIP6 over IEEE
> 802.16e to IESG for consideration of publication as Informational RFC
>   July 06
> 
>                          Submit Internet-Draft on IPv6 over IEEE
> 802.16(e) to IESG for consideration of publication as Proposed Standard
>                          RFC
> 
> 
> Internet-Drafts:
> 
> Mobile IPv6 Fast Handover over IEEE 802.16e Networks
> Transmission of IPv6 Packets over IEEE802.16 Networks
> IPv6 over IEEE 802.16(e) Networks Problem Statements (coming soon)
> 
> Related links:
> 
> BoF Procedures
> Important Dates for the 64th IETF Meeting
> WiMAX Forum Homepage
> IEEE 802.16 Task Group e (Mobile Wireless MAN)
> 
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Myung-Ki Shin, Ph.D.| [email-masked]
> ETRI/PEC            | 161 Gajeong-dong Yuseong-gu
> Tel:+82-42-860-4847 | Daejeon, 305-350 Korea

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Myung-Ki Shin, Ph.D.| [email-masked]
ETRI/PEC            | 161 Gajeong-dong Yuseong-gu 
Tel:+82-42-860-4847 | Daejeon, 305-350 Korea

---

From: YounHee Han <[email-masked]>
Date: Tue, 13 Sep 2005 16:00:21 +0900

Hello,
 Thank you for bringing up technical issue.
 In some presentation, I talked about the following issues in ipv6/wibro 
problem space.
- router (prefix) discovery,
- stateless address auto-configuration,
- address resolution, 
- next-hop determination, 
- NUD,
- Redirect
- Multicast address mapping of ND-related messages
- MLD
 As said by Myung-Ki, in 802.16 specification (802.16-2004), 
address resolution function seems to be already addressed 
in Section 5.2.2 'classification'. We can expect that 
ACR device of WiBro will implement the classification
function in its convergence sub-layer.
 The classification function is only applied to the downward packets 
(packets come from network to terminal) and implemented inside ACR. 
How about upward packets (packets from terminal to network or terminal)?
Classification is not related to terminal. So, the simple solution is to
fix the resolution result of all addresses with "ACR's address"
It seems to be somewhat controversial. Any comments?
 Regarding next-hop determination, the solution seems to be
similar with the above.
 I roughly agree with Myung-Ki. But, I don't want to firmly conclude that
"address resolution and next hop determination are not needed"
It's one of 3gpp's sentence :-) Instead of it, we can say that...
"address resolution and next hop determination can be simply implemented"
 - Youn-Hee Han (Ph.D.)
Samsung Advanced Institute of Technology
 On 9/13/05, Myung-Ki Shin <[email-masked]> wrote:
 
> > > I and some of related people are trying to propose a new BoF at 
> upcoming 64th IETF and the specific tasks are in progress. This issue aims 
> to assist in doing a WiBro (IEEE 802.16) task. Here is existing charter of 
> this BoF.
> > >
> _______________________________________________
> 16ng mailing list
> [email-masked]
> http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
>

---

From: Myung-Ki Shin <[email-masked]>
Date: Tue, 13 Sep 2005 16:44:50 +0900

Hi,

At this phase, I don't want to discuss about solutions ...
I'm just saying it is really a problem or not.

e.g., as for the ND issues, if we conclude *address 
resolution and next hop determination are not needed* or 
*address resolution and next hop determination can be 
simply implemented*, any statement will be not a problem, 
just one of implementation considerations, I think.

My intention was to figure out problems to put them
in charter items.  

Back to the general comments on propsoed charter, 
we should focus on the scope according to problem statement 
discussion. (to create wg :)

We can say ND may be a problem just in 802.16 networks ? 
 
Thanks,
Myung-Ki,

---

From: "Younhee Han" <[email-masked]>
Date: Tue, 13 Sep 2005 17:19:21 +0900

> discussion. (to create wg :)

Yes. I understand your point. 
I really want to focus the problem definition, too.

My intention was just asking a favor to you 
that we should take a different view from IPv6/3gpp 
when we talking about  IPv6/Wibro issues.
 
> We can say ND may be a problem just in 802.16 networks ? 

In my opinion, ND can be a problem in IPv6/WiBro in terms of 
the multicast method of ND messages.

Now, I'd like to raise another issues related to ND problem.

1) Should we support the stateless address configuration in 802.16 networks?
2) If it should be supported, how to defend the address conflict?

If we try to solve the address conflict by using RFC 2462 DAD solution,
the following issue can be also brought up:

3) How to deliver NS message with the solicited-node multicast address as its destination?

Definitely, the issue 3) is related to ND 

- Youn-Hee

---

From: Soohong Daniel Park <[email-masked]>
Date: Wed, 14 Sep 2005 09:17:50 +0900

> I'm also trying to make a draft on "A consideration of IPv6 in 

Remind that we have to search for at least one item as Standard Track RFC, leading to clean up the issue that why we need this BoF within IETF. This is what IESG (and 802.16 guy) is speaking to me.

Your task seems a bit more informational document. Or is there any protocol issues ? If yes, that would be very useful to me at this stage...

Regards,

---

From: Myung-Ki Shin <[email-masked]>
Date: Wed, 14 Sep 2005 09:29:26 +0900

> the multicast method of ND messages.

Okay, if so, we got something new(?) to describe problems, 
rather than other networks (e.g., 3gpp ...)

As for the other issues below, I thought considerations would be 
the same as those of 3gpp considerations, described in rfc 3316.

If we find something different, it will be good news for BoF ...

Now, I'm gathering considerations from ETRI implementation.
I can finish all of works soon, then we can share 
the information, hopefully. 

Thanks, 
Myung-Ki,

---

From: Soohong Daniel Park <[email-masked]>
Date: Wed, 14 Sep 2005 09:45:38 +0900

> Definitely, the issue 3) is related to ND 

Any protocol issues to be newly defined as a Proposed Standard RFC ?
If you are saying an operational aspect, proxy ND seems a reasonable approach without any host-side requirement.

Once again, please looking for a protocol issues wrt IPv6 over 802.16(e) networks, slightly aside from ND considerations.

Regards,

---

From: Myung-Ki Shin <[email-masked]>
Date: Wed, 14 Sep 2005 09:51:56 +0900

> Remind that we have to search for at least one item as Standard Track RFC, leading to clean up the issue that why we need this BoF within IETF. This is what IESG (and 802.16 guy) is speaking to me.

That's what I'm saying now. 

To find protocol issues, problem statements (Info RFCs) should be
proposed first. 

So, first, basic question on this BoF was "there are problems (protocol
issues)
on IPv6 adoption in IEEE802.16, not implementation considerations ?

It would be asked by IESG, maybe.
 
> Your task seems a bit more informational document. Or is there any protocol issues ? If yes, that would be very useful to me at this stage...

I think *considerations* (in IETF) has broader view 
(protocol issues, operational issues, implementation issues)
than problem statement.

It will be a fist step to investigate the problems. 

As I said, the general steps for Internet Area's (IP over xxx) WG. 

   1) define problems and goal 
   2) produce one document to describe them  (Info RFCs)
   3) if some changes or extensions are required to current IP specs, 
      document seperated drafts to update each issues ... (Std RFCs)

Thanks, 
Myung-Ki,

---

From: Soohong Daniel Park <[email-masked]>
Date: Wed, 14 Sep 2005 09:57:18 +0900

> To find protocol issues, problem statements (Info RFCs) should be

It is already under work of course...:-)

Regards,

---

From: Myung-Ki Shin <[email-masked]>
Date: Wed, 14 Sep 2005 10:09:38 +0900

> It is already under work of course...:-)

If so, can you clarify or summarize problems (protocol issues) ?
I didn't see the point in proposed charter, beyond ND.
At this phase, I'm not sure of ND.

Thanks,

---

From: YounHee Han <[email-masked]>
Date: Wed, 14 Sep 2005 22:07:36 +0900

Hi Daniel,

> Once again, please looking for a protocol issues wrt IPv6 over 802.16(e) networks, slightly aside from ND considerations.

Ok. I understand your point. For a wg foundation,
We need a protocol of standard track, not informational one. 

As asked by Myung-Ki, however, I am also curious to know  
the protocol issues of "IPv6 over 802.16" without ND consideration.
do ND-related issues always come to end with informational document?
I am not sure at this stage.

- Youn-Hee Han

---

From: YounHee Han <[email-masked]>
Date: Wed, 14 Sep 2005 22:30:54 +0900

> If we find something different, it will be good news for BoF ...

Yes. I agree. We need a document like rfc 3316.
As you know well, however, at the current stage, 
such document seems to be not urgent one for founding BoF.
But, we should keep such work in mind steadily 
to operate IPv6 over WiBro, I think. 

> the information, hopefully.

Good news. I hope to see your work soon. 
We are also interacting with Samsung implementation team at some intervals.
Let's discuss about it continuously.

Thanks.

- Youn-Hee Han