Subject: RE: [16ng] Re: I-D ACTION:draft-ietf-16ng-ipv6-over-ipv6cs-00.txt

From: <[email-masked]>
Date: Tue, 17 Oct 2006 14:57:52 +0200

Hi Alex, 

[major-snip]

> >>> [snip]
> > [snip]
> >>> Actually this is how current cellular networks (3GPP and 3GPP2) 
> >>> work.
> >> You mean for 3GPP/3GPP2 IPv4?  I agree they so work for IPv4.  But
> >>  that is possible in IPv4 only because private non-routable 
> >> addresses exist in IPv4 - they don't exist in IPv6.  In one 
> >> particular IPv4 cellular network each mobile gets a 10.x.x.x/8 
> >> prefix.  But that is possible only because it's a 10 non-routable 
> >> address.
> >> 
> >> I don't think operators are inclined to build closed dedicated IPv6
> >>  systems where the mobiles are not reachable from the Internet.
> > 
> > The 3GPP/3GPP2 specifications say that you allocate a /64 per mobile
> >  in IPv6. The assumption is that the addresses would be of global 
> > scope.
> 
> Thanks, that is good to know, and confirms some of my 
> expectations.  Is 
> there any deployment of the 3GPP/3GPP2 specifications that say you
> allocate a /64 per mobile in IPv6, and the addresses are global scope?

You might want to check e.f. 3GPP TS23.030 sub-clause 9.2.1.1. Though
it doesn't state there that the prefix is /64. Anyway the prefix must be
unique
within its scope to each PDP context. On the other hand 29.061 state
that the
interface identifier is 64bits (generated by GGSN) etc.. At least our
(3GPP)
networks are configured in this way.

[major-snap]

> > Maybe I'm confused, but usually links have just one MTU. This is the
> >  case also for 2G/3G GPRS.
> 
> Yes, I agree in general we talk links have one MTU.
> 
> However, many cellular wireless links are asymmetric in nature, the
> download pipe is wider - because the typical use is to 
> download content
> (not to upload).  This can be seen easily with stacks that fragment
> outgoing packets because their next-hop routers tells them do so.

Haven't seen this happening in practise.. Dunno if the asymmetry e.g. in
GPRS ul/dl timeslots numbers should reflect in any way to MTU sizes.. I
doubt not.

> Finally, I agree with you that IP-friendly MAC-enabled IEEE 802 links
> are easier to specify and implement with symmetric MTU.
> 

Cheers,
	Jouni

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 19 Oct 2006 21:49:20 +0200

Hi Jouni.. snip-snap heh :-)

[email-masked] wrote:
> Hi Alex,
> 
> 
> [snip-snap]
> 
>> Let me ask this then: a 3GPP commercial operator giving /64 
>> prefixes to mobiles - does it ensure their mobiles are reachable 
>> from the IPv6 Internet?
> 
> No.. why should it? This falls into operators' or possible customers'
>  deployment decisions.

Right, and if all customers needed to connect to the IPv6 Internet (and
all ready to pay for that) the operator couldn't probably technically
keep up with the demand, because it had not enough IPv6 addresses (it
gave a /48 to each mobile).

I think that an operator planning its network should know in advance
that if it distributes a /48 to each mobile user then it will face the
risk of not having enough of those /48s.

A closed IPv6 network, within one operator services and users, is a
different thing indeed.  But then, these operators also wonder why not
continue use non-routable NAT IPv4 addresses?  IPv4 does the trick as
IPv6 in most respects and functionalities.

Alex
>From [email-masked] Fri Oct 20 07:12:33 2006
Content-class: urn:content-classes:message
Subject: RE: [16ng] Re: I-D ACTION:draft-ietf-16ng-ipv6-over-ipv6cs-00.txt
Date: Thu, 19 Oct 2006 22:49:05 +0200
From: <[email-masked]>
To: <[email-masked]>
cc: [email-masked]
cc: [email-masked]

Alex, 

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: 19. lokakuuta 2006 22:49
> To: Korhonen, Jouni /TeliaSonera Finland Oyj
> Cc: [email-masked]; [email-masked]
> Subject: Re: [16ng] Re: I-D 
> ACTION:draft-ietf-16ng-ipv6-over-ipv6cs-00.txt
> 
> Hi Jouni.. snip-snap heh :-)
> 
> [email-masked] wrote:
> > Hi Alex,
> > 
> > 
> > [snip-snap]
> > 
> >> Let me ask this then: a 3GPP commercial operator giving /64 
> >> prefixes to mobiles - does it ensure their mobiles are reachable 
> >> from the IPv6 Internet?
> > 
> > No.. why should it? This falls into operators' or possible 
> customers'
> >  deployment decisions.
> 
> Right, and if all customers needed to connect to the IPv6 
> Internet (and
> all ready to pay for that) the operator couldn't probably technically
> keep up with the demand, because it had not enough IPv6 addresses (it
> gave a /48 to each mobile).

Hmm.. where did this /48 came into picture? Why should I give a mobile
node /48? I could give a customer (e.g. corporate, virtual operator,
etc)
using our cellular network a /48 and then he could do whatever he wants
with that block..
 
> I think that an operator planning its network should know in advance
> that if it distributes a /48 to each mobile user then it will face the
> risk of not having enough of those /48s.

I think operators survived this far are capable of planning their
networks.

