Re: [16NG] DAD in IEEE802.16

["Syam Madanapalli" <[e-mail]>]

Hi Frank and Sangeon,

How about using Optimistic DAD (RFC 4429) to minimize the delay?

Thanks,
Syam


On 5/2/07, Frank Xia <[e-mail]> wrote:
>
>  Hi Deniel and Sangeon
>
> A  solution is proposed in the END draft and it applies to p2p link model
> as well.
>
> http://tools.ietf.org/wg/16ng/draft-xia-16ng-end-01.txt
>
> Comments are welcomed.
>
> BR
> Frank
>
>
>
>
>
>  ----- Original Message -----
> *From:* Daniel Park <[e-mail]>
> *To:* '김상언' <[e-mail]> ; [e-mail]
> *Sent:* Tuesday, May 01, 2007 6:39 PM
> *Subject:* [16NG] DAD in IEEE802.16
>
>
> [Trimming the list and subject]
>
> Sangeon,
>
> IPv6 subnet model document was gone. Its status
> is in RFC Queue. If you have any concern regarding
> IPv6 DAD, it may take place in IPv6CS or EthernetCS
> document in my sense. Can you elaborate on your
> concern more specific ?
>
> -- Daniel Park
>
>
>
>  ------------------------------
> *From:* 김상언 [mailto:[e-mail]]
> *Sent:* Monday, April 30, 2007 11:14 PM
> *To:* [e-mail]
> *Cc:* [e-mail]; [e-mail]
> *Subject:* Re: 16NG Digest, Vol 5, Issue 22
>
>
>  Hi all,
>
> The one of the important thing in IEEE802.16 is missed.
> RFC 2462 specifies autoconfiguration in wired-based IPv6 Internet. It did
> not specify configuration time.
> To use RFC 2462 specfication in IEEE802.16e network, it is
> required faster procedure than current DAD procedure.
> Has anyone can tell the DAD processing time?
>
> If the IEEE 802.16 network will consume more than one seconds to handover
> at IP layer, Does it practical?
>
> So, I would like to propose to add some technical resolution for section
> 3.1.3 and 3.3.3.
>
> regards,
>
>
> 2007/4/28, [e-mail] <[e-mail]>rg>:
> >
> > Send 16NG mailing list submissions to
> >        [e-mail]
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >        https://www1.ietf.org/mailman/listinfo/16ng
> > or, via email, send a message with subject or body 'help' to
> >        [e-mail]
> >
> > You can reach the person managing the list at
> >        [e-mail]
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of 16NG digest..."
> >
> >
> > Today's Topics:
> >
> >   1.  Document Action: 'Analysis of IPv6 Link Models for  802.16
> >      based Networks' to Informational RFC  (The IESG)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Fri, 27 Apr 2007 11:30:34 -0400
> > From: The IESG <[e-mail] >
> > Subject: [16NG] Document Action: 'Analysis of IPv6 Link Models for
> >        802.16 based Networks' to Informational RFC
> > To: IETF-Announce <[e-mail] >
> > Cc: Internet Architecture Board <[e-mail]>rg>,  16ng mailing list
> >        <[e-mail]>rg>, 16ng chair < [e-mail]>gt;,
> > RFC Editor
> >        <[e-mail]>
> > Message-ID: < [e-mail]>
> >
> > The IESG has approved the following document:
> >
> > - 'Analysis of IPv6 Link Models for 802.16 based Networks '
> >   <draft-ietf-16ng-ipv6-link-model-analysis-03.txt > as an Informational
> > RFC
> >
> > This document is the product of the IP over IEEE 802.16 Networks Working
> > Group.
> >
> > The IESG contact persons are Jari Arkko and Mark Townsley.
> >
> > A URL of this Internet-Draft is:
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-16ng-ipv6-link-model-analysis-03.txt
> >
> > Technical Summary
> >
> > This document provides different IPv6 link models that are suitable
> > for 802.16 based networks and provides analysis of various
> > considerations for each link model and the applicability of each link
> > model under different deployment scenarios.
> >
> > Working Group Summary
> >
> > This document is result of a Design Team that was formed
> > to analyze the IPv6 link models for 802.16 based networks.
> > Based on the recommendations of the design team and this
> > document, the working group has chosen the unique-prefix-per-
> > link/mn model over the previously assumed shared prefix
> > model. The new model is in use in the IPv6 over 802.16 IPCS
> > document (draft-ietf-16ng-ipv6-over-ipv6cs), and has also
> > been adopted by the Wimax Forum.
> >
> > Protocol Quality
> >
> > Jari Arkko has revied this document for the IESG.
> >
> > Note to RFC Editor
> >
> > Please insert "IEEE" in front of references to 802.16
> > or other IEEE specification numbers throughout the
> > document, including the title.
> >
> > Please expand "MS" to "MS (Mobile Station)" on first
> > occurence in Section 1. Similarly, expand "BS" to
> > "BS (Base Station)". And later in the document,
> > "CS" to "CS (Convergence Sublayer)".
> >
> > Please expand "MLD" to "MLD (Multicast Listener
> > Discovery)" in Section 3.1.3.
> >
> > Please add the following informative reference:
> >
> >   [WiMAXArch]
> >              "WiMAX End-to-End Network Systems Architecture
> >              http://www.wimaxforum.org/technology/documents"quot;,
> >              August 2006.
> >
> > and refer to that from Section 1, 2nd paragraph, 1st sentence.
> >
> > In Section 3.1, change "on per MS basis" to "on a per MS basis".
> >
> > Also in Section 3.1, paragraph 1: change "does not any multicast"
> > to "does not provide any multicast". And change "illustrates high"
> > to "illustrate a". Finally, change "one more" to "one or more".
> >
> > Change the section titles (3 instances) that say "Reuse of
> > Existing Standards" to "Reuse of Existing Specifications".
> >
> > Replace the text in the Security Considerations section
> > with the following:
> >
> >    This document provides the analysis of various IPv6 link models for
> >    IEEE 802.16 based networks and this document as such does not
> >    introduce any new security threats. No matter what the link model
> >    is, the networks employ the same link-layer security mechanisms
> >    defined in [5]. However, the chosen link model affects the scope
> >    of link local communication, and this may have security implications
> >    for protocols that are designed to work within the link scope. This
> >    is the concern for shared link model compared other models wherein
> >    private resources e.g. personal printer cannot be put onto a public
> >    WiMAX network. This may restrict the usage of shared prefix model
> >    to enterprise environments.
> >
> >    The Neighbor Discovery related security issues are document in [RFC
> >
> >    2461] [RFC 2462] and these are applicable for all the models
> >    described in this documents. The model specific security
> >    considerations are documented in their respective protocol
> >    specifications.
> >
> > Place a new top-level section between Sections 5 and 6:
> >
> >    X. Effect on Routing
> >
> >    The model used for in a 802.16 network may have a significant
> >    impact on how routing protocols are run over such a network.
> >    The deployment model presented in this document discusses the
> >    least impacting model on routing as connectivity on the provider
> >    edge is intentionally limited to point to point connectivity
> >    from one BS to any one of multiple MSs. Any other deployment
> >    model may cause a significant impact on routing protocols,
> >    however, but they are outside the scope of this document.
> >
> >
> >
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > 16NG mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/16ng
> >
> >
> > End of 16NG Digest, Vol 5, Issue 22
> > ***********************************
> >
>
>
>
> --
> ------------------------------------------------
> Sang-Eon Kim
> Senior Researcher
> Infra. Lab., KT
> 139-791, Woomyeon-dong, Seocho-gu, Seoul, Korea
>
> Voice: [phone]
> Mobile: [phone]
> E-mail: [e-mail]
> ------------------------------------------------
>
>  ------------------------------
>
> _______________________________________________
> 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