[16ng] Final Agenda (slightly modified)

[Soohong Daniel Park <[e-mail]>]

Agenda:

o Update: 2006-03-14

o Timeslot: 2 hrs

o Agenda Items:

05 mins:    Agenda bashing - chairs

20 mins:    16NG Problem Statement - Junghoon Jee
10 mins:    WiMAX Forum NWG Stage 3 work for IPv6 - Basavaraj Patil
10 mins:    IPv6 over IEEE 802.16 Solution Framework - Syam Madanapalli
50 mins:    Charter discussion - chairs

[If time allows]

05 mins:    IPv6 NDP for Common Prefix Allocation in IEEE 802.16 - Hongseok Jeon
05 mins:    IPv6 Packet Tramsmission over 802.16 Networks - Myungki Shin
05 mins:    Real-Time usage of IEEE 802.16: Problem Statement - Pedro Neves
05 mins:    QoS Aware Real-Time Support for IPv6 in IEEE 802.16 Backhaul scenarios - Pedro Neves

05 mins:    Closing - chairs

========
120 mins


Thanks, 

Gabriel and Daniel 
16ng BOF, co-chair
From [e-mail] Fri Mar 24 02:47:35 2006
Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33])
	by eeca16.sogang.ac.kr (8.12.8/8.12.8) with ESMTP id k2NHlZIB008766
	for <[e-mail]>; Fri, 24 Mar 2006 02:47:35 +0900
Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33])
 by mailout3.samsung.com
 (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004))
 with ESMTP id <[e-mail]> for
 [e-mail]; Fri, 24 Mar 2006 02:05:06 +0900 (KST)
Received: from daniellaptop ([124.235.139.2])14 2004))
	[e-mail]; Fri, 24 Mar 2006 02:05:06 +0900 (KST)
Date: Thu, 23 Mar 2006 11:05:00 -0600
From: Soohong Daniel Park <[e-mail]>
To: [e-mail]
Message-id: <020501c64e9b$ed8658e0$f6828182@daniellaptop>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
Content-type: text/plain; charset=ks_c_5601-1987
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
Subject: [16ng] Meeting notes
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1
Precedence: list
List-Id: IPv6 over IEEE 802.16(e) Networks <16ng.eeca16.sogang.ac.kr>
List-Unsubscribe: <http://eeca16.sogang.ac.kr/mailman/listinfo/16ng>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://eeca16.sogang.ac.kr/pipermail/16ng>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://eeca16.sogang.ac.kr/mailman/listinfo/16ng>,
	<mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 23 Mar 2006 17:47:35 -0000

Here is a meeting note. If you find any missing point, 
please let me know, and I will update accordingly. 


+++++++++++++++++++++++[BEGIN]+++++++++++++++++++++++++

IPv6 over IEEE 802.16e Networks BOF
-----------------------------------

Slot: Wed. 13:00 - 15:00 @ Coronado A

========================================================
Note: Special thanks to James Kempf for his effort on the notes
========================================================

Agenda bashing - chairs
16ng Problem Statement - Junghoon Jee
WiMax Forum NWG Stage 3 for IPv6 - Basavaraj Patil
IPv6 over IEEE 802.16 Solution Framework 0 Syam Madanapalli
Charter Discussion

IP over 802.16 Problem Statement
--------------------------------

- PMP Link layer
 
No native multicast support

No direct communication between stations

connection oriented MAC

PDUs transferred by connection id, Mac address is not used for transmission of MAC PDUs over the air.

Convergence layer does not provide Ethernet fuctionality over the air, only encap and class over the air

- Subnet model on 802.16

Subnet is a topological area that uses same address prefix, prefix not futher subdivided

Link is a topological area bounded by router which decrement TTL

3G like subnet - each station ahs separate prefix, only default router is neighbor

Ethernet like subnet - stations share prefix, neighbors

- Next Hop determinatin and address resolution

IP CS, no need of address resolution and ARP might be blocked

But NDP is performed at IP level

Blocking results in different IPv6 stacks for 802.16, and redudent signaling results

Ethernet CS

3G like model - next hop is IP gatway  but no wayt to force the SS's next hop because it is internal 
IP stack's decision based on the destination prefix

Ethernet like Subnet Model can not expect required change to IP...

-Autoconfig and DAD

48bit MAC can be sued

3G modle - DAD is trival only between station and Ip gateway (router)

Ethernet model - DAD for LLA might not guanrantee unique iid

-Gap Analysis

3GPP recommendation (RFC 3314)

PPP to assign unique IID

No convergence layer for PPP on .16

IP over ethernet (RFC 894)