> A closed IPv6 network, within one operator services and users, is a
> different thing indeed.  But then, these operators also wonder why not
> continue use non-routable NAT IPv4 addresses?  IPv4 does the trick as
> IPv6 in most respects and functionalities.

Well.. to be honest, for many operators there are no pressing reasons
to migrate to IPv6.

Anyway, I think this thread has already served its purpose and deviated
too far away from the original subject ;)

/Jouni

---

From: "Soininen Jonne (Nokia-NET/Espoo)" <[email-masked]>
Date: Fri, 20 Oct 2006 00:19:28 +0300

Alex,

On 10/19/06 9:33 PM, "ext Alexandru Petrescu"
<[email-masked]> wrote:

> Jonne, thanks for your email.  In general your emails on this thread to
> me helped me better understand some aspects of this draft.  Please let
> me clarify just a few points, below.
>

Good. I hope these can be of use.
 
> Soininen Jonne (Nokia-NET/Espoo) wrote:
>>> Thanks but no, please save the time.  I am interested if there's
>>> any tutorial about the implementation of these systems, not on the
>>> specs.
>> 
>> The specs specify how the networks work. So, the information is
>> accurate.
> 
> This is simply not true.  We do not currently know how these networks
> work.  We write specs about how we would like them to work.

I don't really understand your comment. We write the specs because that is
how we want the things to work to get interoperability. The networks are
implemented according the specs to make sure there is interoperability.

There are implemented, alive 3GPP networks that work according the specs. It
does not mean that all the features and options are implemented. However,
those that are - are usually according the specs.

Mobile Wimax is a bit of a different thing, though. The specifications are
just being finalized.
> 
> I've asked the variable MTU question and you replied with the 3GPP spec.
>   Do we know a WiMax trial/plan doing equal MTU uplink/downlink?

The 802.16 specs to my knowledge say the MTU is 1522. That is both for
uplink and downlink.

> 
>> I don't think there is any public information about
>> how-to-implement-a-3gpp-network. However, I'm sure you can try to ask
>>  your company as you do build both networks and handsets.
> 
> I'm very surprised by your request.  I take it as a polite invitation
> though.

Was supposed to be just a data-point if you needed more information.

[snip]
>> The operators don't have a problem with giving /64 in 3GPP/3GPP2
>> networks either.
> 
> Let me ask this then: a 3GPP commercial operator giving /64 prefixes to
> mobiles - does it ensure their mobiles are reachable from the IPv6 Internet?
>

I think Jouni answered you on this already.

Like Jouni, I also feel that this mail threat has served most probably its
purpose by now.

Cheers,

Jonne.
 
>>> End users sometimes want privacy other times reachability.  Let
>>> this fundamental decision to end user not delegate to network.
>> 
>> That's why the decision should be left for the host, not the network.
>> 
> We agree on this one.
> 
> Alex
> 

-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 19 Oct 2006 23:47:10 +0200

[email-masked] wrote:
> Alex,
> 
>> -----Original Message----- From: Alexandru Petrescu 
>> [mailto:[email-masked]] Sent: 19. lokakuuta 2006 
>> 22:49 To: Korhonen, Jouni /TeliaSonera Finland Oyj Cc: 
>> [email-masked]; [email-masked] Subject: Re: 
>> [16ng] Re: I-D ACTION:draft-ietf-16ng-ipv6-over-ipv6cs-00.txt
>> 
>>>> prefixes to mobiles - does it ensure their mobiles are 
>>>> reachable from the IPv6 Internet?
>> Right, and if all customers needed to connect to the IPv6 Internet
>>  (and all ready to pay for that) the operator couldn't probably 
>> technically keep up with the demand, because it had not enough IPv6
>>  addresses (it gave a /48 to each mobile).
> 
> Hmm.. where did this /48 came into picture? Why should I give a 
> mobile node /48? I could give a customer (e.g. corporate, virtual 
> operator, etc) using our cellular network a /48 and then he could do
>  whatever he wants with that block..

Let's say I'm that virtual operator and I get a /48 from you.  How many
mobiles can I accomodate if I give each mobile a prefix?  Probably no
more than 65535.

Let's say you are a real operator and get a /48 from a RIR.  How many
mobiles can you accomodate with a prefix-per-mobile?  Probably no more
than 65535.

I think that's how I came up with the /48 figure.

Why only 65535 mobiles if a /48 prefix?  Because the other boundary is
64.  Which makes for 64-48 is 16.  Two to 16 is 65536.  I hope I
had that right.

What if I want to accomodate 1 million mobiles?  I'll probably need 20
/48 prefixes like that from you.  Or you need 20 /48 prefixes like that
to give only to me.  You may say it's feasible.

But.

Look how many mobiles you could accomodate if you could share one /64
prefix among the mobiles.  You could have 2^64 mobiles only with one
such /64 prefix.  All this space risks being wasted.

>> I think that an operator planning its network should know in 
>> advance that if it distributes a /48 to each mobile user then it 
>> will face the risk of not having enough of those /48s.
> 

YEs.  I do not intend to make this any personal.  I bear in mind that we
participate as individuals here.  I do not take your participation as
you speaking for your employer.  I hope you don't either.

>>  different thing indeed.  But then, these operators also wonder why
>>  not continue use non-routable NAT IPv4 addresses?  IPv4 does the 
>> trick as IPv6 in most respects and functionalities.
> 

