Subject: [16ng] Subnet Model Analysis for 16ng

From: "Syam Madanapalli" <[email-masked]>
Date: Wed, 6 Sep 2006 19:19:02 +0530

Hi,

We made some analysis of subnet models for IPv6,
please review and comment.
I have attached the text document with this mail as
the draft has not been published yet.

Thanks,
Syam
_______________________________________________
16ng mailing list
[email-masked]
http://eeca16.sogang.ac.kr/mailman/listinfo/16ng

---

From: <[email-masked]>
Date: Wed, 6 Sep 2006 16:12:30 -0400

A few questions 

On ...
3.3.3.  Duplicate Address Detection

Does adding something like "such as BS performaing relay DAD-like
functions for MS under itself" make sense? Of course, it needs to be
worked out somewhere like the shared prefix model, but I recall that
some early systems do something similar and it has smaller scope, just
for a BS instead of an AR.

On..
3.3.4.2. On-link Multicast Support & 3.3.4.5.  Effect on Dormant Mode
I wonder if it makes sense to consider that BS can potentially block
broadcast/multicast with known purposes to MS that do not need it and
deliver only to intended MS MAC unicast over the air. 
An 802.16 BS is already involved in many activities that require
awareness of higher layer states beyond MAC (regrettably to some), so
knowing necessary information may not be a big additional burden. Also,
a BS needs and can act with only local information.
Also IGMP/MLD snooping can be used for additional cases, as some
ethernet switches already do. And finally, broadcast/multicast with
unknown functions will have to be left to a policy and maybe subject to
rate limits like many 802.11 implementations, where practical
experiences to come will help guide the usage.

I guess the common thing is that BS's are already very specialized nodes
for 802.16, so I'd be inclined to limit 802.16 specifics to BS and not
bother AR, even if there is some penalty in other aspects. (though I
have not seen something that'd concern me too much yet.) If all or most
of 802.16 specifics are handled at BS using only local knowledge, there
will be even less interop issues.

I apologize if I'm out of context, for I am not there at the meeting
following the discussions.

Bests.

"J" Kim
[email-masked]
AT&T Labs - Research

http://macsbug.googlepages.com/

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Syam Madanapalli
Sent: Wednesday, September 06, 2006 9:49 AM
To: [email-masked]
Subject: [16ng] Subnet Model Analysis for 16ng

Hi,

Thanks,
Syam

---

From: Myung-Ki Shin <[email-masked]>
Date: Thu, 07 Sep 2006 10:02:13 +0900

Hi J,

Thanks for your comments.
Inline ...

> for a BS instead of an AR.

I think there are several ways to implement the DAD optimization
(e.g., relay DAD, proxy DAD, or some vendor-specifc functions).  Also, 
BS, AR or both can perform that kind of fuctions for MS.

In my understanding, the goal of this draft is to provides analysis and
applicability of each subnet model.  So, the isssue above can be 
discussed in solution documents for IPv6 CS and Eth-CS, respectively.

> experiences to come will help guide the usage.

I know and I agree that this issue is very important for dormant mobile 
node. There are strong and weak points with this approach above.
Also, sometimes it might be not specific to IPv6 solutions and
morevover this may be a kind of BS implementation issues.

> will be even less interop issues.

I wonder if we can define or discuss about BS and/or AR behaviors here,
that is, omniscient AR and dummy BS vs. omniscient(?) BS and general AR,
even if interop issues are important, of course.

Thanks,
Myung-Ki,
ETRI

---

From: Pars Mutaf <[email-masked]>
Date: Thu, 07 Sep 2006 16:42:41 +0200

Hi, 

Thanks to the contributors for this draft. 
I have a quick question. Have you decided
that in 16ng:

Subnet = paging area?

Thanks,
pars

---

From: <[email-masked]>
Date: Thu, 7 Sep 2006 11:01:52 -0400

Your comments appreciated...

Although this thread is on the subnet model analysis, I guess I was
commenting a bit broadly.

Some comments..

"Also, BS, AR or both can perform that kind of functions for MS."
>> Of course, but I'd prefer BS than AR, since BS only needs to defend
MS under it which I believe is more realistic and of limited scope,
given the way 802.16 works, while AR indeed needs to know everyone. In a
similar spirit as "802.16 specifics is unavoidable at BS, so try not to
rope in AR as well".

"In my understanding, the goal of this draft is to provides analysis and
applicability of each subnet model. "
>> Agreed. However, any analysis is bound to imply some directions to
solutions. It'd be very useful to indicate the desirable properties of
potential solutions, whatever they may be.

"There are strong and weak points with this approach above"
>> I'd like to discuss that, online or offline if inappropriate for this
thread.

" this may be a kind of BS implementation issues"
>>  It may still be useful to put forth desirable properties, or
best/recommended practices in some other docs.

" omniscient AR and dummy BS vs. omniscient(?) BS and general AR"
>> I think omniscient BS needs to be only omniscient about its own MS's,
which is a relatively weak requirement, given how 802.16 works.
Nonetheless, a full description of such spectrum of approaches is
probably not needed in this doc, but may be something to keep in mind
during the design stage.

Byoung-Jo "J" Kim
[email-masked]
AT&T Labs - Research

-----Original Message-----
From: Myung-Ki Shin [mailto:[email-masked]] 
Sent: Wednesday, September 06, 2006 9:02 PM
To: Kim,Byoung-Jo J (J)
Cc: [email-masked]
Subject: Re: [16ng] Subnet Model Analysis for 16ng

Hi J,

Thanks,
Myung-Ki,
ETRI

---

From: "Syam Madanapalli" <[email-masked]>
Date: Thu, 7 Sep 2006 20:31:54 +0530

Hi Pars,

> I have a quick question. Have you decided

No.

And do you see any reason to tie these two things together?
If point-to-point subnet model is considered, there will be
essentially only one node in the paging area if subnet = paging area,
which I think is not effective way of doing the paging.

Thanks,
Syam

---

From: Pars Mutaf <[email-masked]>
Date: Thu, 07 Sep 2006 17:18:53 +0200

> And do you see any reason to tie these two things together?

Hi Syam,
No particular reason. 

(Subnet=PA is the simplest approach. But I agree that this 
may be too restrictive.)

> which I think is not effective way of doing the paging.

:-)

