Subject: [16NG] ipv6 over ipv6cs document approval

From: Jari Arkko <[email-masked]>
Date: Wed, 21 Nov 2007 17:08:48 +0200

We're trying to close the remaining issues and approve
the current document.

The current proposal is what we have in the draft, with
the following changes. If there is any concern with
these changes, let me know as soon as possible.

There are a few editorial changes. The substantive
changes are clarifying MTU rules in the presence
of tunneling on the BS side, and strengthening
the requirements related to interoperability.

----

  Please change in Section 8.1:

  OLD:
    The use of router advertisements as a means for movement detection is
    not recommended for MNs connected via 802.16 links as the frequency
    of periodic router advertisements can be high.
  NEW:
    The use of router advertisements as a means for movement detection is
    not recommended for MNs connected via 802.16 links as the frequency
    of periodic router advertisements would have to be high.

  Please add new text at the end of Section 4 (just before 4.1),
  these are the new paragraphs:

    In any case, the MS and BS MUST negotiate at most one
    convergence sublayer for IPv6 transport on a given link.

    In addition, to ensure interoperability between devices that
    support different encapsulations, it is REQUIRED that BS
    implementations support all standards track encapsulations
    defined for 802.16 by the IETF. At the time of writing this
    specification, this is the only encapsulation, but additional
    specifications are being worked on. It is, however, not
    required that the BS implementations use all the encapsulations
    they support; some modes of operation may be off by
    configuration.

  Change in Appendix D:

  OLD:
    It is
    recommended that the default MTU for IPv6 be set to 1400 octets for
    the MS in WiMAX networks. 
  NEW:
    It is recommended that the MTU for IPv6 be set to 1400 octets in
    WiMAX networks, and this value (different from the default)
    be communicated to the MS.

  Change Section 6.3 to:

   The MTU value for IPv6 packets on an 802.16 link is configurable.
   The default MTU for IPv6 packets over an 802.16 link SHOULD be 1500
   octets.

   The 802.16 MAC PDU (Protocol Data Unit) is composed of a 6 byte
   header followed by an optional payload and an optional CRC covering
   the header and the payload.  The length of the PDU is indicated by
   the Len parameter in the Generic MAC Header.  The Len parameter has a
   size of 11 bits.  Hence the total MAC PDU size is 2048 bytes.  The
   IPv6 payload size can vary.  In certain deployment scenarios the MTU
   value can be greater than the default.  Neighbor Discovery for IPv6
   [RFC4861] defines an MTU option that an AR MUST advertise, via router
   advertisement (RA) if a value different from 1500 is used.
   If an AR advertises an
   MTU via the RA MTU option, the MN SHOULD use the MTU from the RA.
   Nodes that implement Path MTU discovery [RFC1981] MAY use the
   mechanism to determine the MTU for the IPv6 packets.

  In the abstract:
    s/fxed/fixed/
 
  In section 6.1:
    s/it is recommended that a tunnel is established/it is recommended
    that a tunnel be established/

_______________________________________________
16NG mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/16ng

---

From: "Junghoon Jee" <[email-masked]>
Date: Thu, 22 Nov 2007 18:01:36 +0900

Hi Jari,

I agree to apply the suggested changes.

Let me share my unsolved question regarding how to deal with neighbor
discovery packets for IPv6CS case.

Do we have to block neighbor discovery packets not to wake up idle/sleep SSs
? Or,
Do we have to let them delivered in that p2p link not to break the NUD
model?
Is there no need to specify about that in this document?

BR,
Junghoon

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 22 Nov 2007 23:29:06 -0600

One of the reasons for choosing a PtP link model is to avoid the issues
related to ND.
Because of the PtP link type there is no question about an MS being
transitioned out of Idle mode because of ND.
The document does not need to specify anything further regarding ND.

-Raj

On 11/22/07 3:01 AM, "ext Junghoon Jee" <[email-masked]> wrote:

> Do we have to block neighbor discovery packets not to wake up idle/sleep SSs ?
> Or,
> Do we have to let them delivered in that p2p link not to break the NUD model?
>> <https://www1.ietf.org/mailman/listinfo/16ng>
>> 
> 
>

---

From: "Junghoon Jee" <[email-masked]>
Date: Fri, 23 Nov 2007 18:55:51 +0900

Hi Raj,

related to ND.

Multilink subnet issues are the main reason of that.

So, we should not send neighbor discovery packets in case of the IPv6CS?

Junghoon

2007/11/23, Basavaraj Patil <[email-masked]>:
> Do we have to block neighbor discovery packets not to wake up idle/sleep
> SSs ? Or,
> https://www1.ietf.org/mailman/listinfo/16ng  <
> https://www1.ietf.org/mailman/listinfo/16ng>
>
>
> ------------------------------

---

From: "Syam Madanapalli" <[email-masked]>
Date: Fri, 23 Nov 2007 15:34:47 +0530

ND just runs normally on IPv6CS, similar to any p2p link.