That's a good remark.

Alex
>From [email-masked] Fri Oct 20 08:44:28 2006
Date: Fri, 20 Oct 2006 01:21:05 +0300
Subject: Re: [16ng] Re: I-D ACTION:draft-ietf-16ng-ipv6-over-ipv6cs-00.txt
From: "Soininen Jonne (Nokia-NET/Espoo)" <[email-masked]>
To: ext Alexandru Petrescu <[email-masked]>,
   <[email-masked]>
cc: [email-masked]

Alex,

The default allocation policy from the RIRs is /32. So, from an RIR you
would get always at least /32. If you use addresses from your upstream
provider how much you get is up to the contract between you and the upstream
operator.

In addition, you can take a look at RFC3177, if you want to know what IESG
and IAB recommend as the address allocation for sites - I think the /64
applies pretty well for Mobile hosts as the minimum. (I have nothing against
an operator allocation a shorter prefix than /64 for a mobile  - the
prefix-per-mobile link-model allows that).

Like I tried to say, there was a consensus call on the link-model. One of
the reasons we decided that model was the technical difficulty to make the
shared prefix model to work. You should come up with an argument that would
show that the decision we made was wrong. I haven't seen one, yet.

If you think this is an important issue for you, you most probably should
start defining the solutions for making the shared model to work as the
recommendation says. The link prefix-per-mobile model does not preclude of
adding a new mechanism in the future if needed.

In addition, if some operator would really like to give just /128 per
mobile, they can always run PPPoE over the ETH CS.

I feel like going in circles here. So, I think I'll just stop now.

Cheers,

Jonne. 

On 10/20/06 12:47 AM, "ext Alexandru Petrescu"
<[email-masked]> wrote:

>>> -----Original Message----- From: Alexandru Petrescu
>>> [mailto:[email-masked]] Sent: 19. lokakuuta 2006
>>> 22:49 To: Korhonen, Jouni /TeliaSonera Finland Oyj Cc:
>>> [email-masked]; [email-masked] Subject: Re:
>>> [16ng] Re: I-D ACTION:draft-ietf-16ng-ipv6-over-ipv6cs-00.txt
>>> 
>>>>> prefixes to mobiles - does it ensure their mobiles are
>>>>> reachable from the IPv6 Internet?
>>> Right, and if all customers needed to connect to the IPv6 Internet
>>>  (and all ready to pay for that) the operator couldn't probably
>>> technically keep up with the demand, because it had not enough IPv6
>>>  addresses (it gave a /48 to each mobile).
>> 
>> Hmm.. where did this /48 came into picture? Why should I give a
>> mobile node /48? I could give a customer (e.g. corporate, virtual
>> operator, etc) using our cellular network a /48 and then he could do
>>  whatever he wants with that block..
> 
> Let's say I'm that virtual operator and I get a /48 from you.  How many
> mobiles can I accomodate if I give each mobile a prefix?  Probably no
> more than 65535.
> 
> Let's say you are a real operator and get a /48 from a RIR.  How many
> mobiles can you accomodate with a prefix-per-mobile?  Probably no more
> than 65535.
> 
> I think that's how I came up with the /48 figure.
> 
> Why only 65535 mobiles if a /48 prefix?  Because the other boundary is
> 64.  Which makes for 64-48 is 16.  Two to 16 is 65536.  I hope I
> had that right.
> 
> What if I want to accomodate 1 million mobiles?  I'll probably need 20
> /48 prefixes like that from you.  Or you need 20 /48 prefixes like that
> to give only to me.  You may say it's feasible.
> 
> But.
> 
> Look how many mobiles you could accomodate if you could share one /64
> prefix among the mobiles.  You could have 2^64 mobiles only with one
> such /64 prefix.  All this space risks being wasted.
> 
>>> I think that an operator planning its network should know in
>>> advance that if it distributes a /48 to each mobile user then it
>>> will face the risk of not having enough of those /48s.
>> 
> YEs.  I do not intend to make this any personal.  I bear in mind that we
> participate as individuals here.  I do not take your participation as
> you speaking for your employer.  I hope you don't either.
> 
>>>  different thing indeed.  But then, these operators also wonder why
>>>  not continue use non-routable NAT IPv4 addresses?  IPv4 does the
>>> trick as IPv6 in most respects and functionalities.
>> 
> That's a good remark.

-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34

---

From: "Tow, Agnes C (Agnes)** CTR **" <[email-masked]>
Date: Mon, 23 Oct 2006 10:51:24 -0400

I believe the WiMAX Profile B still comply with all the ASN-GW functions because it still need to communicate with other ASN-GW in the standard way, just the R6 is not exposed.
>From [email-masked] Tue Oct 24 14:26:36 2006
Date: Tue, 24 Oct 2006 12:02:25 +0800
From: wenson <[email-masked]>
Subject: Re: [16ng] WGLC: draft-ietf-16ng-ipv6-link-model-analysis-00
To: Soohong Daniel Park <[email-masked]>
cc: Qin Alice <[email-masked]>
cc: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_zPsWsYmnAfNeZGh8VAVxTw)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

Hi Daniel:

As far as I concern, the link models can be categorized based on three network topology  modes ,i.e., point to point, point to multiple points and multiple points and multipoints. Different topology mode can be deployed in different scenario. 

>>>In section 3.3.4.2, it said:

