RE: [16NG] ipv6 over ipv6cs document approval

["John.zhao" <[e-mail]>]

Hi keshav,
	See comments inline.
	Best Rgds,
Thanks,
John.zhao

> -----邮件原件-----
> 发件人: [e-mail] [mailto:[e-mail]]
> 主题: RE: [16NG] ipv6 over ipv6cs document approval
> Hi John,
> One small query on idle mode.
> When the RA is received in idle mode, to process the RA
> it should move to the "ACTIVE/NORMAL" mode. I am not sure if
> each Vendor would have an option to handle sleep mode in different
> way, as being still in IDLE mode and ignoring the RA might result in
> issues in future as RA might have some information which is critical
> for example the MTU size change which comes with RA.
[John.zhao] In the definition of IEEE802.16, a MN in sleep mode can still process those service belong to it. The main difference to that MN is it can save power in the sleep window. So the process of RA should be normally. Just as you has mentioned , the new MTU maybe difference, so some MN in sleep mode should process those RA messages it received.
> 
> Also, as the RA interval might be long the next RA might come after
> a very long time causing MS to use incorrect information.
[John.zhao] Agreee, but after awaken from idle mode, the MN has the capability to re-established the connection with network. So in this situation , the network may send the RA to it to inform about the basic situation of current network. Those details can be found and discussed in wimax forum. But to this document about IPCS in 16ng, it seems need to be pointed and do some statement within the scope of this wg.
> 
> regards,
> Keshav
> 
> --------------------------------------------------------
> Date: Tue, 27 Nov 2007 11:03:01 +0800
> From: "John.zhao" <[e-mail]>
> Subject: RE: [16NG] ipv6 over ipv6cs document approval
> To: 'Alexandru Petrescu' <[e-mail]>
> Cc: [e-mail]
> Message-ID: <004601c830a2$08788350$[e-mail]>
> Content-Type: text/plain; charset=gb2312
> 
> Hi,Alex
> 	Thanks for comments.See my reply inline.
> 	Best Rgds,
> Thanks,
> John.zhao
> 
> > -----ÓʼþÔ­¼þ-----
> > ·¢¼þÈË: Alexandru Petrescu [mailto:[e-mail]]
> > Ö÷Ìâ: Re: [16NG] ipv6 over ipv6cs document approval 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
> >
> [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
> >
> > > 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:[e-mail]]
> > > *·¢ËÍʱ¼ä:* 2007Äê11ÔÂ24ÈÕ 12:45
> > > *ÊÕ¼þÈË:* Syam Madanapalli
> > > *³­ËÍ:* [e-mail]
> > > *Ö÷Ìâ:* Re: [16NG] ipv6 over ipv6cs document approval
> > > *ÖØÒªÐÔ:* ¸ß
> > >
> > >
> > >
> > > 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 <[e-mail]
> > > <mailto:[e-mail]>>:
> > >
> > >     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 <[e-mail]
> > >     <mailto:[e-mail]>> wrote:
> > >     >  Hi Syam,
> > >     >
> > >     >  Then, what can we do not to wake up the idle/sleep SSs?
> > >     >
> > >     >  Junghoon
> > >     >
> > >     >
> > >     >  2007/11/23, Syam Madanapalli < [e-mail]
> > >     <mailto:[e-mail]>>:
> > >     >
> > >     >  > ND just runs normally on IPv6CS, similar to any p2p link.
> > >     >  >
> > >     >  > -Syam
> > >     >  >
> > >     >  > On Nov 23, 2007 3:25 PM, Junghoon Jee < [e-mail]
> > >     <mailto:[e-mail]>> wrote:
> > >     >  > > Hi Raj,
> > >     >  > >
> > >     >  > > >One of the reasons for choosing a PtP link model is to avoid
> > >     the issues
> > >     >  > > related to ND.
> > >     >  > >
> > >     >  > > Multilink subnet issues are the main reason of that.
> > >     >  > >
> > >     >  > > >Because of the PtP link type there is no question about
> > > an
> MS
> > >     being
> > >     >  > > transitioned out of Idle mode because of ND.
> > >     >  > >
> > >     >  > > So, we should not send neighbor discovery packets in case of
> > >     the IPv6CS?
> > >     >  > >
> > >     >  > > >The document does not need to specify anything further
> > >     regarding ND.
> > >     >  > >
> > >     >  > > Junghoon
> > >     >  > >
> > >     >  > > 2007/11/23, Basavaraj Patil <[e-mail]
> > >     <mailto:[e-mail]> >:
> > >     >  > >
> > >     >  > > >
> > >     >  > > >
> > >     >  > > > 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" <
> > >     [e-mail] <mailto:[e-mail]>>
> > >     >  wrote:
> > >     >  > > >
> > >     >  > > >
> > >     >  > > >
> > >     >  > > > 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
> > >     >  > > >
> > >     >  > > >
> > >     >  > > > 2007/11/22, Jari Arkko <[e-mail]
> > >     <mailto:[e-mail]>>:
> > >     >  > > >
> > >     >  > > >
> > >     >  > > >
> > >     >  > > > 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
> > >     >  > > > [e-mail] <mailto:[e-mail]>
> > >     >  > > > https://www1.ietf.org/mailman/listinfo/16ng  <
> > >     >  > > https://www1.ietf.org/mailman/listinfo/16ng >
> > >     >  > > >
> > >     >  > > >
> > >     >  > > > ________________________________
> > >     >  > > _______________________________________________
> > >     >  > > > 16NG mailing list
> > >     >  > > > [e-mail] <mailto:[e-mail]>
> > >     >  > > > https://www1.ietf.org/mailman/listinfo/16ng
> > >     <https://www1.ietf.org/mailman/listinfo/16ng>
> > >     >  > > >
> > >     >  > > >
> > >     >  > >
> > >     >  > >
> > >     >  > > _______________________________________________
> > >     >  > > 16NG mailing list
> > >     >  > > [e-mail] <mailto:[e-mail]>
> > >     >  > > https://www1.ietf.org/mailman/listinfo/16ng
> > >     >  > >
> > >     >  > >
> > >     >  >
> > >     >
> > >     >
> > >
> > >
> > >
> > >
> > > --------------------------------------------------------------------
> > > ----
> > >
> > > _______________________________________________
> > > 16NG mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/16ng
> 
> 
> 
> 
> 
> The information contained in this electronic message and any attachments to
> this message are intended for the exclusive use of the addressee(s) and may
> contain proprietary, confidential or privileged information. If you are not
> the intended recipient, you should not disseminate, distribute or copy this
> e-mail. Please notify the sender immediately and destroy all copies of this
> message and any attachments.
> 
> WARNING: Computer viruses can be transmitted via email. The recipient should
> check this email and any attachments for the presence of viruses. The company
> accepts no liability for any damage caused by any virus transmitted by this
> email.
> 
> www.wipro.com




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