-Syam

On Nov 23, 2007 3:25 PM, Junghoon Jee <[email-masked]> wrote:
> > On 11/22/07 3:01 AM, "ext Junghoon Jee" < [email-masked]> wrote:
> >
> >
> >
> > Hi Jari,
> >
> > ________________________________

---

From: Jari Arkko <[email-masked]>
Date: Fri, 23 Nov 2007 12:43:26 +0200

> So, we should not send neighbor discovery packets in case of the IPv6CS?

No, you send them when you need to.

Jari

---

From: "Junghoon Jee" <[email-masked]>
Date: Fri, 23 Nov 2007 21:05:02 +0900

Hi Syam,

Then, what can we do not to wake up the idle/sleep SSs?

Junghoon

---

From: "Junghoon Jee" <[email-masked]>
Date: Fri, 23 Nov 2007 21:08:58 +0900

To maintain the IP reachability through neighbor discovery packets, yes, I
need to send them.
However, those packets can wake up idle/sleep SS.
What can we recommend in this situation?

Junghoon

---

From: "Syam Madanapalli" <[email-masked]>
Date: Fri, 23 Nov 2007 18:17:06 +0530

Hi Junghoon,

On the IPv6 CS link, there will be two nodes: MS and AR.
ND packets from one MS will never reach other MS.
Problem may arise from periodic RAs, which may require
increasing the periodic RA interval.

Thanks,
Syam

On Nov 23, 2007 5:35 PM, Junghoon Jee <[email-masked]> wrote:
> > On Nov 23, 2007 3:25 PM, Junghoon Jee < [email-masked]> wrote:
> > > Hi Raj,
> > >
> > > 2007/11/23, Basavaraj Patil <[email-masked] >:
> > >
> > > >
> > > >
> > > https://www1.ietf.org/mailman/listinfo/16ng >
> > > >
> > > >

---

From: "Premec, Domagoj" <[email-masked]>
Date: Fri, 23 Nov 2007 16:16:09 +0100

Hi Junghoon,

> To maintain the IP reachability through neighbor
> discovery packets, yes, I need to send them.

Host probes neighbor for reachability only when it has packets to send. 

> However, those packets can wake up idle/sleep SS.

Host in the idle mode will not have any packets for sending and thus will not initiate NUD.

domagoj

	From: Junghoon Jee [mailto:[email-masked]] 
	Sent: 23. studeni 2007 13:09
	To: Jari Arkko
	Cc: [email-masked]
	Subject: Re: [16NG] ipv6 over ipv6cs document approval

	To maintain the IP reachability through neighbor discovery packets, yes, I need to send them.
	However, those packets can wake up idle/sleep SS.
	What can we recommend in this situation?
	 
	Junghoon

		
		
		Jari

---

From: "Junghoon Jee" <[email-masked]>
Date: Sat, 24 Nov 2007 13:45:24 +0900

Yes, the major problem comes from the periodic RA.

I was thinking about the case when AR sends neighbor discovery packets to
the SS which is in the sleep/idle state.
The AR's sending the unsolicited NAs to SS can be a case for that which is
described in the section 7.2.6 of RFC 4861.

Maybe we need not allow that optional behavior in the case of IPv6CS?

Junghoon

2007/11/23, Syam Madanapalli <[email-masked]>:

> > > > >    The use of router advertisements as a means for movement
> detection
> > is
> > > > >    The use of router advertisements as a means for movement
> detection
> > is
> > > > >   the Len parameter in the Generic MAC Header.  The Len parameter
> has
> > a

---

From: "John.zhao" <[email-masked]>
Date: Sat, 24 Nov 2007 13:16:29 +0800

Hi,all

         I have ever stated this problem in prague.  It’s Very glad to see
it is discussed again. The periodic RA will force those idled MS out from
sleep/idle state. So to those cases, we didn’t need the unsolicited NAs
come from ARs. But I think only in this case.

         Back to this draft, I suggest we have three choice:

1)       Didn’t take care of this, and exclude it out side of this draft.

2)       Specify this requirement , for example:

a)         Those SS/MS in sleep/idle state shouldn’t  receive those
periodic RA aimed to them.

And leave the details to others , such as wimax nwg , to handle it.

3)       Specify a detail implementation in this detail. Maybe … wait for
the input from this wg.

My two cents.

Best Rgds,

Thanks,

John.zhao

2007-11-24

  _____  

发件人: Junghoon Jee [mailto:[email-masked]] 
发送时间: 2007年11月24日 12:45
收件人: Syam Madanapalli
抄送: [email-masked]
主题: Re: [16NG] ipv6 over ipv6cs document approval
重要性: 高

Junghoon

Hi Junghoon,

Thanks,
Syam

On Nov 23, 2007 5:35 PM, Junghoon Jee <[email-masked]
<mailto:[email-masked]> > wrote:
> 2007/11/23, Syam Madanapalli < [email-masked]
detection
detection 
has

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Nov 2007 11:56:33 +0100