>>>in case of bridging, direct inter-MSs communication may not be not allowed due to restrictions from the service providers.  

So my questions is

1.If MSs are served by the same service providers and located below the same BS(i.e., connect to the same BS), Do they communicate with each other?

2. In Ether like link model, there are several BS attached the same ether Switch device and also there are several MS attached the same BS, how does BS process multicast packet from AR beyond ether Switch and forward the processed packet to each MS who is located below BS?

***maybe multicast capability is limited not between MS and AR but between BS and AR, what do you think of it? 

3. As Above said, how Ether switch or bridge work to support multicast capability?

----- Original Message ----- 
From: "Soohong Daniel Park" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, October 12, 2006 5:20 PM
Subject: [16ng] WGLC: draft-ietf-16ng-ipv6-link-model-analysis-00

> Folks,
> 
> This is a two week WGLC on draft-ietf-16ng-ipv6-link-model-analysis-00.
> 
> Please review the I-D and submit your comments to the authors or to
> the list directly. The WGLC will exipre on October 26 (Pacific Time).
> 
> o I-D: http://www.ietf.org/internet-drafts/draft-ietf-16ng-ipv6-link-model-analysis-00.txt
> 
> o Intended publication: Informational RFC
> 
> -- 
> 
> 
> Daniel (Soohong Daniel Park)
> Mobile Convergence Laboratory, SAMSUNG Electronics.

--Boundary_(ID_zPsWsYmnAfNeZGh8VAVxTw)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.2963" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV>
<P class=MsoNormal 
style="MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: auto"><SPAN 
lang=EN-US 
style="FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: &#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT 
face="Times New Roman">Hi Daniel:<?xml:namespace prefix = o ns = 
"urn:schemas-microsoft-com:office:office" /><o:p></o:p></FONT></SPAN></P>
<P class=MsoNormal 
style="MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: auto"><SPAN 
lang=EN-US 
style="FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: &#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT 
face="Times New Roman">As far as I concern, the link models&nbsp;can be 
categorized based on three&nbsp;network topology &nbsp;modes ,i.e., point to 
point, point to multiple points and multiple points and multipoints. Different 
topology mode can be </FONT></SPAN><SPAN lang=EN-US 
style="FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: &#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT 
face="Times New Roman">deployed in different scenario. 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoNormal 
style="MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: auto"><SPAN 
lang=EN-US 
style="FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: &#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT 
face="Times New Roman">&gt;&gt;&gt;In section <?xml:namespace prefix = st1 ns = 
"urn:schemas-microsoft-com:office:smarttags" /><st1:chsdate w:st="on" 
IsROCDate="False" IsLunarDate="False" Day="30" Month="12" 
Year="1899">3.3.4</st1:chsdate>.2, it said:<o:p></o:p></FONT></SPAN></P>
<P class=MsoNormal 
style="MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: auto"><SPAN 
lang=EN-US 
style="FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: &#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT 
face="Times New Roman">&gt;&gt;&gt;in case of bridging, direct inter-MSs 
communication may not be not allowed due to restrictions from the service 
providers.&nbsp; <o:p></o:p></FONT></SPAN></P>
<P class=MsoNormal 
style="MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: auto"><SPAN 
lang=EN-US 
style="FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: &#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT 
face="Times New Roman">So my questions is<o:p></o:p></FONT></SPAN></P>
<P class=MsoNormal 
style="MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: auto"><SPAN 
lang=EN-US 
style="FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: &#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT 
face="Times New Roman">1.If MSs are served by the same service providers and 
located below the same BS(i.e., connect to the same BS), Do 
they&nbsp;communicate with each other?<o:p></o:p></FONT></SPAN></P>
<P class=MsoNormal 
style="MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: auto"><SPAN 
lang=EN-US 
style="FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: &#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT 
face=&#23435;&#20307; size=2></FONT></SPAN>&nbsp;</P>
<P class=MsoNormal 
style="MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: auto"><SPAN 
lang=EN-US 
style="FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: &#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT 
face="Times New Roman">2. In Ether like link model, there are several BS 
attached the same ether Switch device and also there are several MS attached the 
same BS, how does BS process multicast packet from AR beyond ether Switch and 
forward the processed packet to each MS who is located below 
BS?</FONT></SPAN></P>
<P class=MsoNormal 
style="MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: auto"><SPAN 
lang=EN-US 
style="FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: &#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT 
face=&#23435;&#20307; size=2><FONT face="Times New Roman" size=3>***maybe multicast capability 
is limited not between MS and AR but between BS and AR, what do you&nbsp;think 
of it?</FONT>&nbsp;</FONT></SPAN></P>
<P class=MsoNormal 
style="MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: auto"><SPAN 
lang=EN-US 
style="FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: &#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT 
size=2></FONT></SPAN>&nbsp;</P>
<P class=MsoNormal 
style="MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: auto"><SPAN 
lang=EN-US 
style="FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: &#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT 
face="Times New Roman">3. As Above said, how Ether switch or bridge work to 
support multicast capability?<o:p></o:p></FONT></SPAN></P></DIV>
<DIV><FONT face=&#23435;&#20307; size=2>&nbsp;<BR></FONT></DIV>
<DIV><FONT face=&#23435;&#20307; size=2>----- Original Message ----- </FONT>
<DIV><FONT face=&#23435;&#20307; size=2>From: "Soohong Daniel Park" &lt;</FONT><A 
href="mailto:[email-masked]"><FONT face=&#23435;&#20307; 
size=2>[email-masked]</FONT></A><FONT face=&#23435;&#20307; size=2>&gt;</FONT></DIV>
<DIV><FONT face=&#23435;&#20307; size=2>To: &lt;</FONT><A 
href="mailto:[email-masked]"><FONT face=&#23435;&#20307; 
size=2>[email-masked]</FONT></A><FONT face=&#23435;&#20307; size=2>&gt;</FONT></DIV>
<DIV><FONT face=&#23435;&#20307; size=2>Sent: Thursday, October 12, 2006 5:20 PM</FONT></DIV>
<DIV><FONT face=&#23435;&#20307; size=2>Subject: [16ng] WGLC: 
draft-ietf-16ng-ipv6-link-model-analysis-00</FONT></DIV></DIV>
<DIV><FONT face=&#23435;&#20307;><BR><FONT size=2></FONT></FONT></DIV><FONT face=&#23435;&#20307; 
size=2>&gt; Folks,<BR>&gt; <BR>&gt; This is a two week WGLC on 
draft-ietf-16ng-ipv6-link-model-analysis-00.<BR>&gt; <BR>&gt; Please review the 
I-D and submit your comments to the authors or to<BR>&gt; the list directly. The 
WGLC will exipre on October 26 (Pacific Time).<BR>&gt; <BR>&gt; o I-D: </FONT><A 
href="http://www.ietf.org/internet-drafts/draft-ietf-16ng-ipv6-link-model-analysis-00.txt"><FONT 
face=&#23435;&#20307; 
size=2>http://www.ietf.org/internet-drafts/draft-ietf-16ng-ipv6-link-model-analysis-00.txt</FONT></A><BR><FONT 
face=&#23435;&#20307; size=2>&gt; <BR>&gt; o Intended publication: Informational RFC<BR>&gt; 
<BR>&gt; -- <BR>&gt; <BR>&gt; <BR>&gt; Daniel (Soohong Daniel Park)<BR>&gt; 
Mobile Convergence Laboratory, SAMSUNG Electronics.<BR>&gt; 
_______________________________________________<BR>&gt; 16ng mailing 
list<BR>&gt; </FONT><A href="mailto:[email-masked]"><FONT face=&#23435;&#20307; 
size=2>[email-masked]</FONT></A><BR><FONT face=&#23435;&#20307; size=2>&gt; 
</FONT><A href="http://eeca16.sogang.ac.kr/mailman/listinfo/16ng"><FONT face=&#23435;&#20307; 
size=2>http://eeca16.sogang.ac.kr/mailman/listinfo/16ng</FONT></A><BR><FONT 
face=&#23435;&#20307; size=2>&gt;</FONT></BODY></HTML>