Thanks again for the draft

pars

---

From: Pars Mutaf <[email-masked]>
Date: Thu, 07 Sep 2006 18:00:55 +0200

Hi, 

On Thu, 2006-09-07 at 08:52 -0700, Behcet Sarikaya wrote:

> ==> I think that PA should be the coverage area under an AR (or
> ASN-GW) which might
> ==>include many BSs (this is from IP Paging point of definition). 
> ==>In the shared prefix model, this translates to subnet=PA, but in
> the per-MS prefix model
> ==>it does not, PA=all BS's under AR is probably better definition.

OK. Paging is the responsibility of AR, in this case. Right?

I'd like to ask another question if 
possible: 

     Neighbor discovery = paging?

That's my impression. But I'm not sure.

If so, does the AR know the current BS of the dormant host?

Thanks! 
pars

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 7 Sep 2006 08:52:38 -0700 (PDT)

----- Original Message ----
From: Pars Mutaf <[email-masked]>
To: Syam Madanapalli <[email-masked]>
Cc: [email-masked]
Sent: Thursday, September 7, 2006 10:18:53 AM
Subject: Re: [16ng] Subnet Model Analysis for 16ng

Hi Syam,
No particular reason. 

:-)

==> I think that PA should be the coverage area under an AR (or ASN-GW) which might
==>include many BSs (this is from IP Paging point of definition). 
==>In the shared prefix model, this translates to subnet=PA, but in the per-MS prefix model
==>it does not, PA=all BS's under AR is probably better definition.
Thanks again for the draft

pars

> > > the draft has not been published yet.
==> I checked in WiMAX documents, they use paging group which corresponds to paging area
==>In 802.16e it says that a BS may be a member of one or more paging groups 
==>My 0.5 cents.
 
--behcet

---

From: Thomas Narten <[email-masked]>
Date: Thu, 07 Sep 2006 13:31:53 -0400

One question I have wrt this document. It is asserted (without
justification) that "DAD is too expensive" and special extensions will
be needed. Where is this justified and where is the exact problem with
DAD explained?

I assume the issue is that multicast is expensive or doesn't work. But
then, ND in general is a problem also.  But I don't see ND being
listed as problematic, even though it is based on multicast.

What am I missing?

Thomas

---

From: "Syam Madanapalli" <[email-masked]>
Date: Fri, 8 Sep 2006 07:15:01 +0530

Hello Thomas,

> be needed. Where is this justified and where is the exact problem with

The next version of the document either contain the text or a reference
for this.

> listed as problematic, even though it is based on multicast.

802.16 MAC transport connection exists between MS and AR. (This
is based on current WiMAX Network model). And there will be no such
transport connection to any other MS. So it is possible to restrict ND
between MS and AR, which does not require the multicast support.
When prefix is being shared with multiple MSs, the DAD somehow
should reach all the MS for which multicast support is required.

Thanks,
Syam

---

From: "JinHyeock Choi" <[email-masked]>
Date: Fri, 8 Sep 2006 13:38:45 +0900

Dear Thomas

> I assume the issue is that multicast is expensive or doesn't work.

yes.

> But

In shared prefix model, we managed to run ND without multicast by
imposing a few restrictions to simplify network. There is only one
access router and an MN's (known) on-link neighbor is only its AR. All
ND procedures (such as address resolution) can be performed between an
MS and its AR without concerning other nodes except DAD.

Thanks for your kind consideration.

Best Regards

JinHyeock

---

From: Thomas Narten <[email-masked]>
Date: Fri, 08 Sep 2006 08:35:43 -0400

> MS and its AR without concerning other nodes except DAD.

I think it would be helpful to have subsections in the document that
explain how ND works (or is assumed to work, once (current unstated!)
assumptions are made) in each case.

Thomas

---

From: "Syam Madanapalli" <[email-masked]>
Date: Fri, 8 Sep 2006 23:58:56 +0530

Link to the draft:
http://www.ietf.org/internet-drafts/draft-madanapalli-16ng-subnet-model-analysis-00.txt
_______________________________________________
16ng mailing list
[email-masked]
http://eeca16.sogang.ac.kr/mailman/listinfo/16ng

---

From: qinxia <[email-masked]>
Date: Sat, 09 Sep 2006 12:03:03 +0800

Hello all,

           IMHO, The overlap between Paging area and the coverage area under
a AR does not mean 

" Neighbor discovery = paging?" 

A relay Paging controller function may be provided by an AR(ASN-GW), so, I
think, the AR may know the dormant hosts.

If I miss something or misunderstanding something, let me know,  Thanks.

BR
Alice 

> [mailto:[email-masked]] On Behalf Of Pars Mutaf
> Sent: Friday, September 08, 2006 12:01 AM
> To: Behcet Sarikaya
> > the per-MS prefix model ==>it does not, PA=all BS's under AR is 
> > probably better definition.
> 
>

---

From: Pars MUTAF <[email-masked]>
Date: Mon, 11 Sep 2006 20:00:46 +0200