Ethernet CS does not provide Enet funcitonality

Requires multicast emulation over connection-oriented MAC

Discussion
---------

Bernard: <missed>
James Kempf: <missed>

Jim Bound: Too many acronyms, please define. Need mesh too. MARS (for ATM) also applies. 
Look at something more esoteric, backhauling over WiMax, run 802.11 with WiMax as backbone 
like lease line. Could be mission creep, but write in charter words to look at this. 
Hastily formed networks, WiMax was used in emergency situations, need to spend some time 
on other than PMP mode. 

Erik Nordmark: Boundary between this and .16, particularly Internet CS. If broadcast and 
multicast will work, but may be expensive in large subnets. ARP or ND with not as much 
multicast as today. 6lowpan, avoid b&mcast. Need to carefully define boundary.

Parviz Yegani: Similarity of architecture to 3G model, open radio interface, easily 
specified interface on radio. Ethernet CS, ready to go, switched cloud v.s. routed cloud. 
Similar to what is already in 3GPP2 and 3GPP (iu interface). Issue is over the air. 
Do your really need to multicast over the air? No. Don't see particular concern for 
WiMax doing over R6. 

Soohong Daniel Park : 3GPP terminal doesn't have MAC address. 16 has 48 bit MAC.

Parviz: MAC address for extending multicast cloud over air, if you can't multicast, 
then the MAC address isn't useful. 3GPP IMEI, 3GPP2 ISN, don't use for multicast. 
Do you want to carry multicast traffic over the air? No.

Max Riegel: Mesh, don't go into it according current spec, new group redoing it, can't 
design based on current spec. Will take another year or two to finalize.


WiMax Forum Report
------------------

IP CS conversion sublayer interworking specifying for IPv6

Afterwards, how will it run over Ethernet CS.

Reference model. 

R1 - MN BS interface
R6 - BS to ASN-GW (first hop router for mobile) GRE tunnel here
R3 - ASN-GW to CSN

- IPv6 carried in a Transport connection

Auth/authz of MS is performed

MS sets up a transport connection
  . L2 PtP connection between MS and BS
  . GRE tunnel between BS and ASN-GW

This allows MS to send IP packets

MS receives RA or does RS

Address config, DAD, etc.

- What is NWG in WiMax Forum specifying for IPv6?

Operation of IPv6 over .16 based on IPv6 RFCs

Specifically:
. address assignment
. ND (DAD, NUD, etc.)
. DNS discovery
. Proxy DAD
. MIP6
. ICMPv6 and IPsec

Publish as an informational RFC, IPv6 over .16

- Current state

Addr assignemtn, ND, DNS discovery complete

MIP6 for WiMax will be next

IPv6 over Eth CS will be dealt with after that

- What needed from IETF

Expert reviews and guidance by the IETF

Discussion
-----------

Erik: What is subnet model?

Raj: Shared at IP, PtP at link

Erik: How many groups will be involved?

Raj: Depends on what WiMax Form needs and their timeframe. More dependency. 
NWG not trying to specify how IPv6 works.

Dave Thaler: Said like IPv6 over PPP, etc., but much more on this slide (MIP, etc). 
For E-net sublayer, should be trival, looks like e-net.

Max: .16 makes a distinction between IP over E-net, and E-net. Bridging. .16 can 
optimize IP over E-net by not supporting bridging. 

Dave: Generic ND opt., fine. Might be scary for specific .16.

Raj: Nothing specific for .16, same generic model of avoiding multicast. 
Need for that on .16 link given current deployment models. 

Dave: This is IPv6 over IPv4 over .16. GRE tunnels, are they going over IPv4? 

Raj: Yes.

Dave: Would not be there in E-net covergence layer. Why did WiMax Forum choose 
this layer instead of E-net layer?

Raj: IPv6 over E-net over IPv4, Ethernet frames are carried over GRE

Max: GRE is used for link layer mobility. Switched E-net, different possibilities. 

Raj: Optimization is what is needed over...

Bob Hinden: Using GRE for mobility, running v4, put v4 where end of pipe is. 

Bernard: What are you asking IETF to do? Asking IETF to specify IPv6 but not IPv4 over 802.16, right?

Bernard: WiMax F asking for IPv6 only?

Daniel: Yes, but scope is more than just v6.

Bernard: Issue with IETF specifying IPv4?

Raj: Yes, also a need for specifying v4.

Bernard: Lots of convergence sublayers.

Raj: IP Conv. layer is necessary.

Bernard: But only in WiMax Forum. In .16, elsewhere. Are you asking IETF to define IPv6 over IPv6 CS?