Just some thoughts on these issues...

John.zhao wrote:
> Hi,all
> 
>          I have ever stated this problem in prague.  It’s Very glad to 
> see it is discussed again. The periodic RA will force those idled MS out 
> from sleep/idle state.

I think we'd need to get in more detail about the levels of sleep and
idle.  I think many handheld devices have more than just two states
(normal vs standby).  For example a handheld device could run at its
fullest but have the screen and the wifi interface turned off.  Is this
'sleep'?  Other devices have various clocking strategies, based on the
application being run: if this application is run then this clock speed
should be used.

Other devices have two processors each with its own powering
architecture.  RA will probably wake up only one.

So... what do we mean by "idle/sleep" state?

It may be that the periodic RA will not provoke more battery consumption
than the other periodic link-layer messages.

Is battery the worry.

(I'm not saying at all that this is not a problem.)

Alex

> So to those cases, we didn’t need the unsolicited 
> NAs come from ARs. But I think only in this case.
> 
> 3)       Specify a detail implementation in this detail. Maybe … wait 
> for the input from this wg.
> 
>  
> 
> My two cents.
> 
> Best Rgds,
> 
> Thanks,
> 
> John.zhao
> 
> 2007-11-24
> 
> ------------------------------------------------------------------------
> 
> *发件人:* Junghoon Jee [mailto:[email-masked]]
> *发送时间:* 2007年11月24日 12:45
> *收件人:* Syam Madanapalli
> *抄送:* [email-masked]
> *主题:* Re: [16NG] ipv6 over ipv6cs document approval
> *重要性:* 高
> 
>  
> 
> I was thinking about the case when AR sends neighbor discovery 
> packets to the SS which is in the sleep/idle state.
> 
> The AR's sending the unsolicited NAs to SS can be a case for that which 
> is described in the section 7.2.6 of RFC 4861.
> 
>  
> 
> 2007/11/23, Syam Madanapalli <[email-masked] 
> <mailto:[email-masked]>>:
> 
>     Hi Junghoon,
> 
>     <mailto:[email-masked]>> wrote:
>     >  Hi Syam,
>     >
>     <mailto:[email-masked]>>:
>     >
>     >  > On Nov 23, 2007 3:25 PM, Junghoon Jee < [email-masked]
>     <mailto:[email-masked]>> wrote:
>     >  > > Hi Raj,
>     >  > >
>     >  > > 2007/11/23, Basavaraj Patil <[email-masked]
>     <mailto:[email-masked]> >:
>     >  > >
>     >  > > >
>     >  > > >
>     >  > > > On 11/22/07 3:01 AM, "ext Junghoon Jee" <
>     [email-masked] <mailto:[email-masked]>>
>     >  wrote:
>     >  > > >
>     >  > > >
>     >  > > >
>     >  > > > Hi Jari,
>     >  > > >
>     >  > > > 2007/11/22, Jari Arkko <[email-masked]
>     <mailto:[email-masked]>>:
>     >  > > >
>     >  > > >
>     >  > > >
>     >  > > >   the Len parameter in the Generic MAC Header.  The Len
>     parameter has
>     >  a
>     >  > > > [email-masked] <mailto:[email-masked]>
>     >  > > > [email-masked] <mailto:[email-masked]>
>     >  > > [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
> 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "John.zhao" <[email-masked]>
Date: Tue, 27 Nov 2007 11:03:01 +0800

Hi,Alex
	Thanks for comments.See my reply inline.
	Best Rgds,
Thanks,
John.zhao

> -----邮件原件-----
> 发件人: Alexandru Petrescu [mailto:[email-masked]]
[John.zhao] I understand. Just as you have said that to a MN, there are
difference action or status around sleep/idle what we have said. But I think
what we has discussed is mainly about the definition in IEEE802.16 about
sleep/idle state and mode. 
	Just for reference.
	As to the detail state of MN behavior. That will be decided by
vendor it self I think.
	Best Rgds,
Thank,

John.zhao
> >     >  > > >Because of the PtP link type there is no question about an
MS
> >     being
> >     >  > > > One of the reasons for choosing a PtP link model is to
avoid
> the
> >     >  issues
> >     >  > > > Let me share my unsolved question regarding how to deal
with
> >     neighbor
> >     >  > > > Do we have to block neighbor discovery packets not to wake
up
> >     >  idle/sleep
> >     >  > > >    not recommended for MNs connected via 802.16 links as
the
> >     frequency
> >     >  > > >    not recommended for MNs connected via 802.16 links as
the
> >     frequency
> >     >  > > >   The 802.16 MAC PDU (Protocol Data Unit) is composed of a
6
> >     byte
> >     >  > > >   header followed by an optional payload and an optional
CRC
> >     covering
> >     >  > > >   value can be greater than the default.  Neighbor
Discovery
> >     for IPv6
> >     >  > > >   [RFC4861] defines an MTU option that an AR MUST
advertise,
> via
> >     >  router