--Boundary_(ID_zPsWsYmnAfNeZGh8VAVxTw)--
>From [email-masked] Tue Oct 24 21:39:39 2006
Content-class: urn:content-classes:message
Subject: RE: [16ng] WGLC: draft-ietf-16ng-ipv6-link-model-analysis-00
Date: Tue, 24 Oct 2006 13:15:26 +0200
From: "Riegel, Maximilian" <[email-masked]>
To: "wenson" <[email-masked]>
cc: Qin Alice <[email-masked]>
cc: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6F75D.B51737A9
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Wenson,
=20
You may find answers to your questions in the just released I-D
draft-riegel-16ng-ip-over-eth-over-80216-01.txt
=20
The Ethernet link model for IEEE802.16 does not make use of the native
MBS function in IEEE802.16 for broadcast and all hosts multicast, as MBS
is less efficient than unicast and special processing in the bridge.
=20
Direkt host-to-host communication is only enabled as a configurable
option in VLAN scenario between members of a particular VLAN. Otherwise
all communication is passing through the AR to allow for interception
and accounting by the AR.
=20
Broadcast and Multicast is realized in the bridge behind BS over unicast
connections to the MSs with special filtering taking place to prevent
from wasting transmission and power resources.
=20
Bye
Max
=20

________________________________

From: [email-masked]
[mailto:[email-masked]] On Behalf Of wenson
Sent: Tuesday, October 24, 2006 6:02 AM
To: Soohong Daniel Park
Cc: Qin Alice; [email-masked]
Subject: Re: [16ng] WGLC: draft-ietf-16ng-ipv6-link-model-analysis-00

Hi Daniel:

As far as I concern, the link models can be categorized based on three
network topology  modes ,i.e., point to point, point to multiple points
and multiple points and multipoints. Different topology mode can be
deployed in different scenario.=20

>>>In section 3.3.4.2, it said:

>>>in case of bridging, direct inter-MSs communication may not be not
allowed due to restrictions from the service providers. =20

So my questions is

1.If MSs are served by the same service providers and located below the
same BS(i.e., connect to the same BS), Do they communicate with each
other?

=20

2. In Ether like link model, there are several BS attached the same
ether Switch device and also there are several MS attached the same BS,
how does BS process multicast packet from AR beyond ether Switch and
forward the processed packet to each MS who is located below BS?

***maybe multicast capability is limited not between MS and AR but
between BS and AR, what do you think of it?=20

=20

3. As Above said, how Ether switch or bridge work to support multicast
capability?