Raj: Yes. GRE tunnel is not relevent.

Bernard: Also like IPv4 over IPv4 CS, IETF define?

Raj: Yes

Bernard: Over E-net CS too?

Raj: Yes. If no multicast desired, need proxy DAD or something at ASN-GW

Bernard: Lots of covergence layers, need to focus.

Parviz: R6, IP CS is routed LAN. Almost the same as a 3GPP2 network. Default router at AG, 
layer 2 termination at MAC and PHY. Run traffic shouldn't present problem at user layer. 
For E-net CS, swithced cloud, then switching function at BS must manage proxy manner for 
mobile w. MAC translation. Addr resolutoin betwen MAC and IP. Disconnect over R1, no multicast 
on up link. Issue: BS to act on behalf of MS.

Raj: No, that is not necessary. The ASN-GW connects to mobile.

Max: If doing E-net, try to prevent multicast. Proxy ARP at BS. 

Jin Hyeok: MS only neighbor is ASN-GW, no need for ARP for IPv4

<unknown>: How does WiMax Forum treat QoS.

Raj: Service flow ids, set of classifiers based on IP info

<unk>: Granularity on MN, what is classifiaction parameter?

Hannas Schoefping: Link layer, classifiers using connection ids, but still a question on 
AAA and how to get it to BS

Raj: How to do IP QoS markings.

<unk>: Need a CID for each service on same MN.

Hannas: Not relevant.

IPv6 over 802.16 Framework
--------------------------

-WiMax network arch

ASN GW - knows about all nodes attached

Transport ocnnection at MAC layer.


-Design Trends

No change in IPv6 protocols

No changes in host side iimplementation

Minimal chages to network

- Proposed solution

IP link. ASN GW, BSs attached to it and MSs share same link.

-ND

Router Dis. - Send unsolicted RA, jsut do RSA/RA

Periodic RAs optional

Prefix Assignment - shared among nodes

