[16NG] Re: 16NG Digest, Vol 5, Issue 22

" 김상언 " <kim.sangeon@gmail.com> Mon, 30 April 2007 14:14 UTC

Return-path: <16ng-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiWdk-00040V-JY; Mon, 30 Apr 2007 10:14:08 -0400
Received: from 16ng by megatron.ietf.org with local (Exim 4.43) id 1HiWdj-0003vC-Cs for 16ng-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 10:14:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiWdj-0003uH-0f for 16ng@ietf.org; Mon, 30 Apr 2007 10:14:07 -0400
Received: from an-out-0708.google.com ([209.85.132.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiWdh-0004tX-9J for 16ng@ietf.org; Mon, 30 Apr 2007 10:14:06 -0400
Received: by an-out-0708.google.com with SMTP id d30so1397551and for <16ng@ietf.org>; Mon, 30 Apr 2007 07:14:00 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=XGUsWj8iRf/cHd3Tw/XqRpD/tKBAHIt26aleHlY5yV+hvzh9TNamjAnxJybNx1WmlrpzhWkaq6oOeHSRLp9fQQEL8gbMSwokktiRdIMq+cKvZ5MBcqaN739qIBqbaMAwRTFvv4+l+gGQn6ShPugh9AgXpG9IikHQMWb9bIbqydI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=dlWDoVTI3Xx2KLnvnRevI4E3uBcTNHk16H2T4D8XK+wM29nyyZiiZaf4nb6QWLQuEmhCv9O5KyttpP/QXT/3wpF97WmJwJwAwY1/8woDgU29/xzvG+wrYDPtk0XbfVS9xZaUT29/Z5//tG0DwET5o5CiE4jfuvhHWr6OkCCxGLU=
Received: by 10.100.13.12 with SMTP id 12mr3998174anm.1177942440037; Mon, 30 Apr 2007 07:14:00 -0700 (PDT)
Received: by 10.100.164.1 with HTTP; Mon, 30 Apr 2007 07:13:59 -0700 (PDT)
Message-ID: <7d5d1f6f0704300713t16b7171es2f7426b88c786ff3@mail.gmail.com>
Date: Mon, 30 Apr 2007 23:13:59 +0900
From: "=?EUC-KR?B?sei7877w?=" <kim.sangeon@gmail.com>
To: 16ng@ietf.org
In-Reply-To: <E1HhSPg-0005CL-W5@megatron.ietf.org>
MIME-Version: 1.0
References: <E1HhSPg-0005CL-W5@megatron.ietf.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8
Cc: iab@iab.org, 16ng-chairs@tools.ietf.org
Subject: [16NG] Re: 16NG Digest, Vol 5, Issue 22
X-BeenThere: 16ng@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 16ng working group discussion list <16ng.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/16ng>
List-Post: <mailto:16ng@ietf.org>
List-Help: <mailto:16ng-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2050659673=="
Errors-To: 16ng-bounces@ietf.org

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, 16ng-request@ietf.org <16ng-request@ietf.org>rg>:
>
> Send 16NG mailing list submissions to
>        16ng@ietf.org
>
> 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
>        16ng-request@ietf.org
>
> You can reach the person managing the list at
>        16ng-owner@ietf.org
>
> 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 <iesg-secretary@ietf.org>
> Subject: [16NG] Document Action: 'Analysis of IPv6 Link Models for
>        802.16 based Networks' to Informational RFC
> To: IETF-Announce <ietf-announce@ietf.org>
> Cc: Internet Architecture Board <iab@iab.org>rg>,  16ng mailing list
>        <16ng@ietf.org>rg>, 16ng chair <16ng-chairs@tools.ietf.org>rg>,       RFC
> Editor
>        <rfc-editor@rfc-editor.org>
> Message-ID: <E1HhSP4-00025w-LX@stiedprstage1.ietf.org>
>
> 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
> 16NG@ietf.org
> 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: +82-2-526-6117
Mobile: +82-10-3073-4084
E-mail: Kim.SangEon@gmail.com
------------------------------------------------
_______________________________________________
16NG mailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng