Re: [16NG] ipv6 over ipv6cs document approval

["Junghoon Jee" <[e-mail]>]

Hi Syam,

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

Junghoon


2007/11/23, Syam Madanapalli <[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]> 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]>:
> >
> > >
> > >
> > > 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]>
> 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]>:
> > >
> > >
> > >
> > > 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]
> > > https://www1.ietf.org/mailman/listinfo/16ng  <
> > https://www1.ietf.org/mailman/listinfo/16ng>
> > >
> > >
> > > ________________________________
> > _______________________________________________
> > > 16NG mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/16ng
> > >
> > >
> >
> >
> > _______________________________________________
> > 16NG mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/16ng
> >
> >
>

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