- ND (con't)

Next hop is ASN-GW, no communicaton between stations

ADdr res. ASN-GW can proxy, but not needed

NUD, required because MN can have multiple addreses

- Addr autoconf

Gernate iids from 48 bit mac

ASN-GW must proxy, addr cache for all on link

- Proxy DAD

ASN GW maintains addre cache , leards from DAD NS

-Defends addr in the addr cache in case MS generates a dup

Addre cache entries expire

prefix lifetime expires, ms deregisgters, GRE tunnel is deleted, NS/NA exhcange with longer intervals

issues- addr cache overflow

Discussion
----------

Dave Thaler: L bit clear, A bit set can cause problems

Depending on what host does, depends on if the host sees as a multi-link subnet

2 possibilities: Actual subnet prefix (/64) or make it a /128 (single hose subnet)

say /64: L bit on or off is invisible to application. Decrement TTL, etc. breaks lots of things

say /128: fewer things break, no assumption of anyone else on subnet. This breaks assumption 
based on addr arch that addresses all have /64 prefix.

Do as much as you can to avoid breaking applications. TTL etc. assumptions may be broken.

Offlink causes problems for application protocols

Raj: .16 specific

Dave: This a generic problem, try to do it without an offlink assumption. ND proxy draft 
has an onlink assumption, L bit is on, attempt to do ND, proxy ND is done.

<discussion, didn't catch>

Dave: Data plane is exactly same as proxy.

Erik: Violate 2461

Jari Arkko (AD): Focus on what IETF needs to solve.

Samita Chakrabarti: Are these similar to 6lowpan? Would these work?

<presneter>: No

Erik Nordmark: Updated draft w. more details. Some things don't work. High level: Model where 
TTL is decremented thru ASN-GW or not? 

<presenter>: TTL is implementatation

Erik: Significant for multicast. Link local forward back on same link, router forwards, 
decrement TTL. Apps assume TTL=1, or 255 work on same link. Possible to do w.o. decrementing 
TTL, but can't create loops.

Dave: Best behavior, L bit on

Erik: Can put L bit off

Raj: Everything is as current IPv6 spec, need DAD proxy at ASN GW. Don't want NAs going out to all hosts.

Erik Nordmark: DAD, issue we don't have solution. Ensure ASN gateway knows all addresses, 
may have to invent new one. Don't DAD proxy, do DAD relay. Works with SEND. 

Raj: Can page and bring mobile up. That is a model. If ASN-GW knows all addresses, then it can do proxy,

Erik: Not SEND

Jari: This is solution space, let's concentrte on whether to form WG

Bob Hinden: 3 presentations, seemed to be talking about the same thing but slightly different. 
Alternative ways to solve? What is relationship? What are you asking IETF to do?

Raj: Last 2, working on how to specify v6 operation over .16. Addr assignment, ND, etc. are specific, 
can we have the ASN GW do proxy ND? 

Gab: Maybe clearer with charter discussion, including deliverables

Bob: What were we supposed to learn to help make decision?

Gab: First presentation only one referring to overall WG. Other 2 were referering how to make IPv6 
CS work from WiMax Forum. Attention given to that because just thinking about IPv6 over WiMax.

Jari: Request to do IPv4 and IPv6 over E-net CS, IPv6 over IPv6 CS, IPv4 over IPv4 CS. 3 things.

Gab: Charther discussion.

<unknown>: Talk about when work is done by. Business point of view, complete this work by this year.

Jari: Yes, that is what I read as well. 

Bernard: 4 work items, another question, what happens if you implement all 4 things, what happens 
if both sides support all 4?

Raj: Specify profiles

Bernard: Where?

Raj: Here

Bernard: How do both sides interoperate if they use different CS?

Raj: Yes, cna have.

Bernard: How do you figure out how to talk?

Raj: IP CS is the only mandated one. You can use it. E net CS may or may not be able to get service.

Bernard: Mandatory to implement v.s. mandatory to use. .16 mandiated IP and E-net CS, what do I do? 
Are we going to figure out this or will WiMax Forum?

Raj: Good point. Not sure. 

Gab: Maybe some guidance in deliverables.

Parviz: Is there work for IETF on this problem?

Bernard: Not a protocol, just deconfusion. Link layer makes preference, negotiate done. Need extra 
guidance to avoid interop problems. 

Bob Hinden: We used to have 2 ways to do stuff over E-net. One way has died away. Even having those
two created lots of problems, expense. Bug reports. Is this what we are talking about? Or is this 
like E-net and Token ring because it is two different media types, which is OK.

Gab: Enough information in .16 frame to tell which convergence sublayer to use. In 802 v.s. E-net, wasn't told.

Bob: You could tell w. old 802 v.s. E-net, people forced to do both, expensive, added no value.

Gab: Choosing one is good?

Bob: Really good.

Gab: WiMax and WiBro have chosen one.

Bob: IEEE has chosen not chosen.

Max: .16 spec does not choose, but WiMax Forum has specified IP CS only. 

Bernard: E-net is manditory.

Max: CS is defined to handle, configuration

Bernard: Intent to use one at a time? 

Max: Terminal takes one, BS supports both. Terminal has a set of functionality, terminal chooses 
whether to use E-net CS or IP CS. Single host terminal will use IP CS, others E-net CS.

Bob: Terminals work on lots of things at the same time, might try to come up on all at once. 

Daniel: .16e mobility environment, .16 and .16d is nomadic. 

Bernard: Convergence sublayer is the same?

Daniel: WiBro (.16e), IP CS is mandatory, not use E-net CS. 

Bernard: Mandatory to implement v.s. mandatory to use. Need to clarify this. Negotiate one ok, 
but multiple is confusion.

Jari: We've ratholed. Multiple CS is confusing, .16 will be the experience we remember for the 
next 10 years, what can we do? Perhaps we might select one, also need to take into account that 
other ways to do it. For WG.

Dave: Question on IP CS. Same IP CS is used for v4 and v6?

Gab: IPv4 CS and IPv6 CS

Dave: What is mandatory?

Bernard: E-net and IPv4.

Dave: Requirements distinction? 

Max: Profie work in WiMax Forum. Mobile profile madandates IPv4 CS and IPv6 CS, IPx o. E-net 
is optional.

Raj: WiMax Forum has own mandates. v4 and v6 CS are mandatory. But .16 says v4 and E-net CS. 
WiMax Forum is interested in only v4 and v6 CS.

<unknown>: Charter needs to be explicit about what CS this group will consider. RFC 3314, 
3G model, will this be excluded or later examine if applicable? Need to focus, put these 
issues in charter.

Gab: Need to discuss problem statement. 

<unk>: Don't use it, then we have problems. 

Gab: WG is venue to discuss issues. Strict deadlines, longer we take here, the less influence 
we will have.

Jari: Question is WG have enough room to work. Is closed issue?

Raj: Junghoon presented gap analysis. Link model is different so RFC 3314 doesn't apply.

Erik N: WiMax priorty is what they have picked. Prioritize. 

Gab: Nothing in initial charter on IPv4, but now widening charter.

Erik N: Constrain, 4th bullet is vague, but others are clear.

Gab: Deployment scenerio

Erik N: 4th bullet is any scenerio deployment? 

Bob Hinden: Need to include co-ordination w. other WGs like 6lowpan, formalize in charter. 
v4 and v6 over the v4 or v6 CS, what about E-net CS discussion? 4th doc, need to define 
transition model of dual stack. 

Raj: Not dealt with in WiMax Forum. v6 CS, it is a v6 network, no transition at this point.

Bernard: Mixing too much in docs, separate out: v6 over v6 CS, etc. Some other things might 
not need a problem statement document.

Gab: We got message out of Vancouver, need PS

Raj: PS is still too confusing. 

Gab: Constrained charter. Results of questions asked by ADs (slide).

Related activites:

- IPv4 WiBro deployment in June
- IPv6 Ready branding by IPv6 Forum

Q. Should the IETF do the work in this area?

YES: <lots>

NO: 5 

Q. Should the IETF charter this proposed 16ng WG?

YES: <lots but fewer> 

NO: 5

Q. Of the above, do you have time to work on this (editing, reviewing, etc.)?

YES: <lots> 20-30

Jim Bound: Don't agree about mesh, very important. Can we discuss?

Gab: Document isn't there.

Jim: Document is there, but we would have to work out access. MARS, argue that, go through process, or what? 

Gab: WG is here for 2 years, recharter.

Jim: Option for recharter to cover. 

Jari: Always an option for that.

Daniel: 16 mesh is a study group.


Q. Do you think the charter is fine already?

Gab: No we need to work on it.


Q. Should the WG work on IPv4 in addition to IPv6?

Jari & Gab: This was approved by discussion.

Q. How many in the room participate in:

- IEEE 802.16 - 10

- WiMax - 25

- WiBro - 12

Individual presentations
-----------------------
<missed title>

<repeat discussion of NDP problems with .16>

Solution: multicast emulation

Multcast relay w. relay in AR

Use repeated unicast

<missed title>

MTU, stateless autoconfig, farme format and encap, unicast and multicast transmission.

frame format for the E-net and IPv6 CS.

address mapping different

subnet models different.

+++++++++++++++++++++++[END]+++++++++++++++++++++++++


Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.
From [e-mail] Mon Mar 27 19:04:40 2006
Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131])
	by eeca16.sogang.ac.kr (8.12.8/8.12.8) with ESMTP id k2RA4eIB021420
	for <[e-mail]>; Mon, 27 Mar 2006 19:04:40 +0900