Hi Alice,

Personally, I don't know currently what kind of
paging service will be provided in 16ng.

But, a priori, I would vote for ND-based paging.

It can be reused for future wireless access protocol
perhaps.

Regards,
pars

> > If so, does the AR know the current BS of the dormant host?

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
_______________________________________________
16ng mailing list
[email-masked]
http://eeca16.sogang.ac.kr/mailman/listinfo/16ng

---

From: qinxia <[email-masked]>
Date: Tue, 12 Sep 2006 09:12:17 +0800

Thread-index: AcbVzLTMvB8HEGSbSLOSJL7bsrTYTgAO2IKQ

Hello Pars,
    
           Could you kindly introduce "ND-based paging"  in WiMAX? Or could
ND-based paging  be used in WLAN and so on, as you say, it looks like a
general paging appoach?
 
        Thanks

 BR

Alice

> [mailto:[email-masked]] On Behalf Of Pars MUTAF
> Sent: Tuesday, September 12, 2006 2:01 AM
> To: qinxia
> Subject: RE: [16ng] Subnet Model Analysis for 16ng
> 
> 	<mailto:[email-masked]?subject=subscribe>
> List-Unsubscribe: <http://eeca16.sogang.ac.kr/mailman/listinfo/16ng>,
> 	<mailto:[email-masked]?subject=unsubscribe>
> List-Archive: <http://eeca16.sogang.ac.kr/pipermail/16ng>
> List-Help: <mailto:[email-masked]?subject=help>
> List-Id: IP over IEEE 802.16 Networks <16ng.eeca16.sogang.ac.kr>
> 
> 
> Hi Alice,
> 
> Personally, I don't know currently what kind of paging 
> service will be provided in 16ng.
> 
> It can be reused for future wireless access protocol perhaps.
> 
> Regards,
> pars
> 
> 
> >            IMHO, The overlap between Paging area and the 
> coverage area 
> > under a AR does not mean
> >
> > A relay Paging controller function may be provided by an 
> AR(ASN-GW), 
> > so, I think, the AR may know the dormant hosts.
> >
> > > > ==>In the shared prefix model, this translates to 
> subnet=PA, but 
> > > > in the per-MS prefix model ==>it does not, PA=all BS's 
> under AR is

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 12 Sep 2006 09:23:15 -0700 (PDT)

In the interest of letting people know what we were up to in the first day of the meeting, here are my hasty notes. These are not the official interim meeting minutes, which will come later, but just an attempt at keeping folks in the loop.

-gabriel