=20
----- Original Message -----=20
From: "Soohong Daniel Park" <[email-masked]
<mailto:[email-masked]> >
To: <[email-masked] <mailto:[email-masked]> >
Sent: Thursday, October 12, 2006 5:20 PM
Subject: [16ng] WGLC: draft-ietf-16ng-ipv6-link-model-analysis-00

> Folks,
>=20
> This is a two week WGLC on
draft-ietf-16ng-ipv6-link-model-analysis-00.
>=20
> Please review the I-D and submit your comments to the authors or to
> the list directly. The WGLC will exipre on October 26 (Pacific Time).
>=20
> o I-D:
http://www.ietf.org/internet-drafts/draft-ietf-16ng-ipv6-link-model-anal
ysis-00.txt
<http://www.ietf.org/internet-drafts/draft-ietf-16ng-ipv6-link-model-ana
lysis-00.txt>=20
>=20
> o Intended publication: Informational RFC
>=20
> --=20
>=20
>=20
> Daniel (Soohong Daniel Park)
> Mobile Convergence Laboratory, SAMSUNG Electronics.
> [email-masked] <mailto:[email-masked]>=20
<http://eeca16.sogang.ac.kr/mailman/listinfo/16ng>=20
>=20

------_=_NextPart_001_01C6F75D.B51737A9
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D "urn:schemas-microsoft-com:office:office" xmlns:st1 =
=3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D720155310-24102006><FONT =
face=3D"Courier New"=20
color=3D#000080 size=3D2>Wenson,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D720155310-24102006><FONT =
face=3D"Courier New"=20
color=3D#000080 size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D720155310-24102006><FONT =
face=3D"Courier New"=20
color=3D#000080 size=3D2>You may find answers to your questions in the =
just released=20
I-D</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D720155310-24102006><SPAN =
lang=3DNO-BOK=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Gulim"><FONT face=3D"Courier New" =

color=3D#000080>draft-riegel-16ng-ip-over-eth-over-80216-01.txt</FONT></S=
PAN></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D720155310-24102006><SPAN =
lang=3DNO-BOK=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Gulim"><FONT face=3D"Courier New" =

color=3D#000080 size=3D2></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D720155310-24102006><SPAN =
lang=3DNO-BOK=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Gulim"><FONT face=3D"Courier New" =

color=3D#000080>The Ethernet link model for IEEE802.16 does not make use =
of the=20
native MBS function in IEEE802.16 for broadcast and all hosts multicast, =
as MBS=20
is less efficient than unicast and special processing in the=20
bridge.</FONT></SPAN></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D720155310-24102006><SPAN =
lang=3DNO-BOK=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Gulim"><FONT face=3D"Courier New" =

color=3D#000080></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D720155310-24102006><SPAN =
lang=3DNO-BOK=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Gulim"><FONT face=3D"Courier New" =

color=3D#000080>Direkt host-to-host communication is only enabled as a=20
configurable&nbsp;option in VLAN scenario&nbsp;between members of a =
particular=20
VLAN. </FONT></SPAN></SPAN><SPAN class=3D720155310-24102006><SPAN =
lang=3DNO-BOK=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Gulim"><FONT face=3D"Courier New" =

color=3D#000080>Otherwise all communication is passing through the AR to =
allow for=20
interception and accounting&nbsp;by the AR.</FONT></SPAN></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D720155310-24102006><SPAN =
lang=3DNO-BOK=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Gulim"><FONT face=3D"Courier New" =

color=3D#000080></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D720155310-24102006><SPAN =
lang=3DNO-BOK=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Gulim"><FONT face=3D"Courier New" =

