Re: [Roll] mixture of storing and non-storing nodes

정종수 <jsjeong@etri.re.kr> Sat, 25 August 2012 00:33 UTC

Return-Path: <jsjeong@etri.re.kr>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276D621F856F for <roll@ietfa.amsl.com>; Fri, 24 Aug 2012 17:33:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -94.896
X-Spam-Level:
X-Spam-Status: No, score=-94.896 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reKIqk7Y6VQ3 for <roll@ietfa.amsl.com>; Fri, 24 Aug 2012 17:33:11 -0700 (PDT)
Received: from mailx.etri.re.kr (mailx.etri.re.kr [129.254.38.251]) by ietfa.amsl.com (Postfix) with ESMTP id 71A4321F856C for <roll@ietf.org>; Fri, 24 Aug 2012 17:33:11 -0700 (PDT)
Received: from SMTPEG2.etri.info (ssbmailx [127.0.0.1]) by mailx.etri.re.kr (8.13.8/8.13.8) with ESMTP id q7P0X8cl029536; Sat, 25 Aug 2012 09:33:08 +0900
Received: from SMTP2.etri.info (129.254.28.72) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 25 Aug 2012 09:33:11 +0900
Received: from SMTP4.etri.info ([169.254.3.84]) by SMTP2.etri.info ([169.254.2.205]) with mapi id 14.01.0355.002; Sat, 25 Aug 2012 09:33:07 +0900
From: 정종수 <jsjeong@etri.re.kr>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Thread-Topic: [Roll] mixture of storing and non-storing nodes
Thread-Index: AQHNf7qCa3ul5GjnHEWCevy5tyL565dkxJyAgAPytYCAAPueTg==
Date: Sat, 25 Aug 2012 00:33:07 +0000
Message-ID: <4CBBFD41-130A-4FD8-ABBA-B515C3B5CFB0@etri.re.kr>
References: <CAErDfUQV2E5H66k9YjRSGF8RmA=xhQzrDwpyTRBJ8WQUZh3diw@mail.gmail.com> <B7828579-4864-4CBA-A999-808F394D543F@cisco.com>, <30393.1345833153@sandelman.ca>
In-Reply-To: <30393.1345833153@sandelman.ca>
Accept-Language: ko-KR, en-US
Content-Language: ko-KR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="euc-kr"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: roll WG <roll@ietf.org>
Subject: Re: [Roll] mixture of storing and non-storing nodes
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Aug 2012 00:33:12 -0000

Hi Michael.

2012. 8. 25. 오전 4:23 "Michael Richardson" <mcr+ietf@sandelman.ca> 작성:

> 
>   OG> John Ko posted a draft a few days ago about how we might accommodate a
>   OG> mixture of storing and non-storing nodes in a network more efficiently
>   OG> than making one of them leaf nodes. Searching through the ROLL mail
>   OG> archives, it was clear at the time that there was no use case for
>   OG> having a network that has a mixture of storing and non-storing
>   OG> nodes.
> 
>   JP> I cannot agree more - actually we even have a partial to the
>   JP> problem during the initial design phase and the WG collectively
>   JP> decided not to mix storing and non-storing in light of the added
>   JP> complexity. I would also appreciate the feedback of the WG on
>   JP> this, and not add complexity unless this becomes a strong
>   JP> requirement. 
> 
> I believe that use cases for storing and non-storing nodes would appear
> as optimizations (particularly in the p2p heavy LLNs) if we could figure
> out how to make it work.
> 

You're right. Additionally, mixture of storing and non-storing nodes can cause inefficient upwards routing in the current RPL. Because nodes that can support only different MOP from the root's MOP should act as a leaf node. Furthermore, if the leaf node is an only node that is at intermediate place physically to forward upstream traffic, not only downwards but also upwards routing will not work from this point.

> I think that the major problem was that nodes below the root needed to
> know if there downstreams nodes were storing or not, and thus
> non-storing nodes wound up picking up significant resource impact, when
> those nodes were supposed to be lighter weight.
> 
> -- 
> Michael Richardson
> -at the cottage-
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

Thank you.
-Jongsoo