Steigenberger Hotel, Mannheim
   
  AGENDA
   
  Sep 12, Tuesday
   
  1000 - 1030      Coffee break & socializing 1030 - 1230      Opening session Welcome host       and chairs Max provided        welcome and overview of our host (Siemens Communications, to be merged        with other companies like Nokia)18billion         Euro revenue60k         employees160         countriesThanks to        Siemens and MaxAgenda bashing       chairs WG status and       milestone review chairs Some revised        text in the milestones and charterLook at notes        in presentationInformative       reports WiMAX IPv6        activities - Jin Hyeok ChoiLed by Raj,         to run ND (2461/62) over SiMAXSec. 5.11         for stage 3 documentASN and ASN         GW = subnet and routerIn v4: ASN          GW is L2 fwding, in v6 not clear yetNo         mcast/bcast (but MBS might add some stuff here)No direct         comm between MSsR6         (BS-ASNGW) on GRE (per MS at least)Through BSGRE tunnel802.16           transport connectionLink def?All         
 connections a a single link (shared prefix)Needs           relay DADPer -MS          prefix:Like 3gppP2p MS-           ASN GWOn-link           comm & mcast trivial (DAD is easy)Per MS RAASN GW to           aggregate to avoid routing table explosionHow to           handle mobility Link is            conceptual, so even if it moves it could remain on same linkVery            similar to GGSN in 3GPPNo clear         winnerSoliciting         input from service provider (SPWG)To decide in         september16ng input         very valuableMyungki -         why is wimax deciding on any subnet model?Jonne -         seems useful to make behavior predictable for interoperability reasons,         error reporting, etcMax: both         would work if BS/ASNGW is in one boxIf in two          boxes, then should specify what happens at the BS, for exampleNWS only          defines R6, not internal behaviorIETF should          provide feedback on how feasible the shared model is.We know the   
       p-p link model is workable (3GPP)Q from Jin         Hyeok: should we follow wimax model in IETF?Jonne: would         not make sense to ignore them or to try to re-design wimaxGab: the         current milestones reflect a current focus, but we're not limited to         that so we could take on, say, mesh in the futureJari: we do         need to make sure our solutions are general enough for future         applicabilityJH: will         IPv6 CS only follow wimax model?Jari: not         sure, but wimax are the main customer, yes, so it should work with         their modelMax: you're         asking for L3 VPN, L2 is what eth CS with VLANs is doing.Public          access has led to L2 VPN Not          following the Wimax model still leaves us with requirements for a VPN          model for carriers, albeit at L3IPv6       deployment scenario v6ops document review - Myungki Shin Extends        v6ops-bb-deployment-scenarios for broadband802.16 can be        applied in many
 scenarios and architecturesWhy here in        16ng interimSubnet model         discussionLooking for         collaboration/cooperation16ng review         requested statusOfficial          v6ops in March 200601          published in septWG LC end          of the year3 scenariosMobile         access depl scenario3GPP-like         deployment (rfc 3314)Fixed/nomadic         depl scenarioImpacts        identifiedIPv6         infratructure changesAddressingIPv6 control         and data transportroutingEtcMulticast,        mobility, etcMax: comment        on L3 awarenessin wimax         model the BS is becoming L3 unaware cuz classification is done in the         ASN GWBut .16         model the BS is L3 awareJari: what is        DAD optimization? Something new?A: in shared        prefix model, yes, something like relay DADDaniel: yes,        but this is only on nw side, not on host sideMax: your        document mixes models3rd model is         really many models, so should split
 these up into the basic models or         subsetsEach subset         with different optimizationsIn eth CS         case we're trying to address all (single MS, prefix delegation for         hosts behind an MS, etc)Q: is nw        behind an MS in 16ng?Max: not, but        there are implications Brian        Carpenter asked in the light of iab-link-encaps how roaming will work        when moving from one CS to anotherMax: wimax        also needs to solve this problemEvery access         nw provides the basic IP CS (v4 now)802.16 says         nothing about what the MUST implement isLink-encaps         does not apply here as wimax only has one way to do encaps at a given         point in timeIf payload          is eth, use eth csIf payload          is IP, use IP csThere's a         very easy way for ETH deployment to provide IP CSMax to send         this short text outText to be          added to 16ng docsJari: good,        the IETF does need this to be solvedDanielNeed to    
     agree on terminology with DT documentNeed to         avoid duplication of content with DT documentMaxYes we need         common terminologyAlso need         normative description of scenariosJari:But it seems         wrong to describe scenarios that don't reflect real deploymentsScenario         consolidation is a good idea.   
  1230 - 1330      Lunch 1330 - 1530      Technical session I Data       forwarding mechanism within ASN (with service flow and GRE tunnel) - Max       RiegelMust        accommodate IPv4 in which many MS may use the same address spaceTunnels over        the air identified by CID - conn identifierAssigned to a        GRE connection (GRE key) for forwarding over R6 (BS to ASN GW) In 802.16        there are 3 control plane CIDs different from data plane CIDs (above)Primary Secondary -         schedulingMgmt - snmpConv        sublayersClassifications         (11 in 16e)Classification         done using L3 informationWimax         prefers classification to be done in ASN GW to avoid BS complexityMultiple CS        types in a BSMgmt/control         is common and agnostic of CS typeNo CS for         PPP, but PPPoE might be a way:GP CS could          help by removing need for classification at the BSBRAS could          map diffserv to eth service, but no current specification of
 BRAS to          ASN GW interface (for release 1.5)R6: BS to ASN        GW in a routed ASNGRE for both         ETH and IP CSGRE keys          are eitherPer flow           (per CID) - must be done for R4 (inter ASM)Per MS, in           which case the BS must do the final classification if a given MS has           more than one CIDBridged         ASN(R6) is for further studyData plane         encapIP* CS: IP          over GREIP*oETH CS:          IP over ETH over GREETH CS: ETH          over GRELink modelIPv4: GRE         tunnels go into a bridge (switch model) sitting before the ASN GWIPv6: GRE         tunnels go directly into the ASN GW (no bridge)Uses relay          DAD and authoritative address cacheIPv6oETH CSExtend          bridge with relay DAD and authoritative address cacheMax to          document a concern of Jari's about optimizations introducedsynchronicity           of state in the IPv6 caseAre there            any holes? Can the            address cache really
 be authoritative?How to            re-establish state if something is lost?Are we           opening new DoS attacks from the internet (triggering lots of ND           traffic, for example)IPv6 subnet       model design team report - Daniel on behalf of SyamAnalyze        subnet modelsMake a        recommendationNBMA link        model (shared prefix)Relay DADOne prefix         (or more)P-P link        model (unique prefix model)How to         support this?PPP does          not existPerhaps to           be removedPer MS GRE          connection - preferredVLAN tag          802.1q may not be sufficient (only 4K)Not the           right technology for this problem (limiting a VLAN to a single host           is not the expected use of VLANs)Mcast capable        link model (ethernet-like model)Supports         full mcast with bridgingBS filters         multicast to not deliver unwanted packets to MSs not part of a groupShould we         rename it the IEEE 802 segment model?All
 models        support autoconf and DHCPv6DADNbmaRelay DADAddress          cachep-p DAD         required for link local addressesMcast         capableAs per 2462Stds - all        reuse themOn-link mcastNbma via         proxyingp-p only 2         nodesEthernet         fineConsistency        of IP modelPkt        forwardingNbma: bridge         local pkts, route external onesDormant modeEthernet-like:         BS must implement filtering or better, should be handled to reduce the         effectJonne: but         this is an L2 issue, not something 16ng needs to sayMax: but         this trouble is caused by IP behavior by assuming mcast or bcast does         not costJari: fair         enough, but another equally dubious assumption is that these packets         are not needed and one can elide themHost        implementations: no changes we hope (error conditions in the cache may        change this)Router        implementationsNbma - relay         DAD and address cache (may not be
 complete due to pkt loss, etc)p-p: unique         prefix assignment, as usualMcast         capable: bridging is requiredRenumberingp-p more         signaling than nbma?Jonne and          Jari: not soOne RA per          hostSeNDAll models         support thisApplicabilityMobile wimax         and wibro: IP CSFixed and         nomadic: ETH CS  1530 - 1600      Coffee break 1600 - 1800      Technical session II IPv6 solution       discussion - I IPv6 shared        prefix model over IPv6CS - Jin Hyeock ChoiIssue with         no link-scope mcastNo globally         unique link-level addr in .16 frameHost's only         on-link neighbor is its ARExploit         wimax featuresOmniscient          AR - knows all IPv6 addresses in use on a linkISF initial          service flowHost to AR           via BS connectionISF can be           used for RS/RA or NS/NAYes, even            with unspecified src addrSolutionL bit off,          A-bit potentially onOnly the AR          is a neighbor
 to an MSNo direct          MS to MS communicationASN GW is          omniscient ARMAC          transport conn = .16 on + GREISF is          state between MS and ASN GW so RS can elicit the appropriate RA going          to the correct MSGRE key          used as the replacement for a MAC addressNon-standard           extension to 802.16, which does not include a GRE key as one of the           parameters used for classificationAddr resol          and NUD only done between MS and GWSkip in           the future?Jari: not           the conclusion in 3GPP meetings, cuz reachability is a two-way thing,           don't eliminate NUD, but you can use payload packets to elide itDAD is          performed using relay DADRelay DADGW has addr          cache Learns from          DAD NSMS helps to          build cache with NUDMS sends NS          using ISFGW makes a          record and drops it if no matchIf match,          the GW relays NS to addr owner, owner responds, GW forwards to MS,
 MS          processes as usualissuesQ: the           addr cache may grow without limit, no mechanism to reduce or clean           the cache, whereas in per-MN prefix there is no such growing quantityIn per-MS           prefix model, there is a detachment procedure (or timeout) which           cleans the cache of prefixes. Moving an           MS from one BS to another is *NOT* a detachment procedure, as the           link is still activeWhy this         model? A: to save address space, but not neededEach          carrier gets a /32 (today's internet) and can get othersEach user          gets a /48Jonne:          "Each /64 prefix is like an addr in IPv4"This is          being done for 3G, HSDPA, etcJonne:This we          looked into for 3GPP, and back in 2001 we saw issues with address          cache managementPer-MS          Prefix management is much simplerRfc 3314          still holdsAddress          space is not an issueOperators          are fine with per-prefixIPv6
 unique        prefix model over IPv6CS - Jonne Soininen presenting the draft by frank        xia, behcet and rajVirtual link         vs physical linkID, prefix,          CID, etcPrefix         assignmentFast router          discovery via unsolicited RASolicited          RAPeriodic RANDBusiness as          usual for NS/NA/RS/RA, autoconfDAD: use          optiDAD (rfc4429) cuz low possibility of duplicationDormant modeLimited #          of nodesIssuesPrefix mgmt          - dhcp relay           in AR, or simplest,           table in AR with prefixesRoute flip          upon mobilityRoute           aggregation of /64's under a /48 so no issue visible outsideEnough          prefixesAnalysis           in sec 2.3.1 of rfc 3314Ex: about           80,000 prefixes per person on earth todayConclusionsPer-MS          model fits naturally to p-p linksDHCP can be          managed using DHCPEnough          prefixes (no address depletion currently foreseen)No impact          to host
 stacksAll others          (DSL, 3GPP, etc) assigning prefixes, not IP addresses to MSSo why           make Wimax worse?One can          ship now with pre-MS prefix and if there is any issue in the future          with prefix space depletion, then one can always specify shared subnet          model in the futureSome       additional discussion on multiple PDP contexts in 3GPPNo equivalent        in wimaxComplicates        user interface tremendously, a nightmareJari and        Jonne: might have happened because of a misunderstanding on the part of        3GPP about how IP works  1900 - 2200      Social

---

From: gabriel montenegro <[email-masked]>
Date: Wed, 13 Sep 2006 05:53:38 -0700 (PDT)

Folks,

Please find the hasty notes for both days of the interim, including the tentative conclusions of the break-out sessions at the end of this message.
I also attach the agenda slides augmented with the break-out session tentative conclusions.
Thanks to Max and Siemens for being such gracious and generous hosts. 

To the participants: these are very hasty notes with no editing so errors and omissions are guaranteed. Please provide the 
appropriate corrections or suggestions for rewording as we hammer these into the minutes for the meeting.

thanks,

-gabriel
   
  o 1st Interim - Mannheim, Gernamy
  o September, 12nd - 13rd
   
  ========================================
  Steigenberger Hotel, Mannheim
   
  AGENDA
   
  Sep 12, Tuesday
   
  1000 - 1030      Coffee break & socializing 1030 - 1230      Opening session Welcome host       and chairs Max provided        welcome and overview of our host (Siemens Communications, to be merged        with other companies like Nokia)18billion         Euro revenue60k         employees160         countriesThanks to        Siemens and MaxAgenda bashing       chairs WG status and       milestone review chairs Some revised        text in the milestones and charterLook at notes        in presentationInformative       reports WiMAX IPv6        activities - Jin Hyeok ChoiLed by Raj,         to run ND (2461/62) over SiMAXSec. 5.11         for stage 3 documentASN and ASN         GW = subnet and routerIn v4: ASN          GW is L2 fwding, in v6 not clear yetNo         mcast/bcast (but MBS might add some stuff here)No direct         comm between MSsR6         (BS-ASNGW) on GRE (per MS at least)Through BSGRE tunnel802.16           transport connectionLink def?All         
 connections a a single link (shared prefix)Needs           relay DADPer -MS          prefix:Like 3gppP2p MS-           ASN GWOn-link           comm & mcast trivial (DAD is easy)Per MS RAASN GW to           aggregate to avoid routing table explosionHow to           handle mobility Link is            conceptual, so even if it moves it could remain on same linkVery            similar to GGSN in 3GPPNo clear         winnerSoliciting         input from service provider (SPWG)To decide in         september16ng input         very valuableMyungki -         why is wimax deciding on any subnet model?Jonne -         seems useful to make behavior predictable for interoperability reasons,         error reporting, etcMax: both         would work if BS/ASNGW is in one boxIf in two          boxes, then should specify what happens at the BS, for exampleNWS only          defines R6, not internal behaviorIETF should          provide feedback on how feasible the shared model is.We know the   
       p-p link model is workable (3GPP)Q from Jin         Hyeok: should we follow wimax model in IETF?Jonne: would         not make sense to ignore them or to try to re-design wimaxGab: the         current milestones reflect a current focus, but we're not limited to         that so we could take on, say, mesh in the futureJari: we do         need to make sure our solutions are general enough for future         applicabilityJH: will         IPv6 CS only follow wimax model?Jari: not         sure, but wimax are the main customer, yes, so it should work with         their modelMax: you're         asking for L3 VPN, L2 is what eth CS with VLANs is doing.Public          access has led to L2 VPN Not          following the Wimax model still leaves us with requirements for a VPN          model for carriers, albeit at L3IPv6       deployment scenario v6ops document review - Myungki Shin Extends        v6ops-bb-deployment-scenarios for broadband802.16 can be        applied in many
 scenarios and architecturesWhy here in        16ng interimSubnet model         discussionLooking for         collaboration/cooperation16ng review         requested statusOfficial          v6ops in March 200601          published in septWG LC end          of the year3 scenariosMobile         access depl scenario3GPP-like         deployment (rfc 3314)Fixed/nomadic         depl scenarioImpacts        identifiedIPv6         infratructure changesAddressingIPv6 control         and data transportroutingEtcMulticast,        mobility, etcMax: comment        on L3 awarenessin wimax         model the BS is becoming L3 unaware cuz classification is done in the         ASN GWBut .16         model the BS is L3 awareJari: what is        DAD optimization? Something new?A: in shared        prefix model, yes, something like relay DADDaniel: yes,        but this is only on nw side, not on host sideMax: your        document mixes models3rd model is         really many models, so should split
 these up into the basic models or         subsetsEach subset         with different optimizationsIn eth CS         case we're trying to address all (single MS, prefix delegation for         hosts behind an MS, etc)Q: is nw        behind an MS in 16ng?Max: not, but        there are implications Brian        Carpenter asked in the light of iab-link-encaps how roaming will work        when moving from one CS to anotherMax: wimax        also needs to solve this problemEvery access         nw provides the basic IP CS (v4 now)802.16 says         nothing about what the MUST implement isLink-encaps         does not apply here as wimax only has one way to do encaps at a given         point in timeIf payload          is eth, use eth csIf payload          is IP, use IP csThere's a         very easy way for ETH deployment to provide IP CSMax to send         this short text outText to be          added to 16ng docsJari: good,        the IETF does need this to be solvedDanielNeed to    
     agree on terminology with DT documentNeed to         avoid duplication of content with DT documentMaxYes we need         common terminologyAlso need         normative description of scenariosJari:But it seems         wrong to describe scenarios that don't reflect real deploymentsScenario         consolidation is a good idea.   
  1230 - 1330      Lunch 1330 - 1530      Technical session I Data       forwarding mechanism within ASN (with service flow and GRE tunnel) - Max       RiegelMust        accommodate IPv4 in which many MS may use the same address spaceTunnels over        the air identified by CID - conn identifierAssigned to a        GRE connection (GRE key) for forwarding over R6 (BS to ASN GW) In 802.16        there are 3 control plane CIDs different from data plane CIDs (above)Primary Secondary -         schedulingMgmt - snmpConv        sublayersClassifications         (11 in 16e)Classification         done using L3 informationWimax         prefers classification to be done in ASN GW to avoid BS complexityMultiple CS        types in a BSMgmt/control         is common and agnostic of CS typeNo CS for         PPP, but PPPoE might be a way:GP CS could          help by removing need for classification at the BSBRAS could          map diffserv to eth service, but no current specification of
 BRAS to          ASN GW interface (for release 1.5)R6: BS to ASN        GW in a routed ASNGRE for both         ETH and IP CSGRE keys          are eitherPer flow           (per CID) - must be done for R4 (inter ASM)Per MS, in           which case the BS must do the final classification if a given MS has           more than one CIDBridged         ASN(R6) is for further studyData plane         encapIP* CS: IP          over GREIP*oETH CS:          IP over ETH over GREETH CS: ETH          over GRELink modelIPv4: GRE         tunnels go into a bridge (switch model) sitting before the ASN GWIPv6: GRE         tunnels go directly into the ASN GW (no bridge)Uses relay          DAD and authoritative address cacheIPv6oETH CSExtend          bridge with relay DAD and authoritative address cacheMax to          document a concern of Jari's about optimizations introducedsynchronicity           of state in the IPv6 caseAre there            any holes? Can the            address cache really
 be authoritative?How to            re-establish state if something is lost?Are we           opening new DoS attacks from the internet (triggering lots of ND           traffic, for example)IPv6 subnet       model design team report - Daniel on behalf of SyamAnalyze        subnet modelsMake a        recommendationNBMA link        model (shared prefix)Relay DADOne prefix         (or more)P-P link        model (unique prefix model)How to         support this?PPP does          not existPerhaps to           be removedPer MS GRE          connection - preferredVLAN tag          802.1q may not be sufficient (only 4K)Not the           right technology for this problem (limiting a VLAN to a single host           is not the expected use of VLANs)Mcast capable        link model (ethernet-like model)Supports         full mcast with bridgingBS filters         multicast to not deliver unwanted packets to MSs not part of a groupShould we         rename it the IEEE 802 segment model?All
 models        support autoconf and DHCPv6DADNbmaRelay DADAddress          cachep-p DAD         required for link local addressesMcast         capableAs per 2462Stds - all        reuse themOn-link mcastNbma via         proxyingp-p only 2         nodesEthernet         fineConsistency        of IP modelPkt        forwardingNbma: bridge         local pkts, route external onesDormant modeEthernet-like:         BS must implement filtering or better, should be handled to reduce the         effectJonne: but         this is an L2 issue, not something 16ng needs to sayMax: but         this trouble is caused by IP behavior by assuming mcast or bcast does         not costJari: fair         enough, but another equally dubious assumption is that these packets         are not needed and one can elide themHost        implementations: no changes we hope (error conditions in the cache may        change this)Router        implementationsNbma - relay         DAD and address cache (may not be
 complete due to pkt loss, etc)p-p: unique         prefix assignment, as usualMcast         capable: bridging is requiredRenumberingp-p more         signaling than nbma?Jonne and          Jari: not soOne RA per          hostSeNDAll models         support thisApplicabilityMobile wimax         and wibro: IP CSFixed and         nomadic: ETH CS  1530 - 1600      Coffee break 1600 - 1800      Technical session II IPv6 solution       discussion - I IPv6 shared        prefix model over IPv6CS - Jin Hyeock ChoiIssue with         no link-scope mcastNo globally         unique link-level addr in .16 frameHost's only         on-link neighbor is its ARExploit         wimax featuresOmniscient          AR - knows all IPv6 addresses in use on a linkISF initial          service flowHost to AR           via BS connectionISF can be           used for RS/RA or NS/NAYes, even            with unspecified src addrSolutionL bit off,          A-bit potentially onOnly the AR          is a neighbor
 to an MSNo direct          MS to MS communicationASN GW is          omniscient ARMAC          transport conn = .16 on + GREISF is          state between MS and ASN GW so RS can elicit the appropriate RA going          to the correct MSGRE key          used as the replacement for a MAC addressNon-standard           extension to 802.16, which does not include a GRE key as one of the           parameters used for classificationAddr resol          and NUD only done between MS and GWSkip in           the future?Jari: not           the conclusion in 3GPP meetings, cuz reachability is a two-way thing,           don't eliminate NUD, but you can use payload packets to elide itDAD is          performed using relay DADRelay DADGW has addr          cache Learns from          DAD NSMS helps to          build cache with NUDMS sends NS          using ISFGW makes a          record and drops it if no matchIf match,          the GW relays NS to addr owner, owner responds, GW forwards to MS,
 MS          processes as usualissuesQ: the           addr cache may grow without limit, no mechanism to reduce or clean           the cache, whereas in per-MN prefix there is no such growing quantityIn per-MS           prefix model, there is a detachment procedure (or timeout) which           cleans the cache of prefixes. Moving an           MS from one BS to another is *NOT* a detachment procedure, as the           link is still activeWhy this         model? A: to save address space, but not neededEach          carrier gets a /32 (today's internet) and can get othersEach user          gets a /48Jonne:          "Each /64 prefix is like an addr in IPv4"This is          being done for 3G, HSDPA, etcJonne:This we          looked into for 3GPP, and back in 2001 we saw issues with address          cache managementPer-MS          Prefix management is much simplerRfc 3314          still holdsAddress          space is not an issueOperators          are fine with per-prefixIPv6
 unique        prefix model over IPv6CS - Jonne Soininen presenting the draft by frank        xia, behcet and rajVirtual link         vs physical linkID, prefix,          CID, etcPrefix         assignmentFast router          discovery via unsolicited RASolicited          RAPeriodic RANDBusiness as          usual for NS/NA/RS/RA, autoconfDAD: use          optiDAD (rfc4429) cuz low possibility of duplicationDormant modeLimited #          of nodesIssuesPrefix mgmt          - dhcp relay           in AR, or simplest,           table in AR with prefixesRoute flip          upon mobilityRoute           aggregation of /64's under a /48 so no issue visible outsideEnough          prefixesAnalysis           in sec 2.3.1 of rfc 3314Ex: about           80,000 prefixes per person on earth todayConclusionsPer-MS          model fits naturally to p-p linksDHCP can be          managed using DHCPEnough          prefixes (no address depletion currently foreseen)No impact          to host
 stacksAll others          (DSL, 3GPP, etc) assigning prefixes, not IP addresses to MSSo why           make Wimax worse?One can          ship now with pre-MS prefix and if there is any issue in the future          with prefix space depletion, then one can always specify shared subnet          model in the futureSome       additional discussion on multiple PDP contexts in 3GPPNo equivalent        in wimaxJinHyeock:        Why allow multiple virtual links for a single MS? might be better to        treat all connections to an MS as only one virtual link.This 3GPP        artifact complicates user interface tremendously, a nightmareJari and        Jonne: might have happened because of a misunderstanding on the part of        3GPP about how IP works  1900 - 2200      Social    
  Sep 13, Wednesday
  0900 - 1000      Technical session III IPv4/IPv6       solution discussion - II IPv6 over        Ethernet CS - Max Riegel IPv4 over        Ethernet CS - Max Riegel Wimax rel1Single host         + PPPoE in flat ETHPKMv2 for          authPPPoE via          standard learning bridgeOptional:         multiple hosts behind MS via STL for extended ARPBridge         before the AR is *NOT* a standard bridgeA standard          bridge would forward MS to MSThis does          not enable MS-MS to avoid bcast storms waking up 40k terminals (issue          because of flat ETH structure)The          "bridge" here is a forwarder, a switch, augmented with          ProxyARP/ProxyNDLearns MAC          addresses from PKMv2 auth (no timeout)But PKMv2           is terminated at the BS, and the "bridge" is beyond that,           so it's actually snooping the AAA exchangeRelying on           snooping is not guaranteed to work (e.g., if BS-AAA exchange is           protected via Ipsec)Better to   
        provide an explicit interface for "bridge" to learn this           info to guarantee this'll workOther MAC          via SLB (bridgetimeout)Floods          stuff from nw side to MS side modulo IPv4/IPv6 filtersProxyARPARP req          from nw side: Sends unicast ARP response if match foundIf no          match, either drop or flood to R1 (towards MS side)Invert the          above for ARP req's from R1 sideProxyARP          table populated from DHCP proxy, FA, data path function in ASNProxyND and         IPv6 behaviorTable of          MAC learned via SLBIPv6          addresses from msgs on R1, or DHCPRA's sent          via unicast replication (avoid waking up MS)Those in           IDLE state don't need to get itThose in           active communication with active GRE keys will get it immediatelyBut           delaying an RA will have issues with SeND            timeoutsPrefix            timeoutsRelated            discussions pointing issues with such schemes in dna WG,
 in            particular as related to the draft-ietf-dna-frd proposalAddr          resolutionNS           forwarded to nw sideMS to MS           traffic redirected to ARDAD: ProxyND         responds on behalf of the nwNeed for a         ProxyND spec available publicly Wimax rel        1.5: VLAN and direct MS-MS comm enabledVLAN         segments the entire MS population so a bcast would wake up a small         number of terminals (not 40K)802.1D         behavior within VLANMBS may be         used to efficiently implement mcast Multicast          CID per VLANNot clear          how to do this, as currently CID is assigned by BS, but in MBS it          should be done at an ASN scopeAlso,          currently SFID (32bits+48bit MAC of the MS) which are unique in the          world get mapped to CID's unique per BSBut for MBS          how this mapping will happen is not clear, so MBS discussions have          been postponed in wimax for nowQ based on        discussion from
 Jari:Instead of         starting (rel1) with a "flat ETH" which is not (no MS-MS) why         not explicitly start with separate MS links and then (rel 1.5) grow         these via VLANs?Ans: PPPoE         wants to aggregate all these devices per the flat ETH model  1000 – 1200      Break-out sessions IP CS       discussions in Room Rheintal MyungKi and        JinHyeock# of tunnels         in GRE is bigger?Jonne: not         necessarilyLots of         discussion about what is a link, and the need to define it for wimaxAs a         strawman, see below, to be ratified/owned by wimaxLink         definition:JinHyeock:          "the collection of connections between an MS and an ASN GW is a          link"ETH CS       discussions in Room Konrad DudenMax, Jeong,        and Jeon working on merging their IPv6 over ETH CS draft  1200 - 1300      Lunch 1300 - 1430      Technical session IV IPv6 solution       discussion – Breakout results   1430 - 1500      Coffee break 1500 -
 1600      Closing session Wrap-up chairs       Recommendation        on subnet model for IPv6 support - chairs Next steps -        chairs    
  ========================================
   
  Break out conclusion and final session
   
  Take-away from the break-out sessions. These are not official positions, but will need to be confirmed on the mailing list. 
   
  ETH CS
  Open issues:Include       reference to IP over ETH specification Describe usage       of ETH header informationCurrent I-D        does not make use of itProxyND vs.       RelayND for SENDApplication of       VLANs mostly for L2VPNsImpact of       delaying RAs on prefix lifetimesHow to handle       SeND time-stamps in RA messages  Considerations      on MTU size belongs to applicability statementNext steps:Max:Specifying        conceptual network modelRefine IPv4        behaviorHongseok,       SangjinExtend        specification on ICT also adopting IPv4 specificsHongseok is       taking over editorship of combined ETH-CS I-D   
  IPv6 over IPv6 CS (with wimax environment in mind)
  Per-MS prefix      is proposed now Shared prefix       can be worked further if needed (including relayND)   What is a link?      JinHyeock:       "the collection of connections between an MS and an ASN GW is a       link"   Open Questions Pkt forwarding       in ASN-GW Normal packet        forwarding based on longest prefix match    
  IPv4 CS
  No discussion      during this interim meeting

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 13 Sep 2006 10:14:22 -0700 (PDT)

Hello Gabriel,
  Thanks for posting the notes.
Can you please elaborate on this discussion?

----- Original Message ----
From: gabriel montenegro <[email-masked]>
To: [email-masked]
Sent: Tuesday, September 12, 2006 11:23:15 AM
Subject: [16ng] Interim meeting hasty notes for first day

snipped

Some additional discussion on multiple PDP contexts in 3GPP
No equivalent in wimax
Complicates user interface tremendously, a nightmare
Jari and Jonne: might have happened because of a misunderstanding on the part of 3GPP about how IP works
 
Thanks.
 
--behcet

---

From: gabriel montenegro <[email-masked]>
Date: Wed, 13 Sep 2006 16:21:12 -0700 (PDT)

JinHyeock was discussing this point with Jonne and Jari. As I remember it, he just wanted to understand
what the implications of having such multiple IP addresses (one per primary PDP context) were on the per-prefix model.
I'm not sure any fundamental such implication was identified, but perhaps one of those three folks can elaborate further.

-gabriel

----- Original Message ----
From: Behcet Sarikaya <[email-masked]>
To: gabriel montenegro <[email-masked]>
Cc: [email-masked]
Sent: Wednesday, September 13, 2006 10:14:22 AM
Subject: Re: [16ng] Interim meeting hasty notes for first day

     Some additional discussion on multiple PDP contexts in 3GPP  No equivalent in wimax Complicates user interface tremendously, a nightmare Jari and Jonne: might have happened because of a misunderstanding on the part of 3GPP about how IP works
  
 Thanks.
  
 --behcet