color=3D#000080>Broadcast and Multicast is realized in the bridge behind =
BS over=20
unicast connections to the MSs with special filtering taking place to =
prevent=20
from wasting transmission and power =
resources.</FONT></SPAN></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D720155310-24102006><SPAN =
lang=3DNO-BOK=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Gulim"></SPAN></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D720155310-24102006><SPAN =
lang=3DNO-BOK=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Gulim">Bye</SPAN></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D720155310-24102006><SPAN =
lang=3DNO-BOK=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Gulim">Max</SPAN></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D720155310-24102006><SPAN =
lang=3DNO-BOK=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Gulim"></SPAN></SPAN>&nbsp;</DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> =
[email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of=20
</B>wenson<BR><B>Sent:</B> Tuesday, October 24, 2006 6:02 =
AM<BR><B>To:</B>=20
Soohong Daniel Park<BR><B>Cc:</B> Qin Alice;=20
[email-masked]<BR><B>Subject:</B> Re: [16ng] WGLC:=20
draft-ietf-16ng-ipv6-link-model-analysis-00<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: =
ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: =
auto"><SPAN=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: =
&#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT=20
face=3D"Times New Roman">Hi Daniel:<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: =
ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: =
auto"><SPAN=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: =
&#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT=20
face=3D"Times New Roman">As far as I concern, the link models&nbsp;can =
be=20
categorized based on three&nbsp;network topology &nbsp;modes ,i.e., =
point to=20
point, point to multiple points and multiple points and multipoints. =
Different=20
topology mode can be </FONT></SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: =
&#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT=20
face=3D"Times New Roman">deployed in different scenario.=20
<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: =
ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: =
auto"><SPAN=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: =
&#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT=20
face=3D"Times New Roman">&gt;&gt;&gt;In section <st1:chsdate =
Year=3D"1899"=20
Month=3D"12" Day=3D"30" IsLunarDate=3D"False" IsROCDate=3D"False"=20
w:st=3D"on">3.3.4</st1:chsdate>.2, it said:<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: =
ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: =
auto"><SPAN=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: =
&#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT=20
face=3D"Times New Roman">&gt;&gt;&gt;in case of bridging, direct =
inter-MSs=20
communication may not be not allowed due to restrictions from the =
service=20
providers.&nbsp; <o:p></o:p></FONT></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: =
ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: =
auto"><SPAN=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: =
&#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT=20
face=3D"Times New Roman">So my questions is<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: =
ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: =
auto"><SPAN=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: =
&#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT=20
face=3D"Times New Roman">1.If MSs are served by the same service =
providers and=20
located below the same BS(i.e., connect to the same BS), Do=20
they&nbsp;communicate with each other?<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: =
ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: =
auto"><SPAN=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: =
&#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT=20
face=3D&#23435;&#20307; size=3D2></FONT></SPAN>&nbsp;</P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: =
ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: =
auto"><SPAN=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: =
&#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT=20
face=3D"Times New Roman">2. In Ether like link model, there are several =
BS=20
attached the same ether Switch device and also there are several MS =
attached the=20
same BS, how does BS process multicast packet from AR beyond ether =
Switch and=20
forward the processed packet to each MS who is located below=20
BS?</FONT></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: =
ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: =
auto"><SPAN=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: =
&#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT=20
face=3D&#23435;&#20307; size=3D2><FONT face=3D"Times New Roman" =
size=3D3>***maybe multicast capability=20
is limited not between MS and AR but between BS and AR, what do =
you&nbsp;think=20
of it?</FONT>&nbsp;</FONT></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: =
ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: =
auto"><SPAN=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: =
&#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT=20
size=3D2></FONT></SPAN>&nbsp;</P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; LINE-HEIGHT: normal; TEXT-AUTOSPACE: =
ideograph-numeric; mso-pagination: widow-orphan; mso-layout-grid-align: =
auto"><SPAN=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; LAYOUT-GRID-MODE: both; FONT-FAMILY: =
&#23435;&#20307;; mso-bidi-font-family: &#23435;&#20307;"><FONT=20
face=3D"Times New Roman">3. As Above said, how Ether switch or bridge =
work to=20
support multicast capability?<o:p></o:p></FONT></SPAN></P></DIV>
<DIV><FONT face=3D&#23435;&#20307; size=3D2><BR></FONT>&nbsp;</DIV>
<DIV><FONT face=3D&#23435;&#20307; size=3D2>----- Original Message ----- =
</FONT>
<DIV><FONT face=3D&#23435;&#20307; size=3D2>From: "Soohong Daniel Park" =
&lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT face=3D&#23435;&#20307;=20
size=3D2>[email-masked]</FONT></A><FONT face=3D&#23435;&#20307; =
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3D&#23435;&#20307; size=3D2>To: &lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT face=3D&#23435;&#20307;=20
size=3D2>[email-masked]</FONT></A><FONT =
face=3D&#23435;&#20307; size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3D&#23435;&#20307; size=3D2>Sent: Thursday, October 12, =
2006 5:20 PM</FONT></DIV>
<DIV><FONT face=3D&#23435;&#20307; size=3D2>Subject: [16ng] WGLC:=20
draft-ietf-16ng-ipv6-link-model-analysis-00</FONT></DIV></DIV>
<DIV><FONT face=3D&#23435;&#20307;><BR><FONT =
size=3D2></FONT></FONT></DIV><FONT face=3D&#23435;&#20307;=20
size=3D2>&gt; Folks,<BR>&gt; <BR>&gt; This is a two week WGLC on=20
draft-ietf-16ng-ipv6-link-model-analysis-00.<BR>&gt; <BR>&gt; Please =
review the=20
I-D and submit your comments to the authors or to<BR>&gt; the list =
directly. The=20
WGLC will exipre on October 26 (Pacific Time).<BR>&gt; <BR>&gt; o I-D: =
</FONT><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-16ng-ipv6-link-mod=
el-analysis-00.txt"><FONT=20
face=3D&#23435;&#20307;=20
size=3D2>http://www.ietf.org/internet-drafts/draft-ietf-16ng-ipv6-link-mo=
del-analysis-00.txt</FONT></A><BR><FONT=20
face=3D&#23435;&#20307; size=3D2>&gt; <BR>&gt; o Intended publication: =
Informational RFC<BR>&gt;=20
<BR>&gt; -- <BR>&gt; <BR>&gt; <BR>&gt; Daniel (Soohong Daniel =
Park)<BR>&gt;=20
Mobile Convergence Laboratory, SAMSUNG Electronics.<BR>&gt;=20
_______________________________________________<BR>&gt; 16ng mailing=20
list<BR>&gt; </FONT><A href=3D"mailto:[email-masked]"><FONT =
face=3D&#23435;&#20307;=20
size=3D2>[email-masked]</FONT></A><BR><FONT =
face=3D&#23435;&#20307; size=3D2>&gt;=20
</FONT><A =
href=3D"http://eeca16.sogang.ac.kr/mailman/listinfo/16ng"><FONT =
face=3D&#23435;&#20307;=20
size=3D2>http://eeca16.sogang.ac.kr/mailman/listinfo/16ng</FONT></A><BR><=
FONT=20
face=3D&#23435;&#20307; size=3D2>&gt;</FONT> </BODY></HTML>

------_=_NextPart_001_01C6F75D.B51737A9--
>From [email-masked] Tue Oct 24 23:51:55 2006
Date: Tue, 24 Oct 2006 21:27:33 +0800
From: wenson <[email-masked]>
Subject: Re: [16ng] Re: I-D ACTION:draft-ietf-16ng-ipv6-over-ipv6cs-00.txt
To: Alexandru Petrescu <[email-masked]>
cc: [email-masked]

Hi, Alex:
In section 5, it wrote:
>>The AR may be a function of the ASN-GW in the case of
>>   profiles A and C and is a function in the ASN in the case of profile
 >>  B. When the BS and the AR are separate entities and linked via the R6
 >>  interface, IPv6 packets between the BS and the AR are carried over a GRE tunnel.
 Since there are no R6 interface in profile B, do it mean that profile B is equivalent to the 802.16e deployment architecture with the integrated BS & AR? if in this case,why does the entity of ASN-GW is removed from WiMAX Network reference model in figure 2? why is there no R6 interface between BS and ASN-GW?

>>The transport connection over the air interface and
>>  the GRE tunnel between the BS and AR create a tunnel at the layer
>>   below IPv6.
In my view, the transport connection between MS and BS is one connection at the layer below IPv6, while the GRE tunnel between BS and AR is tunnel at the layer above IPv6. what do you think of it?

The transport connection between MS and BS and the GRE tunnel between BS and AR implement
point to point link between MS and AR.

Another point is that ipv6cs can implement point to point link, but it doesn't mean ipv6cs is limited to 
implement point to point link, it depends on the tunnel between BS and AR. what do you think of it?

Wenson
----- Original Message ----- 
From: "Alexandru Petrescu" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, October 17, 2006 4:34 AM
Subject: [16ng] Re: I-D ACTION:draft-ietf-16ng-ipv6-over-ipv6cs-00.txt

> [email-masked] wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories. This draft is a work item of the IP over IEEE 802.16 
>> Networks Working Group of the IETF.
>> 
>> Title : IPv6 Over IPv6 Convergence sublayer in WiMAX Networks 
>> Author(s) : B. Patil, et al. Filename : 
>> draft-ietf-16ng-ipv6-over-ipv6cs-00.txt Pages : 20 Date : 
>> 2006-10-16  The WiMAX forum is defining the network architecture 
>> which enables Internet connectivity to mobile stations and IP hosts 
>> via the 802.16d/e radio interface.  This document specifies the 
>> addressing and operation of IPv6 for hosts served by a WiMAX network.
>>  It recommends the assignment of a unique prefix to each host and 
>> allow the host to use multiple identifiers within that prefix, 
>> including support for randomly generated identifiers.  IPv6 operation
>>  in WiMAX networks as explained in this document is based entirely on
>>  existing IETF specifications.  The solution entailed herein is 
>> recommended for adoption by the WiMAX forum for IPv6 over the IPv6 
>> convergence sublayer.
> 
> Thanks for the draft.
> 
>> From an IPv6 perspective the MS and the AR are connected by a point-
>>  to-point link.
> 
> Thus, is the RFC2472 IPv6 over point-to-point protocol used by WiMax
> mobile stations?
> 
>> The IPv6 link between the mobile station (MS) and the access router 
>> (AR) is considered as a point-to-point link.  Assignment of a unique
>>  prefix per MS is recommended in this document.
> 
> Could there be a discussion about address waste which may occur when
> each mobile is using a different 64bit prefix?  And the redundancy of
> using a unique MAC address when the prefix is guaranteed unique, and
> vice-versa?
> 
> I'd be inclined to suggest a common prefix be shared among several
> mobile stations, each with its unique 64bit IID.
> 
> I'd speculate that few operators will enjoy the luxury to assign one 
> 64bit prefix per mobile it operates.  A cell operator operating 4 
> million mobiles, would need a /32 prefix assigned to it by a regional 
> registry... while a /48 is considered luxury already.  Or maybe other 
> allocation schemes are planned?  What are these?
> 
>> The WiMAX forum [WMF] has specified the SDU size as 1522 octets.
> 
> Is the MN-AR link symmetric?  Is the SDU the same in both directions?
> I'm asking because some cellular mobile links are asymmetric,
> privileging the downlink with larger MTU and the upload with smaller MTU.
> 
> Alex
>From [email-masked] Wed Oct 25 06:42:11 2006
Date: Tue, 24 Oct 2006 15:17:56 -0500
From: Behcet Sarikaya <[email-masked]>
To: "Riegel, Maximilian" <[email-masked]>,
   [email-masked]
Subject: [16ng] draft-riegel-16ng-ip-over-eth-over-80216-01.txt
Reply-To: Behcet Sarikaya <[email-masked]>

Hi Max,
  In Sec. 7.4 you say that SeND is adopted. SeND requires Relay DAD and 
in Sec. 7.5 you have that too. So far so good.
  However, Relay DAD has problems if applied over the air and we 
discussed these problems in the context of draft-madanapalli (his draft 
on the shared prefix model). If your draft applies only to the fixed 
nodes or SSs that are connected via an Ethernet port, I think there is 
no problem.
  Can you please confirm this?

Regards,

Behcet