Received: from etri04q4sqc7zc ([129.254.12.66]) by email1.etri.info with
	Microsoft SMTPSVC(6.0.3790.1830);	 Mon, 27 Mar 2006 18:24:08 +0900
From: "Junghoon Jee" <[e-mail]>
To: "'Soohong Daniel Park'" <[e-mail]>,
   <[e-mail]>
Subject: RE: [16ng] Meeting notes
Date: Mon, 27 Mar 2006 18:21:27 +0900
Message-ID: <078a01c6517f$d3a65e70$420cfe81@etri04q4sqc7zc>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcZOnIRpbN7qAQZNRD+w29YlxfSA9wC4TYkA
In-reply-to: <020501c64e9b$ed8658e0$f6828182@daniellaptop>
X-OriginalArrivalTime: 27 Mar 2006 09:24:08.0321 (UTC)
	FILETIME=[3331E710:01C65180]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1
Precedence: list
List-Id: IPv6 over IEEE 802.16(e) Networks <16ng.eeca16.sogang.ac.kr>
List-Unsubscribe: <http://eeca16.sogang.ac.kr/mailman/listinfo/16ng>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://eeca16.sogang.ac.kr/pipermail/16ng>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://eeca16.sogang.ac.kr/mailman/listinfo/16ng>,
	<mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 27 Mar 2006 10:04:40 -0000

Hi,  

> Bernard: <missed>
> James Kempf: <missed>

It's a pity to see the blank here.
Actually there were several replies from myself and Max here about the
questions and comments
from Bernard and James.
If no body has a detailed memory regarding this, I would summarize the
discussion based on my memory.
Let me wait to see who can kindly fill this blank.
It's really time consuming to re-work to compete the meeting minute.
It's a pity to see again the incomplete minute even if we already had
same experience from the previous BoF.
However, I would like to stress the importance of the complete minute
because the discussion needs to be opened who cannot join the offline
meeting unfortunately.

> Raj: PS is still too confusing. 

Raj,
I need to check for clarification.
What is confusing to you?
The presentation done by myself? or the PS I-D in the current format?
Even if it is really energy and time consuming, I am really thinking
about volunteering to rework PS I-D. 
If anyone is volunteering for this job, please let me know.

Thanks,
-Junghoon