From 6lowpan-bounces@ietf.org Sun Oct 5 16:01:53 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C64613A690A; Sun, 5 Oct 2008 16:01:53 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C53703A68E5 for <6lowpan@core3.amsl.com>; Sun, 5 Oct 2008 16:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.777 X-Spam-Level: X-Spam-Status: No, score=-4.777 tagged_above=-999 required=5 tests=[AWL=-0.658, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bc2a6NOfsDVs for <6lowpan@core3.amsl.com>; Sun, 5 Oct 2008 16:01:50 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6438F3A6879 for <6lowpan@ietf.org>; Sun, 5 Oct 2008 16:01:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,365,1220227200"; d="scan'208,217";a="23291230" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 05 Oct 2008 23:02:23 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m95N2NXJ027362 for <6lowpan@ietf.org>; Sun, 5 Oct 2008 19:02:23 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m95N2NBO007729 for <6lowpan@ietf.org>; Sun, 5 Oct 2008 23:02:23 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 5 Oct 2008 19:02:23 -0400 Received: from 10.61.109.242 ([10.61.109.242]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Sun, 5 Oct 2008 23:02:23 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Sun, 05 Oct 2008 16:02:20 -0700 From: JP Vasseur To: <6lowpan@ietf.org> Message-ID: Thread-Topic: [Roll] FW: Details of the ROLL Interim WG Meeting next week Thread-Index: Ackj8zuOOPiZpFlvgke5pYHcPNo4/wAAIC/CANKrxg4= In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 05 Oct 2008 23:02:23.0542 (UTC) FILETIME=[6D815D60:01C9273E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6604; t=1223247743; x=1224111743; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20FW=3A=20[Roll]=20FW=3A=20=20Details=20of=20the= 20ROLL=20Interim=20WG=20Meeting=20next=20week |Sender:=20 |To:=20<6lowpan@ietf.org>; bh=ExL+spaI8ajJ5GmrGk/j5hV01qfwKmZoS8tPrS87+HU=; b=hmDIQeQjzpllacUmwuVhOIlI48JxN+0cPytf6g0BggNehSKPDWZMH5nl1v 8FScmlL1WdQmpWKlfmCBPkGcICBWb9YCoEVZF867eN68E3KcFfrw6rmGEa7M ztnVcDSsbS; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: [6lowpan] FW: [Roll] FW: Details of the ROLL Interim WG Meeting next week X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0966300324==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0966300324== Content-type: multipart/alternative; boundary="B_3306067340_4833995" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3306067340_4833995 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit FYI ------ Forwarded Message From: JP Vasseur Date: Wed, 01 Oct 2008 20:30:10 +0200 To: Cc: "David E. Culler" Subject: [Roll] FW: Details of the ROLL Interim WG Meeting next week Sorry I forgot to mention the time: Oct 6 from 2pm to 4:30pm Thanks. JP and David. ------ Forwarded Message From: JP Vasseur Date: Wed, 01 Oct 2008 20:26:34 +0200 To: Cc: "David E. Culler" Subject: [Roll] Details of the ROLL Interim WG Meeting next week Dear all, Here are the details for the Interim ROLL WG Meeting next week: Date: October 6, 2008 Location: Cisco Systems Building 18, First floor, Room name: DEEP SPACE NINE 3600 Cisco Way San Jose, California 95134 United States Here are the dial-in details for remote attendance. Again thanks to send me a quick email confirming your attendance for logistics. Date/Time: OCT 6, 2008 at 2:00PM America/Los_Angeles Length: 150 Frequency: 1 Meeting ID: 131191510 Meeting Password: Global Access Numbers: http://cisco.com/en/US/about/doing_business/conferencing/index.html San Jose, CA: +408.525.6800 RTP: +919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4103.3979 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------ End of Forwarded Message _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------ End of Forwarded Message --B_3306067340_4833995 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable FW: [Roll] FW:  Details of the ROLL Interim WG Meeting next wee= k FYI

------ Forwarded Message
From: JP Vasseur <jvasseur@cisco.com= >
Date: Wed, 01 Oct 2008 20:30:10 +0200
To: <roll@ietf.org>
Cc: "David E. Culler" <culler@eecs.berkeley.edu>
Subject: [Roll] FW:  Details of the ROLL Interim WG Meeting nex= t week

Sorry I forgot to mention the time:

Oct 6 from 2pm to 4:30pm

Thanks.

JP and David.

------ Forwarded Message
From: JP Vasseur <jvasseur@cisco.com= >
Date: Wed, 01 Oct 2008 20:26:34 +0200
To: <roll@ietf.org>
Cc: "David E. Culler" <culler@eecs.berkeley.edu>
Subject: [Roll] Details of the ROLL Interim WG Meeting next week

Dear all,

Here are the details for the Interim ROLL WG Meeting next week:

Date: October 6, 2008
Location: Cisco Systems

Building 18, First floor, Room name: DEEP SPACE NINE

3600 Cisco Way
San Jose, California 95134
United States

Here are the dial-in details for remote attendance.
 
Again thanks to send me a quick email confirming your attendance for = logistics.
Date/Time:           &nbs= p;  OCT 6, 2008 at 2:00PM America/Los_Angeles
Length:            &= nbsp;    150
Frequency:           &nbs= p;  1
Meeting ID:           &nb= sp; 131191510
Meeting Password:        
 
Global Access Numbers:
http://cisco.com/en/US/about/doing_business/conferencing/index.html  
    San Jose, CA: +408.525.6800   RTP:  =            +919.392.3= 330      
    US/Canada:  +1.866.432.9903    = United Kingdom:   +44.20.8824.0117
    India:     +91.80.4103.3979 &nb= sp;Germany:          +49.619.67= 73.9002
    Japan:     +81.3.5763.9394 &nbs= p; China:           += 86.10.8515.5666
 
Thanks.

JP.
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

------ End of Forwarded Message

___________= ____________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

------ End of Forwarded Message
 --B_3306067340_4833995-- --===============0966300324== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan --===============0966300324==-- From 6lowpan-bounces@ietf.org Mon Oct 6 03:58:44 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DE503A6AAD; Mon, 6 Oct 2008 03:58:44 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAA283A6AB1 for <6lowpan@core3.amsl.com>; Mon, 6 Oct 2008 03:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3b4rkQyzl-1h for <6lowpan@core3.amsl.com>; Mon, 6 Oct 2008 03:58:42 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id BB6D23A67AC for <6lowpan@ietf.org>; Mon, 6 Oct 2008 03:58:41 -0700 (PDT) Received: from h163127.gprs.dnafinland.fi (h163127.gprs.dnafinland.fi [87.93.163.127]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id m96Ax8IO026264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6lowpan@ietf.org>; Mon, 6 Oct 2008 13:59:10 +0300 Message-ID: <48E9EF7C.1030300@sensinode.com> Date: Mon, 06 Oct 2008 13:59:08 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org> Subject: [6lowpan] ND for 6LoWPAN status X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi, We've received quite a few inquiries, so I wanted to keep the WG updated. The author group writing the ND for 6LoWPAN draft has been making good progress since formed in Dublin. Together with Pascal, Jonathan, Samita, Erik and myself, we start to have a stable design. I will submit -00 of the new ID by October 24th. Regards, Zach _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 6 14:06:40 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B355A28C1FF; Mon, 6 Oct 2008 14:06:40 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D96EB28C1F4 for <6lowpan@core3.amsl.com>; Mon, 6 Oct 2008 14:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.135 X-Spam-Level: X-Spam-Status: No, score=-3.135 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r08FRgLabAfA for <6lowpan@core3.amsl.com>; Mon, 6 Oct 2008 14:06:38 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D889628C1B5 for <6lowpan@ietf.org>; Mon, 6 Oct 2008 14:06:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,369,1220227200"; d="scan'208,217";a="23393136" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 06 Oct 2008 21:07:14 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m96L7Egn024858 for <6lowpan@ietf.org>; Mon, 6 Oct 2008 17:07:14 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m96L7EHD009693 for <6lowpan@ietf.org>; Mon, 6 Oct 2008 21:07:14 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Oct 2008 17:07:14 -0400 Received: from 171.70.8.125 ([171.70.8.125]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Mon, 6 Oct 2008 21:07:12 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Mon, 06 Oct 2008 14:07:10 -0700 From: JP Vasseur To: <6lowpan@ietf.org> Message-ID: Thread-Topic: [Roll] New Bridge Thread-Index: Ackn9rsGI4dcLdFIi0mH9i+2r2qDdQAAMQai In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 06 Oct 2008 21:07:14.0505 (UTC) FILETIME=[81CFBB90:01C927F7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4052; t=1223327234; x=1224191234; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20FW=3A=20[Roll]=20New=20Bridge |Sender:=20 |To:=20<6lowpan@ietf.org>; bh=5h4DLIMr5sSFuDmd4MkgE6NkkNnnD2hAhFZw3v2UIOw=; b=m9qcDE1dSa8kcjhCAJ/fhyig/U+4YilA6Go+7yzi4R8GAnp/8mKzIzWTp0 cLUYT26KT8NYsVC6DvYs6Ie6rXymIplQllqzx1I92HeCdVGV2r2A6V+JpXn7 7mQ6vVEb94; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: [6lowpan] FW: [Roll] New Bridge X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1661350340==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1661350340== Content-type: multipart/alternative; boundary="B_3306146830_6830429" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3306146830_6830429 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit ------ Forwarded Message From: JP Vasseur Date: Mon, 06 Oct 2008 14:01:41 -0700 To: Subject: [Roll] New Bridge Sorry but the bridge was not working thus I set up this new one: Date/Time: October 06, 2008 at 04:59PM America/New_York Length: 60 Frequency: once Meeting ID: 2229361252 Meeting Password: Global Access Numbers: http://cisco.com/en/US/about/doing_business/conferencing/index.html San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4103.3979 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------ End of Forwarded Message --B_3306146830_6830429 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable FW: [Roll] New Bridge
------ Forwarded Message
From: JP Vasseur <jvasseur@cisco.com= >
Date: Mon, 06 Oct 2008 14:01:41 -0700
To: <roll@ietf.org>
Subject: [Roll] New Bridge

Sorry but the bridge was not working thus I set up this new one:

Date/Time:           &nbs= p;   October 06, 2008 at 04:59PM America/New_York
Length:            &= nbsp;     60
Frequency:           &nbs= p;   once
Meeting ID:           &nb= sp;  2229361252
Meeting Password:        

Global Access Numbers:
http://cisco.com/en/US/about/doing_business/conf= erencing/index.html

    San Jose, CA: +1.408.525.6800    RTP= :             &n= bsp;+1.919.392.3330      
    US/Canada:  +1.866.432.9903    = United Kingdom:   +44.20.8824.0117
    India:      +91.80.4103.39= 79   Germany:         &nbs= p;+49.619.6773.9002
    Japan:      +81.3.5763.939= 4    China:         &= nbsp;  +86.10.8515.5666
<= FONT SIZE=3D"1">_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

------ End of Forwarded Message
 --B_3306146830_6830429-- --===============1661350340== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan --===============1661350340==-- From 6lowpan-bounces@ietf.org Tue Oct 7 06:30:39 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E06A73A6B76; Tue, 7 Oct 2008 06:30:39 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D49A3A6B7C for <6lowpan@core3.amsl.com>; Tue, 7 Oct 2008 06:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rcd7oSyNNdH for <6lowpan@core3.amsl.com>; Tue, 7 Oct 2008 06:30:37 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 0AC693A6A00 for <6lowpan@ietf.org>; Tue, 7 Oct 2008 06:30:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,372,1220227200"; d="scan'208";a="21865918" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 07 Oct 2008 13:29:45 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m97DTjoa028969 for <6lowpan@ietf.org>; Tue, 7 Oct 2008 15:29:45 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m97DTj8M017860 for <6lowpan@ietf.org>; Tue, 7 Oct 2008 13:29:45 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Oct 2008 15:29:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Oct 2008 15:29:30 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC06576D2D@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Separating T and F Thread-Index: AckogLqVN0bY5oh1TemQjx6nQ/uJbg== From: "Pascal Thubert (pthubert)" To: <6lowpan@ietf.org> X-OriginalArrivalTime: 07 Oct 2008 13:29:45.0690 (UTC) FILETIME=[C374B3A0:01C92880] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1581; t=1223386185; x=1224250185; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20Separating=20T=20and=20F |Sender:=20; bh=toxrs/Ttry6fBVQw9kEzjquYGeADIFDOQvLApsVYKmw=; b=s4xClibYRnIRezjeMzdtCQXHnyGGcku0oOlqkGWRXHqfrdEaOJIIQhtmDT swsBQacU8k+6XLIQ/8dDWveiKWPXy7EAQWK/BGK8sCjbh5IS3eqauesdXYrL 92YuCV8pX8; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [6lowpan] Separating T and F X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Jonathan: It troubles me though that we cannot isolate the T from the VF because I can see the need to report congestion and to apply diffserv in route over. To give you examples, ISA cares (sometimes) about the flow label but not the ToS bits because being mesh under this is all carried in MAC extensions. And the ISA flow label needs only 2 bytes. And in many route over case, I expect the reverse, caring about the ToS bits but not the Flow Label. Proposal: The VTF bit becomes "another HC byte for VTF", if the bit is reset VTF fields are all compressed, if set then how to compress VTF is in the next byte. Then we'd have control bits to say how many bytes to TF follow and what's in there Combinations we need to support: No compression: Need 4 bytes. Control is 1111 and then 24 bits F and then T Compressing T only: Need 3 bytes. Control is 1110 and then 24 bits F Precedence + 2 bytes Flow: Need 3 bytes. Control is 110 and then 2 bit ECN, 3 bits precedence and 16 bits rightmost F Compressing DSCP : Need 3 bytes. Control is 10 and and then 24 bits F. Compress F: Need one byte. Control is 0 then 2 bit ECN and the next 5 bits are T striped from the rightmost bit. This is obtained by rotating the byte by 3 so that the first bit is now the least significant DSCP bit So that compression does not allow odd DSCPs but you'll notice that most DSCPs are even)... This is also compatible with the precedence model. See page 14 of attached doc for more. What do you think? Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Oct 7 09:49:15 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13A803A6B28; Tue, 7 Oct 2008 09:49:15 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC0433A6B28 for <6lowpan@core3.amsl.com>; Tue, 7 Oct 2008 09:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVxhC5r3vfae for <6lowpan@core3.amsl.com>; Tue, 7 Oct 2008 09:49:13 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id F0E313A6B1B for <6lowpan@ietf.org>; Tue, 7 Oct 2008 09:49:12 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id C8F70AF8C9; Tue, 7 Oct 2008 09:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaapcW6SPLrU; Tue, 7 Oct 2008 09:49:50 -0700 (PDT) Received: from [192.168.7.75] (69-12-164-137.sfo.archrock.com [69.12.164.137]) by mail.sf.archrock.com (Postfix) with ESMTP id F2B16AF8E1; Tue, 7 Oct 2008 09:49:49 -0700 (PDT) Message-Id: From: Jonathan Hui To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC06576D2D@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 7 Oct 2008 09:49:48 -0700 References: <7892795E1A87F04CADFCCF41FADD00FC06576D2D@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Separating T and F X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Pascal: Overall, I like the idea of separating T from F in the compression format. That is why I had separate bits for them in hc-01. Unfortunately, it meant adding a byte to the encoding. Here's one idea to extend the idea while keeping the encoding at 1 byte: what if we steal a bit from the dispatch value? The argument is that this HC should be used very often, so we can afford to take some of the dispatch space (similar to how Mesh Addressing and Fragmentation got 2- bit forms of the header identifier). So here's one idea: Base Encoding 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 0 | 1 | 0 | 0 | 1 | CTX | TF |NH | HLIM | SAM | DAM | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - Dispatch: 8-15 - CTX: Context - 00: Link-Local - 01: Global (1 context) - 10: Global (16 contexts) - 11: Reserved - TF: Traffic Class, Flow Label - 00: 4-bit Pad + Traffic Class + Flow Label (4 bytes) - 01: ECN + 2-bit Pad + Flow Label (3 bytes) - 10: Traffic Class (1 byte) - 11: No Traffic Class and Flow Label - NH: Next Header compression - HLIM: Hop Limit - 00: uncompressed - 01: 1 - 10: 64 - 11: 255 - SAM: Source Address Mode - prefix is link-local, when compressed - 00: 128 bits - 01: 64 bits - 10: 16 bits - 11: 0 bits - DAM: Destination Address Mode - prefix is link-local, when compressed - 00: 128 bits - 01: 64 bits - 10: 16 bits - 11: 0 bits CTX is just to say what contexts we are using for compression - this is similar to using different dispatch values in the original proposal, except that we explicitly allocate the bits here. TF is now expanded to support 3 different encodings of Traffic Class and Flow Label. I think it simplifies the encoding (3 encodings vs. 5) and carries the full Traffic Class unmodified when uncompressed. Does that satisfy your needs? -- Jonathan Hui On Oct 7, 2008, at 6:29 AM, Pascal Thubert (pthubert) wrote: > Hi Jonathan: > > It troubles me though that we cannot isolate the T from the VF > because I > can see the need to report congestion and to apply diffserv in route > over. > > To give you examples, ISA cares (sometimes) about the flow label but > not > the ToS bits because being mesh under this is all carried in MAC > extensions. And the ISA flow label needs only 2 bytes. And in many > route > over case, I expect the reverse, caring about the ToS bits but not the > Flow Label. > > Proposal: The VTF bit becomes "another HC byte for VTF", if the bit is > reset VTF fields are all compressed, if set then how to compress VTF > is > in the next byte. Then we'd have control bits to say how many bytes to > TF follow and what's in there > > Combinations we need to support: > > No compression: Need 4 bytes. Control is 1111 and then 24 bits F and > then T > > Compressing T only: Need 3 bytes. Control is 1110 and then 24 bits F > > Precedence + 2 bytes Flow: Need 3 bytes. Control is 110 and then 2 bit > ECN, > 3 bits precedence and 16 bits > rightmost F > > Compressing DSCP : Need 3 bytes. Control is 10 and and then 24 bits > F. > > Compress F: Need one byte. Control is 0 then 2 bit ECN and the next 5 > bits are T striped from the rightmost bit. This is obtained by > rotating > the byte by 3 so that the first bit is now the least significant DSCP > bit So that compression does not allow odd DSCPs but you'll notice > that > most DSCPs are even)... This is also compatible with the precedence > model. See page 14 of attached doc for more. > > What do you think? > > Pascal > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Oct 7 10:09:00 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06ECD3A6AE6; Tue, 7 Oct 2008 10:09:00 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85F963A6AE6 for <6lowpan@core3.amsl.com>; Tue, 7 Oct 2008 10:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1h49WNRVcJU for <6lowpan@core3.amsl.com>; Tue, 7 Oct 2008 10:08:57 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 041B43A67F3 for <6lowpan@ietf.org>; Tue, 7 Oct 2008 10:08:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,373,1220227200"; d="scan'208";a="21896340" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 07 Oct 2008 17:09:00 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m97H90x1008871; Tue, 7 Oct 2008 19:09:00 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m97H90Ys004449; Tue, 7 Oct 2008 17:09:00 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Oct 2008 19:09:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Oct 2008 19:06:11 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC06576EE4@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Separating T and F Thread-Index: AckonMbblLHKUmT8SvuL/9jKpHNEzgAABN+g References: <7892795E1A87F04CADFCCF41FADD00FC06576D2D@xmb-ams-337.emea.cisco.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 07 Oct 2008 17:09:00.0409 (UTC) FILETIME=[64478690:01C9289F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4730; t=1223399340; x=1224263340; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20Separating=20T=20and=20F |Sender:=20; bh=ANLWsonULt33iRNuQYk8Me33NtGylc/LtXBV5acZP2I=; b=klXWQVH0zDp4flBQmniHQs+fU6+6JSc+xdgfGbiM+QXR21Tl71AImhPEuQ PdwQy+oon/+V71IxpM4NkF3dNz8uX4byPMoLqTVIgnuv0jzraH8B+ayn1TXX U+ndLBbgaS; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Separating T and F X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Jonathan, that's perfect. Your proposal: - enables the T/F separation - enables the 2 contexts All without adding an octet which was a dreadful idea. So I'm all for it. The only trouble I have is that ECN is located in various places making it harder for a forwarding node to locate and update. But I have no better proposal in mind either. Anyone? If nobody complains I suggest to go for this change in the 01 release of the WG doc. Pascal >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com] >Sent: mardi 7 octobre 2008 18:50 >To: Pascal Thubert (pthubert) >Cc: 6lowpan@ietf.org >Subject: Re: [6lowpan] Separating T and F > > >Hi Pascal: > >Overall, I like the idea of separating T from F in the compression >format. That is why I had separate bits for them in hc-01. >Unfortunately, it meant adding a byte to the encoding. Here's one idea >to extend the idea while keeping the encoding at 1 byte: what if we >steal a bit from the dispatch value? The argument is that this HC >should be used very often, so we can afford to take some of the >dispatch space (similar to how Mesh Addressing and Fragmentation got 2- >bit forms of the header identifier). > >So here's one idea: > >Base Encoding > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > | 0 | 1 | 0 | 0 | 1 | CTX | TF |NH | HLIM | SAM | DAM | > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > >- Dispatch: 8-15 >- CTX: Context > - 00: Link-Local > - 01: Global (1 context) > - 10: Global (16 contexts) > - 11: Reserved >- TF: Traffic Class, Flow Label > - 00: 4-bit Pad + Traffic Class + Flow Label (4 bytes) > - 01: ECN + 2-bit Pad + Flow Label (3 bytes) > - 10: Traffic Class (1 byte) > - 11: No Traffic Class and Flow Label >- NH: Next Header compression >- HLIM: Hop Limit > - 00: uncompressed > - 01: 1 > - 10: 64 > - 11: 255 >- SAM: Source Address Mode - prefix is link-local, when compressed > - 00: 128 bits > - 01: 64 bits > - 10: 16 bits > - 11: 0 bits >- DAM: Destination Address Mode - prefix is link-local, when compressed > - 00: 128 bits > - 01: 64 bits > - 10: 16 bits > - 11: 0 bits > >CTX is just to say what contexts we are using for compression - this >is similar to using different dispatch values in the original >proposal, except that we explicitly allocate the bits here. TF is now >expanded to support 3 different encodings of Traffic Class and Flow >Label. I think it simplifies the encoding (3 encodings vs. 5) and >carries the full Traffic Class unmodified when uncompressed. > >Does that satisfy your needs? > >-- >Jonathan Hui > > > >On Oct 7, 2008, at 6:29 AM, Pascal Thubert (pthubert) wrote: > >> Hi Jonathan: >> >> It troubles me though that we cannot isolate the T from the VF >> because I >> can see the need to report congestion and to apply diffserv in route >> over. >> >> To give you examples, ISA cares (sometimes) about the flow label but >> not >> the ToS bits because being mesh under this is all carried in MAC >> extensions. And the ISA flow label needs only 2 bytes. And in many >> route >> over case, I expect the reverse, caring about the ToS bits but not the >> Flow Label. >> >> Proposal: The VTF bit becomes "another HC byte for VTF", if the bit is >> reset VTF fields are all compressed, if set then how to compress VTF >> is >> in the next byte. Then we'd have control bits to say how many bytes to >> TF follow and what's in there >> >> Combinations we need to support: >> >> No compression: Need 4 bytes. Control is 1111 and then 24 bits F and >> then T >> >> Compressing T only: Need 3 bytes. Control is 1110 and then 24 bits F >> >> Precedence + 2 bytes Flow: Need 3 bytes. Control is 110 and then 2 bit >> ECN, >> 3 bits precedence and 16 bits >> rightmost F >> >> Compressing DSCP : Need 3 bytes. Control is 10 and and then 24 bits >> F. >> >> Compress F: Need one byte. Control is 0 then 2 bit ECN and the next 5 >> bits are T striped from the rightmost bit. This is obtained by >> rotating >> the byte by 3 so that the first bit is now the least significant DSCP >> bit So that compression does not allow odd DSCPs but you'll notice >> that >> most DSCPs are even)... This is also compatible with the precedence >> model. See page 14 of attached doc for more. >> >> What do you think? >> >> Pascal >> >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Oct 7 11:01:35 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 944573A6B66; Tue, 7 Oct 2008 11:01:35 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F21723A6B66 for <6lowpan@core3.amsl.com>; Tue, 7 Oct 2008 11:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cr0Scti39ENQ for <6lowpan@core3.amsl.com>; Tue, 7 Oct 2008 11:01:33 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id BB7C93A6AAC for <6lowpan@ietf.org>; Tue, 7 Oct 2008 11:01:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,373,1220227200"; d="scan'208";a="21899766" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 07 Oct 2008 18:01:55 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m97I1tLs017310; Tue, 7 Oct 2008 20:01:55 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m97HsJLD012932; Tue, 7 Oct 2008 18:01:55 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Oct 2008 19:57:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Oct 2008 19:57:36 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC06576F0F@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Separating T and F Thread-Index: AckonMbblLHKUmT8SvuL/9jKpHNEzgACSXxQ References: <7892795E1A87F04CADFCCF41FADD00FC06576D2D@xmb-ams-337.emea.cisco.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 07 Oct 2008 17:57:45.0183 (UTC) FILETIME=[33949EF0:01C928A6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4636; t=1223402515; x=1224266515; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20Separating=20T=20and=20F |Sender:=20; bh=6obarzV0bc541EgRz1d5MDnd/L1ujVM/z4HaJ0FRpI4=; b=HxKZFLX0dGrLrHYq7OViYWauq9ZaT+YiQTw87S9XhSlxmW43DhYImcUcFD oeWtCOlFJyGbme3R00Urq3Mo5xjcaPJfbEaB2Yq7sbWt1ZN/9PJPb2OYduYz L19T6h9pJK; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Separating T and F X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Jonathan: Let me propose a small delta for the context: - 00: Link-Local - 01: UL/Global (default context) - 10: UL/Global (backup context) - 11: UL/Global (16 contexts, a byte after the HC contains the contexts for source and destination) This way we can have the 2 contexts without the burden of the additional byte, what do you think? Pascal >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com] >Sent: mardi 7 octobre 2008 18:50 >To: Pascal Thubert (pthubert) >Cc: 6lowpan@ietf.org >Subject: Re: [6lowpan] Separating T and F > > >Hi Pascal: > >Overall, I like the idea of separating T from F in the compression >format. That is why I had separate bits for them in hc-01. >Unfortunately, it meant adding a byte to the encoding. Here's one idea >to extend the idea while keeping the encoding at 1 byte: what if we >steal a bit from the dispatch value? The argument is that this HC >should be used very often, so we can afford to take some of the >dispatch space (similar to how Mesh Addressing and Fragmentation got 2- >bit forms of the header identifier). > >So here's one idea: > >Base Encoding > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > | 0 | 1 | 0 | 0 | 1 | CTX | TF |NH | HLIM | SAM | DAM | > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > >- Dispatch: 8-15 >- CTX: Context > - 00: Link-Local > - 01: Global (1 context) > - 10: Global (16 contexts) > - 11: Reserved >- TF: Traffic Class, Flow Label > - 00: 4-bit Pad + Traffic Class + Flow Label (4 bytes) > - 01: ECN + 2-bit Pad + Flow Label (3 bytes) > - 10: Traffic Class (1 byte) > - 11: No Traffic Class and Flow Label >- NH: Next Header compression >- HLIM: Hop Limit > - 00: uncompressed > - 01: 1 > - 10: 64 > - 11: 255 >- SAM: Source Address Mode - prefix is link-local, when compressed > - 00: 128 bits > - 01: 64 bits > - 10: 16 bits > - 11: 0 bits >- DAM: Destination Address Mode - prefix is link-local, when compressed > - 00: 128 bits > - 01: 64 bits > - 10: 16 bits > - 11: 0 bits > >CTX is just to say what contexts we are using for compression - this >is similar to using different dispatch values in the original >proposal, except that we explicitly allocate the bits here. TF is now >expanded to support 3 different encodings of Traffic Class and Flow >Label. I think it simplifies the encoding (3 encodings vs. 5) and >carries the full Traffic Class unmodified when uncompressed. > >Does that satisfy your needs? > >-- >Jonathan Hui > > > >On Oct 7, 2008, at 6:29 AM, Pascal Thubert (pthubert) wrote: > >> Hi Jonathan: >> >> It troubles me though that we cannot isolate the T from the VF >> because I >> can see the need to report congestion and to apply diffserv in route >> over. >> >> To give you examples, ISA cares (sometimes) about the flow label but >> not >> the ToS bits because being mesh under this is all carried in MAC >> extensions. And the ISA flow label needs only 2 bytes. And in many >> route >> over case, I expect the reverse, caring about the ToS bits but not the >> Flow Label. >> >> Proposal: The VTF bit becomes "another HC byte for VTF", if the bit is >> reset VTF fields are all compressed, if set then how to compress VTF >> is >> in the next byte. Then we'd have control bits to say how many bytes to >> TF follow and what's in there >> >> Combinations we need to support: >> >> No compression: Need 4 bytes. Control is 1111 and then 24 bits F and >> then T >> >> Compressing T only: Need 3 bytes. Control is 1110 and then 24 bits F >> >> Precedence + 2 bytes Flow: Need 3 bytes. Control is 110 and then 2 bit >> ECN, >> 3 bits precedence and 16 bits >> rightmost F >> >> Compressing DSCP : Need 3 bytes. Control is 10 and and then 24 bits >> F. >> >> Compress F: Need one byte. Control is 0 then 2 bit ECN and the next 5 >> bits are T striped from the rightmost bit. This is obtained by >> rotating >> the byte by 3 so that the first bit is now the least significant DSCP >> bit So that compression does not allow odd DSCPs but you'll notice >> that >> most DSCPs are even)... This is also compatible with the precedence >> model. See page 14 of attached doc for more. >> >> What do you think? >> >> Pascal >> >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Oct 7 11:33:13 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F6A228C0DC; Tue, 7 Oct 2008 11:33:13 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 843C03A6967 for <6lowpan@core3.amsl.com>; Tue, 7 Oct 2008 11:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sT8LOTXD3iyg for <6lowpan@core3.amsl.com>; Tue, 7 Oct 2008 11:33:11 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 7EA243A67A1 for <6lowpan@ietf.org>; Tue, 7 Oct 2008 11:33:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id E9DA9AF923; Tue, 7 Oct 2008 11:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTwmj4gdN6Mb; Tue, 7 Oct 2008 11:33:49 -0700 (PDT) Received: from [192.168.7.75] (69-12-164-137.sfo.archrock.com [69.12.164.137]) by mail.sf.archrock.com (Postfix) with ESMTP id A330CAF916; Tue, 7 Oct 2008 11:33:49 -0700 (PDT) Message-Id: <4E2F6997-DE19-493A-BBF9-2B2230A59187@archrock.com> From: Jonathan Hui To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC06576F0F@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 7 Oct 2008 11:33:48 -0700 References: <7892795E1A87F04CADFCCF41FADD00FC06576D2D@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC06576F0F@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Separating T and F X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Pascal: The challenge is that it would be nice to specify the context for the source and destination addresses individually. For example, I have two contexts: 1 for the PAN and 1 for the common peer/subnet that all nodes communicate with outside the PAN. Most of the time the encoding will use both contexts simultaneously. I could grab yet another bit from the dispatch, expand CTX to 3 bits then there's more than enough to do what you suggest. What do you/others think? -- Jonathan Hui On Oct 7, 2008, at 10:57 AM, Pascal Thubert (pthubert) wrote: > Jonathan: > > Let me propose a small delta for the context: > > > - 00: Link-Local > - 01: UL/Global (default context) > - 10: UL/Global (backup context) > - 11: UL/Global (16 contexts, a byte after the HC contains the > contexts for source and destination) > > This way we can have the 2 contexts without the burden of the > additional > byte, what do you think? > > Pascal > >> -----Original Message----- >> From: Jonathan Hui [mailto:jhui@archrock.com] >> Sent: mardi 7 octobre 2008 18:50 >> To: Pascal Thubert (pthubert) >> Cc: 6lowpan@ietf.org >> Subject: Re: [6lowpan] Separating T and F >> >> >> Hi Pascal: >> >> Overall, I like the idea of separating T from F in the compression >> format. That is why I had separate bits for them in hc-01. >> Unfortunately, it meant adding a byte to the encoding. Here's one >> idea >> to extend the idea while keeping the encoding at 1 byte: what if we >> steal a bit from the dispatch value? The argument is that this HC >> should be used very often, so we can afford to take some of the >> dispatch space (similar to how Mesh Addressing and Fragmentation >> got 2- >> bit forms of the header identifier). >> >> So here's one idea: >> >> Base Encoding >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >> | 0 | 1 | 0 | 0 | 1 | CTX | TF |NH | HLIM | SAM | DAM | >> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >> >> - Dispatch: 8-15 >> - CTX: Context >> - 00: Link-Local >> - 01: Global (1 context) >> - 10: Global (16 contexts) >> - 11: Reserved >> - TF: Traffic Class, Flow Label >> - 00: 4-bit Pad + Traffic Class + Flow Label (4 bytes) >> - 01: ECN + 2-bit Pad + Flow Label (3 bytes) >> - 10: Traffic Class (1 byte) >> - 11: No Traffic Class and Flow Label >> - NH: Next Header compression >> - HLIM: Hop Limit >> - 00: uncompressed >> - 01: 1 >> - 10: 64 >> - 11: 255 >> - SAM: Source Address Mode - prefix is link-local, when compressed >> - 00: 128 bits >> - 01: 64 bits >> - 10: 16 bits >> - 11: 0 bits >> - DAM: Destination Address Mode - prefix is link-local, when >> compressed >> - 00: 128 bits >> - 01: 64 bits >> - 10: 16 bits >> - 11: 0 bits >> >> CTX is just to say what contexts we are using for compression - this >> is similar to using different dispatch values in the original >> proposal, except that we explicitly allocate the bits here. TF is now >> expanded to support 3 different encodings of Traffic Class and Flow >> Label. I think it simplifies the encoding (3 encodings vs. 5) and >> carries the full Traffic Class unmodified when uncompressed. >> >> Does that satisfy your needs? >> >> -- >> Jonathan Hui >> >> >> >> On Oct 7, 2008, at 6:29 AM, Pascal Thubert (pthubert) wrote: >> >>> Hi Jonathan: >>> >>> It troubles me though that we cannot isolate the T from the VF >>> because I >>> can see the need to report congestion and to apply diffserv in route >>> over. >>> >>> To give you examples, ISA cares (sometimes) about the flow label but >>> not >>> the ToS bits because being mesh under this is all carried in MAC >>> extensions. And the ISA flow label needs only 2 bytes. And in many >>> route >>> over case, I expect the reverse, caring about the ToS bits but not > the >>> Flow Label. >>> >>> Proposal: The VTF bit becomes "another HC byte for VTF", if the bit > is >>> reset VTF fields are all compressed, if set then how to compress VTF >>> is >>> in the next byte. Then we'd have control bits to say how many bytes > to >>> TF follow and what's in there >>> >>> Combinations we need to support: >>> >>> No compression: Need 4 bytes. Control is 1111 and then 24 bits F and >>> then T >>> >>> Compressing T only: Need 3 bytes. Control is 1110 and then 24 bits F >>> >>> Precedence + 2 bytes Flow: Need 3 bytes. Control is 110 and then 2 > bit >>> ECN, >>> 3 bits precedence and 16 bits >>> rightmost F >>> >>> Compressing DSCP : Need 3 bytes. Control is 10 and and then 24 bits >>> F. >>> >>> Compress F: Need one byte. Control is 0 then 2 bit ECN and the >>> next 5 >>> bits are T striped from the rightmost bit. This is obtained by >>> rotating >>> the byte by 3 so that the first bit is now the least significant >>> DSCP >>> bit So that compression does not allow odd DSCPs but you'll notice >>> that >>> most DSCPs are even)... This is also compatible with the precedence >>> model. See page 14 of attached doc for more. >>> >>> What do you think? >>> >>> Pascal >>> >>> >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Oct 7 13:53:35 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB2E13A67B3; Tue, 7 Oct 2008 13:53:35 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A1683A6768 for <6lowpan@core3.amsl.com>; Tue, 7 Oct 2008 13:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pxo2lEMfbBYk for <6lowpan@core3.amsl.com>; Tue, 7 Oct 2008 13:53:33 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id AF69F3A67B3 for <6lowpan@ietf.org>; Tue, 7 Oct 2008 13:53:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,375,1220227200"; d="scan'208";a="21910155" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 07 Oct 2008 20:54:04 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m97Ks4PE020426; Tue, 7 Oct 2008 22:54:04 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m97Ks4nH015079; Tue, 7 Oct 2008 20:54:04 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Oct 2008 22:54:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Oct 2008 22:53:59 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC06576F56@xmb-ams-337.emea.cisco.com> In-Reply-To: <4E2F6997-DE19-493A-BBF9-2B2230A59187@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Separating T and F Thread-Index: Ackoq0OR9wMSWBAYQui3GSc6eryX/AAExXUw References: <7892795E1A87F04CADFCCF41FADD00FC06576D2D@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC06576F0F@xmb-ams-337.emea.cisco.com> <4E2F6997-DE19-493A-BBF9-2B2230A59187@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 07 Oct 2008 20:54:04.0184 (UTC) FILETIME=[D5281180:01C928BE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6344; t=1223412844; x=1224276844; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20Separating=20T=20and=20F |Sender:=20; bh=M6Vp02GfhLqTjUS4BN+6QjkRR80KUOawvuG5Yd2AU/k=; b=uIDRJLcCYLA02tlpeSiokHap0mBS2uaEMlToLAev5SP1Y27JlG9rf+Sbgz e9kTlnRJE7zQKLOL+zKMRGKRWag7Ebm+1ypLCn37qS+654ZjQz/SpoG4lW10 5wVozPNSEh; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Separating T and F X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Well, that's why I discussed a default and a backup context. If there is a normal (default) context then both ends should be using it. If there's renumbering going on, both ends should be able to switch to the backup. In that vision of things, source should match destination context so one bit is enough for both, you see? OTOH, if you need richness, then use 11 and you get 16 bits for source and 16 bits for destination context. Though even so, IMHO, source and destination contexts should be the same most times. Pascal >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com] >Sent: mardi 7 octobre 2008 20:34 >To: Pascal Thubert (pthubert) >Cc: 6lowpan@ietf.org >Subject: Re: [6lowpan] Separating T and F > > >Hi Pascal: > >The challenge is that it would be nice to specify the context for the >source and destination addresses individually. For example, I have two >contexts: 1 for the PAN and 1 for the common peer/subnet that all >nodes communicate with outside the PAN. Most of the time the encoding >will use both contexts simultaneously. I could grab yet another bit >from the dispatch, expand CTX to 3 bits then there's more than enough >to do what you suggest. > >What do you/others think? > >-- >Jonathan Hui > > > >On Oct 7, 2008, at 10:57 AM, Pascal Thubert (pthubert) wrote: > >> Jonathan: >> >> Let me propose a small delta for the context: >> >> >> - 00: Link-Local >> - 01: UL/Global (default context) >> - 10: UL/Global (backup context) >> - 11: UL/Global (16 contexts, a byte after the HC contains the >> contexts for source and destination) >> >> This way we can have the 2 contexts without the burden of the >> additional >> byte, what do you think? >> >> Pascal >> >>> -----Original Message----- >>> From: Jonathan Hui [mailto:jhui@archrock.com] >>> Sent: mardi 7 octobre 2008 18:50 >>> To: Pascal Thubert (pthubert) >>> Cc: 6lowpan@ietf.org >>> Subject: Re: [6lowpan] Separating T and F >>> >>> >>> Hi Pascal: >>> >>> Overall, I like the idea of separating T from F in the compression >>> format. That is why I had separate bits for them in hc-01. >>> Unfortunately, it meant adding a byte to the encoding. Here's one >>> idea >>> to extend the idea while keeping the encoding at 1 byte: what if we >>> steal a bit from the dispatch value? The argument is that this HC >>> should be used very often, so we can afford to take some of the >>> dispatch space (similar to how Mesh Addressing and Fragmentation >>> got 2- >>> bit forms of the header identifier). >>> >>> So here's one idea: >>> >>> Base Encoding >>> >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>> | 0 | 1 | 0 | 0 | 1 | CTX | TF |NH | HLIM | SAM | DAM | >>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>> >>> - Dispatch: 8-15 >>> - CTX: Context >>> - 00: Link-Local >>> - 01: Global (1 context) >>> - 10: Global (16 contexts) >>> - 11: Reserved >>> - TF: Traffic Class, Flow Label >>> - 00: 4-bit Pad + Traffic Class + Flow Label (4 bytes) >>> - 01: ECN + 2-bit Pad + Flow Label (3 bytes) >>> - 10: Traffic Class (1 byte) >>> - 11: No Traffic Class and Flow Label >>> - NH: Next Header compression >>> - HLIM: Hop Limit >>> - 00: uncompressed >>> - 01: 1 >>> - 10: 64 >>> - 11: 255 >>> - SAM: Source Address Mode - prefix is link-local, when compressed >>> - 00: 128 bits >>> - 01: 64 bits >>> - 10: 16 bits >>> - 11: 0 bits >>> - DAM: Destination Address Mode - prefix is link-local, when >>> compressed >>> - 00: 128 bits >>> - 01: 64 bits >>> - 10: 16 bits >>> - 11: 0 bits >>> >>> CTX is just to say what contexts we are using for compression - this >>> is similar to using different dispatch values in the original >>> proposal, except that we explicitly allocate the bits here. TF is now >>> expanded to support 3 different encodings of Traffic Class and Flow >>> Label. I think it simplifies the encoding (3 encodings vs. 5) and >>> carries the full Traffic Class unmodified when uncompressed. >>> >>> Does that satisfy your needs? >>> >>> -- >>> Jonathan Hui >>> >>> >>> >>> On Oct 7, 2008, at 6:29 AM, Pascal Thubert (pthubert) wrote: >>> >>>> Hi Jonathan: >>>> >>>> It troubles me though that we cannot isolate the T from the VF >>>> because I >>>> can see the need to report congestion and to apply diffserv in route >>>> over. >>>> >>>> To give you examples, ISA cares (sometimes) about the flow label but >>>> not >>>> the ToS bits because being mesh under this is all carried in MAC >>>> extensions. And the ISA flow label needs only 2 bytes. And in many >>>> route >>>> over case, I expect the reverse, caring about the ToS bits but not >> the >>>> Flow Label. >>>> >>>> Proposal: The VTF bit becomes "another HC byte for VTF", if the bit >> is >>>> reset VTF fields are all compressed, if set then how to compress VTF >>>> is >>>> in the next byte. Then we'd have control bits to say how many bytes >> to >>>> TF follow and what's in there >>>> >>>> Combinations we need to support: >>>> >>>> No compression: Need 4 bytes. Control is 1111 and then 24 bits F and >>>> then T >>>> >>>> Compressing T only: Need 3 bytes. Control is 1110 and then 24 bits F >>>> >>>> Precedence + 2 bytes Flow: Need 3 bytes. Control is 110 and then 2 >> bit >>>> ECN, >>>> 3 bits precedence and 16 bits >>>> rightmost F >>>> >>>> Compressing DSCP : Need 3 bytes. Control is 10 and and then 24 bits >>>> F. >>>> >>>> Compress F: Need one byte. Control is 0 then 2 bit ECN and the >>>> next 5 >>>> bits are T striped from the rightmost bit. This is obtained by >>>> rotating >>>> the byte by 3 so that the first bit is now the least significant >>>> DSCP >>>> bit So that compression does not allow odd DSCPs but you'll notice >>>> that >>>> most DSCPs are even)... This is also compatible with the precedence >>>> model. See page 14 of attached doc for more. >>>> >>>> What do you think? >>>> >>>> Pascal >>>> >>>> >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> 6lowpan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowpan >> _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Oct 7 14:15:05 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A613E3A67B3; Tue, 7 Oct 2008 14:15:05 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 166733A67B3 for <6lowpan@core3.amsl.com>; Tue, 7 Oct 2008 14:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-QsBsJaqplN for <6lowpan@core3.amsl.com>; Tue, 7 Oct 2008 14:15:03 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id DFAD33A6768 for <6lowpan@ietf.org>; Tue, 7 Oct 2008 14:15:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 5B4E8AF916; Tue, 7 Oct 2008 14:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neL1a8qVtxtR; Tue, 7 Oct 2008 14:14:36 -0700 (PDT) Received: from [192.168.7.75] (69-12-164-137.sfo.archrock.com [69.12.164.137]) by mail.sf.archrock.com (Postfix) with ESMTP id 2A05CAF901; Tue, 7 Oct 2008 14:14:36 -0700 (PDT) Message-Id: <69E99DD9-C2DE-4F17-93D3-BEF50F9C4515@archrock.com> From: Jonathan Hui To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC06576F56@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 7 Oct 2008 14:14:34 -0700 References: <7892795E1A87F04CADFCCF41FADD00FC06576D2D@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC06576F0F@xmb-ams-337.emea.cisco.com> <4E2F6997-DE19-493A-BBF9-2B2230A59187@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC06576F56@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Separating T and F X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Just to make sure I understand you, let me throw out an example: A - { IP network } - B 1) When both A and B are directly attached to the same IP link and communicate via link-local, they use CTX=00. 2) When both A and B belong to the same LoWPAN and communicate using the default global prefix for both source and destination addresses, the use CTX=01. 3) When both A and B belong to the same LoWPAN and communicate using the alternate global prefix for both source and destination addresses, they use CTX=10. 4) When A is a LoWPAN node and B is outside the LoWPAN, they use CTX=11. The values of CTX are as you proposed in the previous email. Do you agree with these examples? Also, would you like to help out with the draft in fleshing out the separation of T/F as well? -- Jonathan Hui On Oct 7, 2008, at 1:53 PM, Pascal Thubert (pthubert) wrote: > Well, that's why I discussed a default and a backup context. If > there is > a normal (default) context then both ends should be using it. If > there's > renumbering going on, both ends should be able to switch to the > backup. > > In that vision of things, source should match destination context so > one > bit is enough for both, you see? > > OTOH, if you need richness, then use 11 and you get 16 bits for source > and 16 bits for destination context. Though even so, IMHO, source and > destination contexts should be the same most times. > > Pascal > >> -----Original Message----- >> From: Jonathan Hui [mailto:jhui@archrock.com] >> Sent: mardi 7 octobre 2008 20:34 >> To: Pascal Thubert (pthubert) >> Cc: 6lowpan@ietf.org >> Subject: Re: [6lowpan] Separating T and F >> >> >> Hi Pascal: >> >> The challenge is that it would be nice to specify the context for the >> source and destination addresses individually. For example, I have >> two >> contexts: 1 for the PAN and 1 for the common peer/subnet that all >> nodes communicate with outside the PAN. Most of the time the encoding >> will use both contexts simultaneously. I could grab yet another bit >> from the dispatch, expand CTX to 3 bits then there's more than enough >> to do what you suggest. >> >> What do you/others think? >> >> -- >> Jonathan Hui >> >> >> >> On Oct 7, 2008, at 10:57 AM, Pascal Thubert (pthubert) wrote: >> >>> Jonathan: >>> >>> Let me propose a small delta for the context: >>> >>> >>> - 00: Link-Local >>> - 01: UL/Global (default context) >>> - 10: UL/Global (backup context) >>> - 11: UL/Global (16 contexts, a byte after the HC contains the >>> contexts for source and destination) >>> >>> This way we can have the 2 contexts without the burden of the >>> additional >>> byte, what do you think? >>> >>> Pascal >>> >>>> -----Original Message----- >>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>> Sent: mardi 7 octobre 2008 18:50 >>>> To: Pascal Thubert (pthubert) >>>> Cc: 6lowpan@ietf.org >>>> Subject: Re: [6lowpan] Separating T and F >>>> >>>> >>>> Hi Pascal: >>>> >>>> Overall, I like the idea of separating T from F in the compression >>>> format. That is why I had separate bits for them in hc-01. >>>> Unfortunately, it meant adding a byte to the encoding. Here's one >>>> idea >>>> to extend the idea while keeping the encoding at 1 byte: what if we >>>> steal a bit from the dispatch value? The argument is that this HC >>>> should be used very often, so we can afford to take some of the >>>> dispatch space (similar to how Mesh Addressing and Fragmentation >>>> got 2- >>>> bit forms of the header identifier). >>>> >>>> So here's one idea: >>>> >>>> Base Encoding >>>> >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >>>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>>> | 0 | 1 | 0 | 0 | 1 | CTX | TF |NH | HLIM | SAM | DAM | >>>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>>> >>>> - Dispatch: 8-15 >>>> - CTX: Context >>>> - 00: Link-Local >>>> - 01: Global (1 context) >>>> - 10: Global (16 contexts) >>>> - 11: Reserved >>>> - TF: Traffic Class, Flow Label >>>> - 00: 4-bit Pad + Traffic Class + Flow Label (4 bytes) >>>> - 01: ECN + 2-bit Pad + Flow Label (3 bytes) >>>> - 10: Traffic Class (1 byte) >>>> - 11: No Traffic Class and Flow Label >>>> - NH: Next Header compression >>>> - HLIM: Hop Limit >>>> - 00: uncompressed >>>> - 01: 1 >>>> - 10: 64 >>>> - 11: 255 >>>> - SAM: Source Address Mode - prefix is link-local, when compressed >>>> - 00: 128 bits >>>> - 01: 64 bits >>>> - 10: 16 bits >>>> - 11: 0 bits >>>> - DAM: Destination Address Mode - prefix is link-local, when >>>> compressed >>>> - 00: 128 bits >>>> - 01: 64 bits >>>> - 10: 16 bits >>>> - 11: 0 bits >>>> >>>> CTX is just to say what contexts we are using for compression - >>>> this >>>> is similar to using different dispatch values in the original >>>> proposal, except that we explicitly allocate the bits here. TF is > now >>>> expanded to support 3 different encodings of Traffic Class and Flow >>>> Label. I think it simplifies the encoding (3 encodings vs. 5) and >>>> carries the full Traffic Class unmodified when uncompressed. >>>> >>>> Does that satisfy your needs? >>>> >>>> -- >>>> Jonathan Hui >>>> >>>> >>>> >>>> On Oct 7, 2008, at 6:29 AM, Pascal Thubert (pthubert) wrote: >>>> >>>>> Hi Jonathan: >>>>> >>>>> It troubles me though that we cannot isolate the T from the VF >>>>> because I >>>>> can see the need to report congestion and to apply diffserv in > route >>>>> over. >>>>> >>>>> To give you examples, ISA cares (sometimes) about the flow label > but >>>>> not >>>>> the ToS bits because being mesh under this is all carried in MAC >>>>> extensions. And the ISA flow label needs only 2 bytes. And in many >>>>> route >>>>> over case, I expect the reverse, caring about the ToS bits but not >>> the >>>>> Flow Label. >>>>> >>>>> Proposal: The VTF bit becomes "another HC byte for VTF", if the >>>>> bit >>> is >>>>> reset VTF fields are all compressed, if set then how to compress > VTF >>>>> is >>>>> in the next byte. Then we'd have control bits to say how many >>>>> bytes >>> to >>>>> TF follow and what's in there >>>>> >>>>> Combinations we need to support: >>>>> >>>>> No compression: Need 4 bytes. Control is 1111 and then 24 bits F > and >>>>> then T >>>>> >>>>> Compressing T only: Need 3 bytes. Control is 1110 and then 24 bits > F >>>>> >>>>> Precedence + 2 bytes Flow: Need 3 bytes. Control is 110 and then 2 >>> bit >>>>> ECN, >>>>> 3 bits precedence and 16 bits >>>>> rightmost F >>>>> >>>>> Compressing DSCP : Need 3 bytes. Control is 10 and and then 24 > bits >>>>> F. >>>>> >>>>> Compress F: Need one byte. Control is 0 then 2 bit ECN and the >>>>> next 5 >>>>> bits are T striped from the rightmost bit. This is obtained by >>>>> rotating >>>>> the byte by 3 so that the first bit is now the least significant >>>>> DSCP >>>>> bit So that compression does not allow odd DSCPs but you'll notice >>>>> that >>>>> most DSCPs are even)... This is also compatible with the >>>>> precedence >>>>> model. See page 14 of attached doc for more. >>>>> >>>>> What do you think? >>>>> >>>>> Pascal >>>>> >>>>> >>>>> _______________________________________________ >>>>> 6lowpan mailing list >>>>> 6lowpan@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>> > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Oct 7 14:19:04 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 443443A67B3; Tue, 7 Oct 2008 14:19:04 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A06803A67B3 for <6lowpan@core3.amsl.com>; Tue, 7 Oct 2008 14:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCb-ZFV+QgWU for <6lowpan@core3.amsl.com>; Tue, 7 Oct 2008 14:19:01 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id AE0953A6768 for <6lowpan@ietf.org>; Tue, 7 Oct 2008 14:19:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,375,1220227200"; d="scan'208";a="21911337" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 07 Oct 2008 21:18:20 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m97LIKFY024582; Tue, 7 Oct 2008 23:18:20 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m97LIKnW018835; Tue, 7 Oct 2008 21:18:20 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Oct 2008 23:18:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Oct 2008 23:18:08 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC06576F5F@xmb-ams-337.emea.cisco.com> In-Reply-To: <69E99DD9-C2DE-4F17-93D3-BEF50F9C4515@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Separating T and F Thread-Index: AckowbYe0BJsFannSF6lvMWOtTgwsAAACHpQ References: <7892795E1A87F04CADFCCF41FADD00FC06576D2D@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC06576F0F@xmb-ams-337.emea.cisco.com> <4E2F6997-DE19-493A-BBF9-2B2230A59187@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC06576F56@xmb-ams-337.emea.cisco.com> <69E99DD9-C2DE-4F17-93D3-BEF50F9C4515@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 07 Oct 2008 21:18:19.0813 (UTC) FILETIME=[38C76D50:01C928C2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8078; t=1223414300; x=1224278300; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20Separating=20T=20and=20F |Sender:=20; bh=gNeL2z/xHjJ9dohDX0GrzGDLjZ4n/pVeVgGLCYF2NSs=; b=b/RnT3dw0QLcFIJpUWx5coMAGazZDqgiHkLKXVntYhaohPphgTsrNNBqpB 6515255BCskrpXrjkPxFYe34dohIZH1TXSmPgi7nzSCVC4nobUM/9eB21y6k HR7mWWrTzT; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Separating T and F X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Jonathan Please see inline >Just to make sure I understand you, let me throw out an example: > >A - { IP network } - B > >1) When both A and B are directly attached to the same IP link and >communicate via link-local, they use CTX=00. >2) When both A and B belong to the same LoWPAN and communicate using >the default global prefix for both source and destination addresses, >the use CTX=01. >3) When both A and B belong to the same LoWPAN and communicate using >the alternate global prefix for both source and destination addresses, >they use CTX=10. >4) When A is a LoWPAN node and B is outside the LoWPAN, they use CTX=11. > >The values of CTX are as you proposed in the previous email. Do you >agree with these examples? [Pascal] That's right. Reasoning is that the backup is used, like, to transition during a renumbering phase while the default context is going unavailable. So there's no point for either side of using it. > >Also, would you like to help out with the draft in fleshing out the >separation of T/F as well? > [Pascal] Sure, no problem. I'll be glad to help out here. Pascal >-- >Jonathan Hui > > > >On Oct 7, 2008, at 1:53 PM, Pascal Thubert (pthubert) wrote: > >> Well, that's why I discussed a default and a backup context. If >> there is >> a normal (default) context then both ends should be using it. If >> there's >> renumbering going on, both ends should be able to switch to the >> backup. >> >> In that vision of things, source should match destination context so >> one >> bit is enough for both, you see? >> >> OTOH, if you need richness, then use 11 and you get 16 bits for source >> and 16 bits for destination context. Though even so, IMHO, source and >> destination contexts should be the same most times. >> >> Pascal >> >>> -----Original Message----- >>> From: Jonathan Hui [mailto:jhui@archrock.com] >>> Sent: mardi 7 octobre 2008 20:34 >>> To: Pascal Thubert (pthubert) >>> Cc: 6lowpan@ietf.org >>> Subject: Re: [6lowpan] Separating T and F >>> >>> >>> Hi Pascal: >>> >>> The challenge is that it would be nice to specify the context for the >>> source and destination addresses individually. For example, I have >>> two >>> contexts: 1 for the PAN and 1 for the common peer/subnet that all >>> nodes communicate with outside the PAN. Most of the time the encoding >>> will use both contexts simultaneously. I could grab yet another bit >>> from the dispatch, expand CTX to 3 bits then there's more than enough >>> to do what you suggest. >>> >>> What do you/others think? >>> >>> -- >>> Jonathan Hui >>> >>> >>> >>> On Oct 7, 2008, at 10:57 AM, Pascal Thubert (pthubert) wrote: >>> >>>> Jonathan: >>>> >>>> Let me propose a small delta for the context: >>>> >>>> >>>> - 00: Link-Local >>>> - 01: UL/Global (default context) >>>> - 10: UL/Global (backup context) >>>> - 11: UL/Global (16 contexts, a byte after the HC contains the >>>> contexts for source and destination) >>>> >>>> This way we can have the 2 contexts without the burden of the >>>> additional >>>> byte, what do you think? >>>> >>>> Pascal >>>> >>>>> -----Original Message----- >>>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>>> Sent: mardi 7 octobre 2008 18:50 >>>>> To: Pascal Thubert (pthubert) >>>>> Cc: 6lowpan@ietf.org >>>>> Subject: Re: [6lowpan] Separating T and F >>>>> >>>>> >>>>> Hi Pascal: >>>>> >>>>> Overall, I like the idea of separating T from F in the compression >>>>> format. That is why I had separate bits for them in hc-01. >>>>> Unfortunately, it meant adding a byte to the encoding. Here's one >>>>> idea >>>>> to extend the idea while keeping the encoding at 1 byte: what if we >>>>> steal a bit from the dispatch value? The argument is that this HC >>>>> should be used very often, so we can afford to take some of the >>>>> dispatch space (similar to how Mesh Addressing and Fragmentation >>>>> got 2- >>>>> bit forms of the header identifier). >>>>> >>>>> So here's one idea: >>>>> >>>>> Base Encoding >>>>> >>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >>>>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>>>> | 0 | 1 | 0 | 0 | 1 | CTX | TF |NH | HLIM | SAM | DAM | >>>>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>>>> >>>>> - Dispatch: 8-15 >>>>> - CTX: Context >>>>> - 00: Link-Local >>>>> - 01: Global (1 context) >>>>> - 10: Global (16 contexts) >>>>> - 11: Reserved >>>>> - TF: Traffic Class, Flow Label >>>>> - 00: 4-bit Pad + Traffic Class + Flow Label (4 bytes) >>>>> - 01: ECN + 2-bit Pad + Flow Label (3 bytes) >>>>> - 10: Traffic Class (1 byte) >>>>> - 11: No Traffic Class and Flow Label >>>>> - NH: Next Header compression >>>>> - HLIM: Hop Limit >>>>> - 00: uncompressed >>>>> - 01: 1 >>>>> - 10: 64 >>>>> - 11: 255 >>>>> - SAM: Source Address Mode - prefix is link-local, when compressed >>>>> - 00: 128 bits >>>>> - 01: 64 bits >>>>> - 10: 16 bits >>>>> - 11: 0 bits >>>>> - DAM: Destination Address Mode - prefix is link-local, when >>>>> compressed >>>>> - 00: 128 bits >>>>> - 01: 64 bits >>>>> - 10: 16 bits >>>>> - 11: 0 bits >>>>> >>>>> CTX is just to say what contexts we are using for compression - >>>>> this >>>>> is similar to using different dispatch values in the original >>>>> proposal, except that we explicitly allocate the bits here. TF is >> now >>>>> expanded to support 3 different encodings of Traffic Class and Flow >>>>> Label. I think it simplifies the encoding (3 encodings vs. 5) and >>>>> carries the full Traffic Class unmodified when uncompressed. >>>>> >>>>> Does that satisfy your needs? >>>>> >>>>> -- >>>>> Jonathan Hui >>>>> >>>>> >>>>> >>>>> On Oct 7, 2008, at 6:29 AM, Pascal Thubert (pthubert) wrote: >>>>> >>>>>> Hi Jonathan: >>>>>> >>>>>> It troubles me though that we cannot isolate the T from the VF >>>>>> because I >>>>>> can see the need to report congestion and to apply diffserv in >> route >>>>>> over. >>>>>> >>>>>> To give you examples, ISA cares (sometimes) about the flow label >> but >>>>>> not >>>>>> the ToS bits because being mesh under this is all carried in MAC >>>>>> extensions. And the ISA flow label needs only 2 bytes. And in many >>>>>> route >>>>>> over case, I expect the reverse, caring about the ToS bits but not >>>> the >>>>>> Flow Label. >>>>>> >>>>>> Proposal: The VTF bit becomes "another HC byte for VTF", if the >>>>>> bit >>>> is >>>>>> reset VTF fields are all compressed, if set then how to compress >> VTF >>>>>> is >>>>>> in the next byte. Then we'd have control bits to say how many >>>>>> bytes >>>> to >>>>>> TF follow and what's in there >>>>>> >>>>>> Combinations we need to support: >>>>>> >>>>>> No compression: Need 4 bytes. Control is 1111 and then 24 bits F >> and >>>>>> then T >>>>>> >>>>>> Compressing T only: Need 3 bytes. Control is 1110 and then 24 bits >> F >>>>>> >>>>>> Precedence + 2 bytes Flow: Need 3 bytes. Control is 110 and then 2 >>>> bit >>>>>> ECN, >>>>>> 3 bits precedence and 16 bits >>>>>> rightmost F >>>>>> >>>>>> Compressing DSCP : Need 3 bytes. Control is 10 and and then 24 >> bits >>>>>> F. >>>>>> >>>>>> Compress F: Need one byte. Control is 0 then 2 bit ECN and the >>>>>> next 5 >>>>>> bits are T striped from the rightmost bit. This is obtained by >>>>>> rotating >>>>>> the byte by 3 so that the first bit is now the least significant >>>>>> DSCP >>>>>> bit So that compression does not allow odd DSCPs but you'll notice >>>>>> that >>>>>> most DSCPs are even)... This is also compatible with the >>>>>> precedence >>>>>> model. See page 14 of attached doc for more. >>>>>> >>>>>> What do you think? >>>>>> >>>>>> Pascal >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 6lowpan mailing list >>>>>> 6lowpan@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>> >> _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Oct 8 02:24:05 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC5D83A682C; Wed, 8 Oct 2008 02:24:05 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 502D73A682C for <6lowpan@core3.amsl.com>; Wed, 8 Oct 2008 02:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=1.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zuCqeWOzzhT for <6lowpan@core3.amsl.com>; Wed, 8 Oct 2008 02:24:04 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 34F4E3A6774 for <6lowpan@ietf.org>; Wed, 8 Oct 2008 02:24:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,377,1220227200"; d="scan'208,217";a="21955849" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Oct 2008 09:22:43 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m989MhMw006980; Wed, 8 Oct 2008 11:22:43 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m989MhMR005307; Wed, 8 Oct 2008 09:22:43 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Oct 2008 11:22:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 8 Oct 2008 11:22:42 +0200 Message-ID: <38F26F36EAA981478A49D1F37F474A86020CFED2@xmb-ams-33d.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Hc-01 LOWPAN_UDP encoding Thread-Index: AckpJ2qByFhsN84rR2WdH7w8O5lOaA== From: "Julien Abeille (jabeille)" To: "Jonathan Hui" , <6lowpan@ietf.org> X-OriginalArrivalTime: 08 Oct 2008 09:22:43.0163 (UTC) FILETIME=[6AF452B0:01C92927] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2739; t=1223457763; x=1224321763; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20Hc-01=20LOWPAN_UDP=20encoding |Sender:=20; bh=FNdoeCgEAAbTJuHuU1ZfubbjVwfcnJ7WseMohzN9of8=; b=Ng6uzNNviPXisgCilpsMm77f9Et8hj38z0O1rMysGhCSAlktKIGkzmPdSy tikLbqMn3mHbxEwkBqiHAysW3YzweRgkksABx+XpBllHJrUABxXXFq1u6gae 8m7tx3VJRi; Authentication-Results: ams-dkim-1; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [6lowpan] Hc-01 LOWPAN_UDP encoding X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0078076482==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============0078076482== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C92927.6AE3473E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C92927.6AE3473E Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Jonathan, all, =20 one comment regarding hc-01 LOWPAN_UDP encoding for now source and destination ports compression are splitted. It means if only one of them is compressed, the UDP compressed fields will be 36 bits long (4bits port + 16 bits port + checksum). We lose byte alignment this way. =20 to avoid this, you could either not split the compression of ports, or when only one is compressed, pad to 3bytes (4 bits port + 16 bits port + 4bits padding) What do you think? =20 Cheers, Julien =20 =20 ------_=_NextPart_001_01C92927.6AE3473E Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi = Jonathan,=20 all,
 
one = comment=20 regarding hc-01 LOWPAN_UDP encoding
for = now source and=20 destination ports compression are splitted. It means if only one of them = is=20 compressed, the UDP compressed fields will be 36 bits long (4bits port + = 16 bits=20 port + checksum). We lose byte alignment this way.
 
to = avoid=20 this, you could either not split the compression of ports, or = when=20 only one is compressed, pad to 3bytes (4 bits port + 16 bits port + = 4bits=20 padding)
What = do you=20 think?
 
Cheers,
Julien
 
 
------_=_NextPart_001_01C92927.6AE3473E-- --===============0078076482== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan --===============0078076482==-- From 6lowpan-bounces@ietf.org Wed Oct 8 02:41:25 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EF003A6B9F; Wed, 8 Oct 2008 02:41:25 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 454013A6B9F for <6lowpan@core3.amsl.com>; Wed, 8 Oct 2008 02:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.023 X-Spam-Level: X-Spam-Status: No, score=-6.023 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGlP5MaQn+u7 for <6lowpan@core3.amsl.com>; Wed, 8 Oct 2008 02:41:23 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B4ED13A6B74 for <6lowpan@ietf.org>; Wed, 8 Oct 2008 02:41:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,377,1220227200"; d="scan'208,217";a="21958931" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 08 Oct 2008 09:41:04 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m989f4Tw011907; Wed, 8 Oct 2008 11:41:04 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m989f4va012945; Wed, 8 Oct 2008 09:41:04 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Oct 2008 11:41:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 8 Oct 2008 11:41:03 +0200 Message-ID: <38F26F36EAA981478A49D1F37F474A86020CFF03@xmb-ams-33d.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multicast address compression in hc01 Thread-Index: AckpKfqgMBR55kj2QSu9qqE5r8EktA== From: "Julien Abeille (jabeille)" To: "Jonathan Hui" , <6lowpan@ietf.org> X-OriginalArrivalTime: 08 Oct 2008 09:41:04.0027 (UTC) FILETIME=[FB1ED6B0:01C92929] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5181; t=1223458864; x=1224322864; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20Multicast=20address=20compression=20in=20hc01 |Sender:=20; bh=ncEpxH2rJx1vdIze/XHXnovCyi0iGS0jmnWh5HcbXn4=; b=ZxdpDEOWDrYxS1OKGZpmuhCtthVzZ5mA6WP7kyWAByRCRn4PGfwAKg7cYu WW/Jh3nGg9virusTuTKykLqK1vsM2xVq+e6h3zFcseaGkbrTlxe/dJjX2+qB TLk+X+NO/I; Authentication-Results: ams-dkim-2; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [6lowpan] Multicast address compression in hc01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0384054523==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============0384054523== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C92929.FB0A8043" This is a multi-part message in MIME format. ------_=_NextPart_001_01C92929.FB0A8043 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Jonathan, all, =20 a few comments/questions about multicast address compression in hc-01: - is there a need to respect the 16 bit address formats defined in RFC4944 when compressing addresses. I though these formats were defined for layer 2 16 bits addresses, while the compressed addresses in the ip header are rather independant. - with 9 bits group-id, we do not support sollicited node and a few "well known" addresses (though most significant are supoprted), should we work on a format with different length possible? Also the current group-id mapping is stateful. A stateless model would avoid the need to store many mappings, and seems feasible as most group-ids start with a large number of 0 bytes. =20 we could use one more bit for destination address mode: something like 000 128 001 unicast 64 010 unicast 16 011 unicast 0 100 multicast 32 (for e.g. sollicited node), one byte flags + scope, 3bytes =3D last 3 bytes 101 multicast 24 flags + scope + last 2 bytes 110 multicast 16 bits : flags + scope + last byte ... =20 this way we also incorporate flags. =20 the issue is that we need one more bit for this... =20 does it make sense? Best, Julien ------_=_NextPart_001_01C92929.FB0A8043 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi = Jonathan,=20 all,
 
a few=20 comments/questions about multicast address compression in=20 hc-01:
- is = there a need to=20 respect the 16 bit address formats defined in RFC4944 when compressing=20 addresses. I though these formats were defined for layer 2 16 bits=20 addresses, while the compressed addresses in the ip header are rather=20 independant.
- with = 9 bits=20 group-id, we do not support sollicited node and a few "well known" = addresses=20 (though most significant are supoprted), should we work on a format with = different length possible?
Also = the current=20 group-id mapping is stateful. A stateless model would avoid the need to = store=20 many mappings, and seems feasible as most group-ids start with a large = number of=20 0 bytes.
 
we = could use one=20 more bit for destination address mode: something = like
000 128
001 = unicast=20 64
010 = unicast=20 16
011 = unicast=20 0
100 = multicast 32=20 (for e.g. sollicited node), one byte flags + scope, 3bytes =3D last 3=20 bytes
101=20 multicast 24 flags + scope + last 2 bytes
110 = multicast 16=20 bits : flags + scope + last byte
...
 
this = way we also=20 incorporate flags.
 
the issue is=20 that we need one more bit for this...
 
does = it make=20 sense?
Best,
Julien
------_=_NextPart_001_01C92929.FB0A8043-- --===============0384054523== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan --===============0384054523==-- From 6lowpan-bounces@ietf.org Wed Oct 8 02:59:22 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA3D93A6B47; Wed, 8 Oct 2008 02:59:22 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 966383A6B47 for <6lowpan@core3.amsl.com>; Wed, 8 Oct 2008 02:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOtn+B3l5T0P for <6lowpan@core3.amsl.com>; Wed, 8 Oct 2008 02:59:20 -0700 (PDT) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.186]) by core3.amsl.com (Postfix) with ESMTP id 498293A69DB for <6lowpan@ietf.org>; Wed, 8 Oct 2008 02:59:18 -0700 (PDT) Received: by mu-out-0910.google.com with SMTP id w1so3152132mue.9 for <6lowpan@ietf.org>; Wed, 08 Oct 2008 02:59:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=roCFZK3mnMmKmVzJYCM1ZkF8Gao0hM8oHh1zYp0mOuI=; b=VYjagm7rqAywcNLLbrHcG08yJSQlKuaiQgJ5EjUILRrtB+BXEY+T0lI1+Hm9Yiuvzg 9PfUnkdZVQed4nTkvpH9h60dLtEqgV4ZkGyku1zC+O4a93f9vFluGUy0rRUQ7Q9IwB1C /weg29TQTbF7y7MIHxer3pa01vRu6gcm6JHfk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=KO+rKTxYythh8FOr2VQ0Sh0uFV7C6nDgXGyGFE1B9cTd4AaCyh1XVayaMu+D9lj1SX jIIBHGzyX74UcC+d+1fs8e1fF5OjRxUIMmYFX+uz8r1HMBGhb5oM8FYSB3rmZzhpPmOG mflDd5w7uqQZDvpMF1D7lk7D13hDd9hdEp+p4= Received: by 10.103.170.13 with SMTP id x13mr4309684muo.27.1223459962216; Wed, 08 Oct 2008 02:59:22 -0700 (PDT) Received: by 10.102.244.7 with HTTP; Wed, 8 Oct 2008 02:59:22 -0700 (PDT) Message-ID: <147a29c80810080259w5ef10936l2a3fed1f5fcd3538@mail.gmail.com> Date: Wed, 8 Oct 2008 11:59:22 +0200 From: "Laurent Toutain" To: "Jonathan Hui" In-Reply-To: <69E99DD9-C2DE-4F17-93D3-BEF50F9C4515@archrock.com> MIME-Version: 1.0 References: <7892795E1A87F04CADFCCF41FADD00FC06576D2D@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC06576F0F@xmb-ams-337.emea.cisco.com> <4E2F6997-DE19-493A-BBF9-2B2230A59187@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC06576F56@xmb-ams-337.emea.cisco.com> <69E99DD9-C2DE-4F17-93D3-BEF50F9C4515@archrock.com> X-Google-Sender-Auth: 7ff3f90a2fb500a1 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Separating T and F X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1334976638==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --===============1334976638== Content-Type: multipart/alternative; boundary="----=_Part_77355_11647936.1223459962198" ------=_Part_77355_11647936.1223459962198 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I'm quite lost with this new coding: On Tue, Oct 7, 2008 at 23:14, Jonathan Hui wrote: > > Just to make sure I understand you, let me throw out an example: > > A - { IP network } - B > > 1) When both A and B are directly attached to the same IP link and > communicate via link-local, they use CTX=00. > 2) When both A and B belong to the same LoWPAN and communicate using the > default global prefix for both source and destination addresses, the use > CTX=01. > 3) When both A and B belong to the same LoWPAN and communicate using the > alternate global prefix for both source and destination addresses, they use > CTX=10. where is stored the prefix value ? Laurent > > 4) When A is a LoWPAN node and B is outside the LoWPAN, they use CTX=11. > > The values of CTX are as you proposed in the previous email. Do you agree > with these examples? > > Also, would you like to help out with the draft in fleshing out the > separation of T/F as well? > > -- > Jonathan Hui > > > > > On Oct 7, 2008, at 1:53 PM, Pascal Thubert (pthubert) wrote: > > Well, that's why I discussed a default and a backup context. If there is >> a normal (default) context then both ends should be using it. If there's >> renumbering going on, both ends should be able to switch to the backup. >> >> In that vision of things, source should match destination context so one >> bit is enough for both, you see? >> >> OTOH, if you need richness, then use 11 and you get 16 bits for source >> and 16 bits for destination context. Though even so, IMHO, source and >> destination contexts should be the same most times. >> >> Pascal >> >> -----Original Message----- >>> From: Jonathan Hui [mailto:jhui@archrock.com] >>> Sent: mardi 7 octobre 2008 20:34 >>> To: Pascal Thubert (pthubert) >>> Cc: 6lowpan@ietf.org >>> Subject: Re: [6lowpan] Separating T and F >>> >>> >>> Hi Pascal: >>> >>> The challenge is that it would be nice to specify the context for the >>> source and destination addresses individually. For example, I have two >>> contexts: 1 for the PAN and 1 for the common peer/subnet that all >>> nodes communicate with outside the PAN. Most of the time the encoding >>> will use both contexts simultaneously. I could grab yet another bit >>> from the dispatch, expand CTX to 3 bits then there's more than enough >>> to do what you suggest. >>> >>> What do you/others think? >>> >>> -- >>> Jonathan Hui >>> >>> >>> >>> On Oct 7, 2008, at 10:57 AM, Pascal Thubert (pthubert) wrote: >>> >>> Jonathan: >>>> >>>> Let me propose a small delta for the context: >>>> >>>> >>>> - 00: Link-Local >>>> - 01: UL/Global (default context) >>>> - 10: UL/Global (backup context) >>>> - 11: UL/Global (16 contexts, a byte after the HC contains the >>>> contexts for source and destination) >>>> >>>> This way we can have the 2 contexts without the burden of the >>>> additional >>>> byte, what do you think? >>>> >>>> Pascal >>>> >>>> -----Original Message----- >>>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>>> Sent: mardi 7 octobre 2008 18:50 >>>>> To: Pascal Thubert (pthubert) >>>>> Cc: 6lowpan@ietf.org >>>>> Subject: Re: [6lowpan] Separating T and F >>>>> >>>>> >>>>> Hi Pascal: >>>>> >>>>> Overall, I like the idea of separating T from F in the compression >>>>> format. That is why I had separate bits for them in hc-01. >>>>> Unfortunately, it meant adding a byte to the encoding. Here's one >>>>> idea >>>>> to extend the idea while keeping the encoding at 1 byte: what if we >>>>> steal a bit from the dispatch value? The argument is that this HC >>>>> should be used very often, so we can afford to take some of the >>>>> dispatch space (similar to how Mesh Addressing and Fragmentation >>>>> got 2- >>>>> bit forms of the header identifier). >>>>> >>>>> So here's one idea: >>>>> >>>>> Base Encoding >>>>> >>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >>>>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>>>> | 0 | 1 | 0 | 0 | 1 | CTX | TF |NH | HLIM | SAM | DAM | >>>>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>>>> >>>>> - Dispatch: 8-15 >>>>> - CTX: Context >>>>> - 00: Link-Local >>>>> - 01: Global (1 context) >>>>> - 10: Global (16 contexts) >>>>> - 11: Reserved >>>>> - TF: Traffic Class, Flow Label >>>>> - 00: 4-bit Pad + Traffic Class + Flow Label (4 bytes) >>>>> - 01: ECN + 2-bit Pad + Flow Label (3 bytes) >>>>> - 10: Traffic Class (1 byte) >>>>> - 11: No Traffic Class and Flow Label >>>>> - NH: Next Header compression >>>>> - HLIM: Hop Limit >>>>> - 00: uncompressed >>>>> - 01: 1 >>>>> - 10: 64 >>>>> - 11: 255 >>>>> - SAM: Source Address Mode - prefix is link-local, when compressed >>>>> - 00: 128 bits >>>>> - 01: 64 bits >>>>> - 10: 16 bits >>>>> - 11: 0 bits >>>>> - DAM: Destination Address Mode - prefix is link-local, when >>>>> compressed >>>>> - 00: 128 bits >>>>> - 01: 64 bits >>>>> - 10: 16 bits >>>>> - 11: 0 bits >>>>> >>>>> CTX is just to say what contexts we are using for compression - this >>>>> is similar to using different dispatch values in the original >>>>> proposal, except that we explicitly allocate the bits here. TF is >>>>> >>>> now >> >>> expanded to support 3 different encodings of Traffic Class and Flow >>>>> Label. I think it simplifies the encoding (3 encodings vs. 5) and >>>>> carries the full Traffic Class unmodified when uncompressed. >>>>> >>>>> Does that satisfy your needs? >>>>> >>>>> -- >>>>> Jonathan Hui >>>>> >>>>> >>>>> >>>>> On Oct 7, 2008, at 6:29 AM, Pascal Thubert (pthubert) wrote: >>>>> >>>>> Hi Jonathan: >>>>>> >>>>>> It troubles me though that we cannot isolate the T from the VF >>>>>> because I >>>>>> can see the need to report congestion and to apply diffserv in >>>>>> >>>>> route >> >>> over. >>>>>> >>>>>> To give you examples, ISA cares (sometimes) about the flow label >>>>>> >>>>> but >> >>> not >>>>>> the ToS bits because being mesh under this is all carried in MAC >>>>>> extensions. And the ISA flow label needs only 2 bytes. And in many >>>>>> route >>>>>> over case, I expect the reverse, caring about the ToS bits but not >>>>>> >>>>> the >>>> >>>>> Flow Label. >>>>>> >>>>>> Proposal: The VTF bit becomes "another HC byte for VTF", if the bit >>>>>> >>>>> is >>>> >>>>> reset VTF fields are all compressed, if set then how to compress >>>>>> >>>>> VTF >> >>> is >>>>>> in the next byte. Then we'd have control bits to say how many bytes >>>>>> >>>>> to >>>> >>>>> TF follow and what's in there >>>>>> >>>>>> Combinations we need to support: >>>>>> >>>>>> No compression: Need 4 bytes. Control is 1111 and then 24 bits F >>>>>> >>>>> and >> >>> then T >>>>>> >>>>>> Compressing T only: Need 3 bytes. Control is 1110 and then 24 bits >>>>>> >>>>> F >> >>> >>>>>> Precedence + 2 bytes Flow: Need 3 bytes. Control is 110 and then 2 >>>>>> >>>>> bit >>>> >>>>> ECN, >>>>>> 3 bits precedence and 16 bits >>>>>> rightmost F >>>>>> >>>>>> Compressing DSCP : Need 3 bytes. Control is 10 and and then 24 >>>>>> >>>>> bits >> >>> F. >>>>>> >>>>>> Compress F: Need one byte. Control is 0 then 2 bit ECN and the >>>>>> next 5 >>>>>> bits are T striped from the rightmost bit. This is obtained by >>>>>> rotating >>>>>> the byte by 3 so that the first bit is now the least significant >>>>>> DSCP >>>>>> bit So that compression does not allow odd DSCPs but you'll notice >>>>>> that >>>>>> most DSCPs are even)... This is also compatible with the precedence >>>>>> model. See page 14 of attached doc for more. >>>>>> >>>>>> What do you think? >>>>>> >>>>>> Pascal >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 6lowpan mailing list >>>>>> 6lowpan@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>> >>>>> >>>> >> > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > ------=_Part_77355_11647936.1223459962198 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,

I'm quite lost with this new coding:

On Tue, Oct 7, 2008 at 23:14, Jonathan Hui <jhui@archrock.com> wrote:

Just to make sure I understand you, let me throw out an example:

A - { IP network } - B

1) When both A and B are directly attached to the same IP link and communicate via link-local, they use CTX=00.
2) When both A and B belong to the same LoWPAN and communicate using the default global prefix for both source and destination addresses, the use CTX=01.
3) When both A and B belong to the same LoWPAN and communicate using the alternate global prefix for both source and destination addresses, they use CTX=10.

where is stored the prefix value ?

Laurent
 

4) When A is a LoWPAN node and B is outside the LoWPAN, they use CTX=11.

The values of CTX are as you proposed in the previous email. Do you agree with these examples?

Also, would you like to help out with the draft in fleshing out the separation of T/F as well?

--
Jonathan Hui




On Oct 7, 2008, at 1:53 PM, Pascal Thubert (pthubert) wrote:

Well, that's why I discussed a default and a backup context. If there is
a normal (default) context then both ends should be using it. If there's
renumbering going on, both ends should be able to switch to the backup.

In that vision of things, source should match destination context so one
bit is enough for both, you see?

OTOH, if you need richness, then use 11 and you get 16 bits for source
and 16 bits for destination context. Though even so, IMHO, source and
destination contexts should be the same most times.

Pascal

-----Original Message-----
From: Jonathan Hui [mailto:jhui@archrock.com]
Sent: mardi 7 octobre 2008 20:34
To: Pascal Thubert (pthubert)
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] Separating T and F


Hi Pascal:

The challenge is that it would be nice to specify the context for the
source and destination addresses individually. For example, I have two
contexts: 1 for the PAN and 1 for the common peer/subnet that all
nodes communicate with outside the PAN. Most of the time the encoding
will use both contexts simultaneously. I could grab yet another bit
from the dispatch, expand CTX to 3 bits then there's more than enough
to do what you suggest.

What do you/others think?

--
Jonathan Hui



On Oct 7, 2008, at 10:57 AM, Pascal Thubert (pthubert) wrote:

Jonathan:

Let me propose a small delta for the context:


- 00: Link-Local
- 01: UL/Global (default context)
- 10: UL/Global (backup context)
- 11: UL/Global (16 contexts, a byte after the HC contains the
contexts for source and destination)

This way we can have the 2 contexts without the burden of the
additional
byte, what do you think?

Pascal

-----Original Message-----
From: Jonathan Hui [mailto:jhui@archrock.com]
Sent: mardi 7 octobre 2008 18:50
To: Pascal Thubert (pthubert)
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] Separating T and F


Hi Pascal:

Overall, I like the idea of separating T from F in the compression
format. That is why I had separate bits for them in hc-01.
Unfortunately, it meant adding a byte to the encoding. Here's one
idea
to extend the idea while keeping the encoding at 1 byte: what if we
steal a bit from the dispatch value? The argument is that this HC
should be used very often, so we can afford to take some of the
dispatch space (similar to how Mesh Addressing and Fragmentation
got 2-
bit forms of the header identifier).

So here's one idea:

Base Encoding

 0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 | 1 | 0 | 0 | 1 |  CTX  |  TF   |NH | HLIM  |  SAM  |  DAM  |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

- Dispatch: 8-15
- CTX: Context
- 00: Link-Local
- 01: Global (1 context)
- 10: Global (16 contexts)
- 11: Reserved
- TF: Traffic Class, Flow Label
- 00: 4-bit Pad + Traffic Class + Flow Label (4 bytes)
- 01: ECN + 2-bit Pad + Flow Label (3 bytes)
- 10: Traffic Class (1 byte)
- 11: No Traffic Class and Flow Label
- NH: Next Header compression
- HLIM: Hop Limit
- 00: uncompressed
- 01: 1
- 10: 64
- 11: 255
- SAM: Source Address Mode - prefix is link-local, when compressed
- 00: 128 bits
- 01: 64 bits
- 10: 16 bits
- 11: 0 bits
- DAM: Destination Address Mode - prefix is link-local, when
compressed
- 00: 128 bits
- 01: 64 bits
- 10: 16 bits
- 11: 0 bits

CTX is just to say what contexts we are using for compression - this
is similar to using different dispatch values in the original
proposal, except that we explicitly allocate the bits here. TF is
now
expanded to support 3 different encodings of Traffic Class and Flow
Label. I think it simplifies the encoding (3 encodings vs. 5) and
carries the full Traffic Class unmodified when uncompressed.

Does that satisfy your needs?

--
Jonathan Hui



On Oct 7, 2008, at 6:29 AM, Pascal Thubert (pthubert) wrote:

Hi Jonathan:

It troubles me though that we cannot isolate the T from the VF
because I
can see the need to report congestion and to apply diffserv in
route
over.

To give you examples, ISA cares (sometimes) about the flow label
but
not
the ToS bits because being mesh under this is all carried in MAC
extensions. And the ISA flow label needs only 2 bytes. And in many
route
over case, I expect the reverse, caring about the ToS bits but not
the
Flow Label.

Proposal: The VTF bit becomes "another HC byte for VTF", if the bit
is
reset VTF fields are all compressed, if set then how to compress
VTF
is
in the next byte. Then we'd have control bits to say how many bytes
to
TF follow and what's in there

Combinations we need to support:

No compression: Need 4 bytes. Control is 1111 and then 24 bits F
and
then T

Compressing T only: Need 3 bytes. Control is 1110 and then 24 bits
F

Precedence + 2 bytes Flow: Need 3 bytes. Control is 110 and then 2
bit
ECN,
                                    3 bits precedence and 16 bits
rightmost F

Compressing DSCP  : Need 3 bytes. Control is 10 and and then 24
bits
F.

Compress F: Need one byte. Control is 0 then 2 bit ECN and the
next 5
bits are T striped from the rightmost bit. This is obtained by
rotating
the byte by 3 so that the first bit is now the least significant
DSCP
bit So that compression does not allow odd DSCPs but you'll notice
that
most DSCPs are even)... This is also compatible with the precedence
model. See page 14 of attached doc for more.

What do you think?

Pascal


_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan



_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan


------=_Part_77355_11647936.1223459962198-- --===============1334976638== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan --===============1334976638==-- From 6lowpan-bounces@ietf.org Wed Oct 8 07:46:29 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E233728C147; Wed, 8 Oct 2008 07:46:29 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A92E03A6AF5 for <6lowpan@core3.amsl.com>; Wed, 8 Oct 2008 07:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsrZPehXRakv for <6lowpan@core3.amsl.com>; Wed, 8 Oct 2008 07:46:27 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id F0E353A6B30 for <6lowpan@ietf.org>; Wed, 8 Oct 2008 07:45:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 339C0AF96D; Wed, 8 Oct 2008 07:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvUoygib9vfk; Wed, 8 Oct 2008 07:45:18 -0700 (PDT) Received: from [192.168.7.78] (69-12-164-140.sfo.archrock.com [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id 4C6DDAF936; Wed, 8 Oct 2008 07:45:18 -0700 (PDT) Message-Id: <54EA105A-94EC-4D54-89FB-2BD34675AA88@archrock.com> From: Jonathan Hui To: Julien Abeille (jabeille) In-Reply-To: <38F26F36EAA981478A49D1F37F474A86020CFED2@xmb-ams-33d.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 8 Oct 2008 07:45:17 -0700 References: <38F26F36EAA981478A49D1F37F474A86020CFED2@xmb-ams-33d.emea.cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Hc-01 LOWPAN_UDP encoding X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Julien, Fixing UDP compression was definitely on the list of TODOs. So there are a few options: 1) Expand the compressed range to 256 ports (the encoding lengths for the ports are then 2, 3, or 4 bytes). 2) When compressing only one port, add a 4-bit pad as you suggest. However, I would rather add the 4-bit pad to be with the 4-bit compressed port and keep the 16-bit uncompressed port byte-aligned (the encoding options would be 1, 3, or 4 bytes). 3) A hybrid of the two: When only one port is compressed, the compressed form is 8 bits (don't waste the 4 bits on padding). But when both ports are compressed, both only 4 bits. 00 - Neither source nor dest are compressed 01 - Source port uncompressed, dest port 8 bits. 10 - Source port 8 bits, dest port uncompressed 11 - Source port 4 bits, dest port 4 bits. Basic question to ask the group is if compressing both source and dest ports to 4 bits simultaneously useful? -- Jonathan Hui On Oct 8, 2008, at 2:22 AM, Julien Abeille (jabeille) wrote: > Hi Jonathan, all, > > one comment regarding hc-01 LOWPAN_UDP encoding > for now source and destination ports compression are splitted. It > means if only one of them is compressed, the UDP compressed fields > will be 36 bits long (4bits port + 16 bits port + checksum). We lose > byte alignment this way. > > to avoid this, you could either not split the compression of ports, > or when only one is compressed, pad to 3bytes (4 bits port + 16 bits > port + 4bits padding) > What do you think? > > Cheers, > Julien > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Oct 8 08:05:05 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE6263A6BCC; Wed, 8 Oct 2008 08:05:05 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C38FE3A6847 for <6lowpan@core3.amsl.com>; Wed, 8 Oct 2008 08:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eO5k5XQuxAkQ for <6lowpan@core3.amsl.com>; Wed, 8 Oct 2008 08:05:00 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 8AF333A6B30 for <6lowpan@ietf.org>; Wed, 8 Oct 2008 08:05:00 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 10BC2AF936; Wed, 8 Oct 2008 08:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VO1BgGfEHme; Wed, 8 Oct 2008 08:05:25 -0700 (PDT) Received: from [192.168.7.78] (69-12-164-140.sfo.archrock.com [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id 84B2DAF86C; Wed, 8 Oct 2008 08:05:25 -0700 (PDT) Message-Id: From: Jonathan Hui To: Laurent Toutain In-Reply-To: <147a29c80810080259w5ef10936l2a3fed1f5fcd3538@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 8 Oct 2008 08:05:21 -0700 References: <7892795E1A87F04CADFCCF41FADD00FC06576D2D@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC06576F0F@xmb-ams-337.emea.cisco.com> <4E2F6997-DE19-493A-BBF9-2B2230A59187@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC06576F56@xmb-ams-337.emea.cisco.com> <69E99DD9-C2DE-4F17-93D3-BEF50F9C4515@archrock.com> <147a29c80810080259w5ef10936l2a3fed1f5fcd3538@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Separating T and F X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Laurent, HC elides the prefix by relying on shared context (state established with all nodes in the LoWPAN). Every node in the LoWPAN stores the shared context so that they can meaningfully communicate without having to carry the full prefix in every packet. -- Jonathan Hui On Oct 8, 2008, at 2:59 AM, Laurent Toutain wrote: > Hi, > > I'm quite lost with this new coding: > > On Tue, Oct 7, 2008 at 23:14, Jonathan Hui wrote: > > Just to make sure I understand you, let me throw out an example: > > A - { IP network } - B > > 1) When both A and B are directly attached to the same IP link and > communicate via link-local, they use CTX=00. > 2) When both A and B belong to the same LoWPAN and communicate using > the default global prefix for both source and destination addresses, > the use CTX=01. > 3) When both A and B belong to the same LoWPAN and communicate using > the alternate global prefix for both source and destination > addresses, they use CTX=10. > > where is stored the prefix value ? > > Laurent > > > 4) When A is a LoWPAN node and B is outside the LoWPAN, they use > CTX=11. > > The values of CTX are as you proposed in the previous email. Do you > agree with these examples? > > Also, would you like to help out with the draft in fleshing out the > separation of T/F as well? > > -- > Jonathan Hui > > > > > On Oct 7, 2008, at 1:53 PM, Pascal Thubert (pthubert) wrote: > > Well, that's why I discussed a default and a backup context. If > there is > a normal (default) context then both ends should be using it. If > there's > renumbering going on, both ends should be able to switch to the > backup. > > In that vision of things, source should match destination context so > one > bit is enough for both, you see? > > OTOH, if you need richness, then use 11 and you get 16 bits for source > and 16 bits for destination context. Though even so, IMHO, source and > destination contexts should be the same most times. > > Pascal > > -----Original Message----- > From: Jonathan Hui [mailto:jhui@archrock.com] > Sent: mardi 7 octobre 2008 20:34 > To: Pascal Thubert (pthubert) > Cc: 6lowpan@ietf.org > Subject: Re: [6lowpan] Separating T and F > > > Hi Pascal: > > The challenge is that it would be nice to specify the context for the > source and destination addresses individually. For example, I have two > contexts: 1 for the PAN and 1 for the common peer/subnet that all > nodes communicate with outside the PAN. Most of the time the encoding > will use both contexts simultaneously. I could grab yet another bit > from the dispatch, expand CTX to 3 bits then there's more than enough > to do what you suggest. > > What do you/others think? > > -- > Jonathan Hui > > > > On Oct 7, 2008, at 10:57 AM, Pascal Thubert (pthubert) wrote: > > Jonathan: > > Let me propose a small delta for the context: > > > - 00: Link-Local > - 01: UL/Global (default context) > - 10: UL/Global (backup context) > - 11: UL/Global (16 contexts, a byte after the HC contains the > contexts for source and destination) > > This way we can have the 2 contexts without the burden of the > additional > byte, what do you think? > > Pascal > > -----Original Message----- > From: Jonathan Hui [mailto:jhui@archrock.com] > Sent: mardi 7 octobre 2008 18:50 > To: Pascal Thubert (pthubert) > Cc: 6lowpan@ietf.org > Subject: Re: [6lowpan] Separating T and F > > > Hi Pascal: > > Overall, I like the idea of separating T from F in the compression > format. That is why I had separate bits for them in hc-01. > Unfortunately, it meant adding a byte to the encoding. Here's one > idea > to extend the idea while keeping the encoding at 1 byte: what if we > steal a bit from the dispatch value? The argument is that this HC > should be used very often, so we can afford to take some of the > dispatch space (similar to how Mesh Addressing and Fragmentation > got 2- > bit forms of the header identifier). > > So here's one idea: > > Base Encoding > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > | 0 | 1 | 0 | 0 | 1 | CTX | TF |NH | HLIM | SAM | DAM | > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > > - Dispatch: 8-15 > - CTX: Context > - 00: Link-Local > - 01: Global (1 context) > - 10: Global (16 contexts) > - 11: Reserved > - TF: Traffic Class, Flow Label > - 00: 4-bit Pad + Traffic Class + Flow Label (4 bytes) > - 01: ECN + 2-bit Pad + Flow Label (3 bytes) > - 10: Traffic Class (1 byte) > - 11: No Traffic Class and Flow Label > - NH: Next Header compression > - HLIM: Hop Limit > - 00: uncompressed > - 01: 1 > - 10: 64 > - 11: 255 > - SAM: Source Address Mode - prefix is link-local, when compressed > - 00: 128 bits > - 01: 64 bits > - 10: 16 bits > - 11: 0 bits > - DAM: Destination Address Mode - prefix is link-local, when > compressed > - 00: 128 bits > - 01: 64 bits > - 10: 16 bits > - 11: 0 bits > > CTX is just to say what contexts we are using for compression - this > is similar to using different dispatch values in the original > proposal, except that we explicitly allocate the bits here. TF is > now > expanded to support 3 different encodings of Traffic Class and Flow > Label. I think it simplifies the encoding (3 encodings vs. 5) and > carries the full Traffic Class unmodified when uncompressed. > > Does that satisfy your needs? > > -- > Jonathan Hui > > > > On Oct 7, 2008, at 6:29 AM, Pascal Thubert (pthubert) wrote: > > Hi Jonathan: > > It troubles me though that we cannot isolate the T from the VF > because I > can see the need to report congestion and to apply diffserv in > route > over. > > To give you examples, ISA cares (sometimes) about the flow label > but > not > the ToS bits because being mesh under this is all carried in MAC > extensions. And the ISA flow label needs only 2 bytes. And in many > route > over case, I expect the reverse, caring about the ToS bits but not > the > Flow Label. > > Proposal: The VTF bit becomes "another HC byte for VTF", if the bit > is > reset VTF fields are all compressed, if set then how to compress > VTF > is > in the next byte. Then we'd have control bits to say how many bytes > to > TF follow and what's in there > > Combinations we need to support: > > No compression: Need 4 bytes. Control is 1111 and then 24 bits F > and > then T > > Compressing T only: Need 3 bytes. Control is 1110 and then 24 bits > F > > Precedence + 2 bytes Flow: Need 3 bytes. Control is 110 and then 2 > bit > ECN, > 3 bits precedence and 16 bits > rightmost F > > Compressing DSCP : Need 3 bytes. Control is 10 and and then 24 > bits > F. > > Compress F: Need one byte. Control is 0 then 2 bit ECN and the > next 5 > bits are T striped from the rightmost bit. This is obtained by > rotating > the byte by 3 so that the first bit is now the least significant > DSCP > bit So that compression does not allow odd DSCPs but you'll notice > that > most DSCPs are even)... This is also compatible with the precedence > model. See page 14 of attached doc for more. > > What do you think? > > Pascal > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Oct 8 08:05:47 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AED43A691A; Wed, 8 Oct 2008 08:05:47 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 169C23A67F5 for <6lowpan@core3.amsl.com>; Wed, 8 Oct 2008 08:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjw+vy5UFoYk for <6lowpan@core3.amsl.com>; Wed, 8 Oct 2008 08:05:40 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 0095B3A6BEB for <6lowpan@ietf.org>; Wed, 8 Oct 2008 08:05:31 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id B1ED2AF973; Wed, 8 Oct 2008 08:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4sjye6wRNgj; Wed, 8 Oct 2008 08:05:48 -0700 (PDT) Received: from [192.168.7.78] (69-12-164-140.sfo.archrock.com [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id 6C68FAF936; Wed, 8 Oct 2008 08:05:48 -0700 (PDT) Message-Id: <59F5D5A7-956C-434D-ABFB-AFA945A51E67@archrock.com> From: Jonathan Hui To: Julien Abeille (jabeille) In-Reply-To: <38F26F36EAA981478A49D1F37F474A86020CFF03@xmb-ams-33d.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 8 Oct 2008 08:05:48 -0700 References: <38F26F36EAA981478A49D1F37F474A86020CFF03@xmb-ams-33d.emea.cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Multicast address compression in hc01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Julien, This mcast compression issue was brought up in the last WG meeting, but hasn't been addressed on the ML yet. So thanks for brining it up again. Adhering to the 16-bit format was my attempt to keep the format as simple as possible. I've been trying very hard to limit the number of encoding variations. I've also been trying to address concerns of keeping the base format compact. As you will see in my post to the "T and F" thread, I've reduced the encoding to dispatch + 1-byte encoding (1 byte less than the HC-01 draft). So adding 1 bit will require either adding a full byte to the encoding or stealing yet another bit from the dispatch. In all honesty, we might want to consider giving HC a very short header type (similar to mesh addressing and frag). I think there are unused bits with the frag header, and stealing one to indicate frag vs. mesh would give us 13 bits to play with vs. 11 bits that I had in my last post. However, this would require making a minor update to the frag header. A separate question is whether or not increasing the group ID beyond 8/9 bits is useful. As you noted, most of the significant group ids are trivially supported. The solicited node address is not used with the ND/DAD proposal that we are currently working on (multicast over a LoWPAN is not the most efficient). What do people think? -- Jonathan Hui On Oct 8, 2008, at 2:41 AM, Julien Abeille (jabeille) wrote: > Hi Jonathan, all, > > a few comments/questions about multicast address compression in hc-01: > - is there a need to respect the 16 bit address formats defined in > RFC4944 when compressing addresses. I though these formats were > defined for layer 2 16 bits addresses, while the compressed > addresses in the ip header are rather independant. > - with 9 bits group-id, we do not support sollicited node and a few > "well known" addresses (though most significant are supoprted), > should we work on a format with different length possible? > Also the current group-id mapping is stateful. A stateless model > would avoid the need to store many mappings, and seems feasible as > most group-ids start with a large number of 0 bytes. > > we could use one more bit for destination address mode: something like > 000 128 > 001 unicast 64 > 010 unicast 16 > 011 unicast 0 > 100 multicast 32 (for e.g. sollicited node), one byte flags + scope, > 3bytes = last 3 bytes > 101 multicast 24 flags + scope + last 2 bytes > 110 multicast 16 bits : flags + scope + last byte > ... > > this way we also incorporate flags. > > the issue is that we need one more bit for this... > > does it make sense? > Best, > Julien _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Oct 8 08:56:40 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E4883A67F5; Wed, 8 Oct 2008 08:56:40 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EF833A67F5 for <6lowpan@core3.amsl.com>; Wed, 8 Oct 2008 08:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.215 X-Spam-Level: X-Spam-Status: No, score=-6.215 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMjqkRxgZQNA for <6lowpan@core3.amsl.com>; Wed, 8 Oct 2008 08:56:38 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C5B853A6780 for <6lowpan@ietf.org>; Wed, 8 Oct 2008 08:56:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,379,1220227200"; d="scan'208";a="22014666" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Oct 2008 15:56:33 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m98FuX6P020616; Wed, 8 Oct 2008 17:56:33 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m98FuXKO004334; Wed, 8 Oct 2008 15:56:33 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Oct 2008 17:56:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 8 Oct 2008 17:56:32 +0200 Message-ID: <38F26F36EAA981478A49D1F37F474A86020D0200@xmb-ams-33d.emea.cisco.com> In-Reply-To: <54EA105A-94EC-4D54-89FB-2BD34675AA88@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Hc-01 LOWPAN_UDP encoding Thread-Index: AckpVIGKFziWoli4Tweh+rm98+v4fQACRw6Q References: <38F26F36EAA981478A49D1F37F474A86020CFED2@xmb-ams-33d.emea.cisco.com> <54EA105A-94EC-4D54-89FB-2BD34675AA88@archrock.com> From: "Julien Abeille (jabeille)" To: "Jonathan Hui" X-OriginalArrivalTime: 08 Oct 2008 15:56:33.0493 (UTC) FILETIME=[6FBA8850:01C9295E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2160; t=1223481393; x=1224345393; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20RE=3A=20Hc-01=20LOWPAN_UDP=20encoding |Sender:=20; bh=yGWy6s96w3DclgYcOeIrncyjYpNyDkJvC3YZl5+2zQA=; b=WOAJSgwSUP7PIwEGbnOY35oiK/pxl2If4bWurbQJ+mru97+ZJrZArDGsTn iwvGjHBlEU+ULSrL7Qdt8mlR/GIUlBDJVnUYvJg68svxlcXxTbOh9/I4xMoO 6X1k4bKdXK; Authentication-Results: ams-dkim-1; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Hc-01 LOWPAN_UDP encoding X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Jonathan, I am ok with 2 or 3. Regarding compression of both ports simultaneously, I do not know if it useful, but as we must support at least 3 scenarios (src only compressed, dst only, or none), we need two bits. Hence I would say we can reserve the 4th value for the case where both ports are compressed. Regards, Julien -----Original Message----- From: Jonathan Hui [mailto:jhui@archrock.com] Sent: mercredi 8 octobre 2008 16:45 To: Julien Abeille (jabeille) Cc: 6lowpan@ietf.org Subject: Re: Hc-01 LOWPAN_UDP encoding Hi Julien, Fixing UDP compression was definitely on the list of TODOs. So there are a few options: 1) Expand the compressed range to 256 ports (the encoding lengths for the ports are then 2, 3, or 4 bytes). 2) When compressing only one port, add a 4-bit pad as you suggest. However, I would rather add the 4-bit pad to be with the 4-bit compressed port and keep the 16-bit uncompressed port byte-aligned (the encoding options would be 1, 3, or 4 bytes). 3) A hybrid of the two: When only one port is compressed, the compressed form is 8 bits (don't waste the 4 bits on padding). But when both ports are compressed, both only 4 bits. 00 - Neither source nor dest are compressed 01 - Source port uncompressed, dest port 8 bits. 10 - Source port 8 bits, dest port uncompressed 11 - Source port 4 bits, dest port 4 bits. Basic question to ask the group is if compressing both source and dest ports to 4 bits simultaneously useful? -- Jonathan Hui On Oct 8, 2008, at 2:22 AM, Julien Abeille (jabeille) wrote: > Hi Jonathan, all, > > one comment regarding hc-01 LOWPAN_UDP encoding for now source and > destination ports compression are splitted. It means if only one of > them is compressed, the UDP compressed fields will be 36 bits long > (4bits port + 16 bits port + checksum). We lose byte alignment this > way. > > to avoid this, you could either not split the compression of ports, or > when only one is compressed, pad to 3bytes (4 bits port + 16 bits port > + 4bits padding) What do you think? > > Cheers, > Julien > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Oct 8 14:04:17 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7BAD28C170; Wed, 8 Oct 2008 14:04:17 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D2303A6BB5 for <6lowpan@core3.amsl.com>; Wed, 8 Oct 2008 14:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENqBUP-KdO0v for <6lowpan@core3.amsl.com>; Wed, 8 Oct 2008 14:04:16 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id E71643A6B92 for <6lowpan@ietf.org>; Wed, 8 Oct 2008 14:04:15 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so3935704rvf.49 for <6lowpan@ietf.org>; Wed, 08 Oct 2008 14:04:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=17EhwjLHtX0pHIMGmhazKLnb7yRALWSOUpFwoffJm7M=; b=qE6/5P371PL3WsYM9zwtx8Yhhw2DI82Z09nP79kDYmzT1zyLpCm29W49SRksW/HpJ0 Lki270GnATNdrRrwxQZDMAr/I/CQoE3A95auCOYuQIqYEtDD/IR8p73VJFlbLcGyhr6f A06fxgtfR+RwSVhS3YzGgtzIlhBAAvpdkB7/g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=F9DAwNRKv939VGlPrh0PPetuEhqsCkh568i+NeN3pYU9V7g6QLU9JyRvQFDpAgUZNe LRGoHqIESQulXFByEaRQpFbgkh8duVjyqVQm+BKdphZhE+EDF0ahv55GsANbAs7K9Jvi 5p6vcU3lcdlW7rwxGnQON9nPzKw2/ErZO4a3Y= Received: by 10.141.129.14 with SMTP id g14mr5530211rvn.50.1223499842799; Wed, 08 Oct 2008 14:04:02 -0700 (PDT) Received: by 10.140.193.1 with HTTP; Wed, 8 Oct 2008 14:04:02 -0700 (PDT) Message-ID: Date: Wed, 8 Oct 2008 14:04:02 -0700 From: "David Culler" To: 6lowpan@ietf.org MIME-Version: 1.0 Subject: [6lowpan] I-D of interest to this list - Zigbee Application Protocol over UDP/IP, including 6LoPWAN X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1497809879==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --===============1497809879== Content-Type: multipart/alternative; boundary="----=_Part_58606_9514743.1223499842780" ------=_Part_58606_9514743.1223499842780 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline http://tools.ietf.org/html/draft-tolle-cap-00 ------=_Part_58606_9514743.1223499842780 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------=_Part_58606_9514743.1223499842780-- --===============1497809879== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan --===============1497809879==-- From 6lowpan-bounces@ietf.org Wed Oct 8 16:30:51 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 482BA3A6BEC; Wed, 8 Oct 2008 16:30:51 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FC8F3A6BEC for <6lowpan@core3.amsl.com>; Wed, 8 Oct 2008 16:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXiTjYKRxueT for <6lowpan@core3.amsl.com>; Wed, 8 Oct 2008 16:30:48 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 4B42E3A6BE4 for <6lowpan@ietf.org>; Wed, 8 Oct 2008 16:30:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,381,1220227200"; d="scan'208";a="22032165" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Oct 2008 23:31:29 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m98NVTnW012006; Thu, 9 Oct 2008 01:31:29 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m98NVTmR025402; Wed, 8 Oct 2008 23:31:29 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Oct 2008 01:31:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 9 Oct 2008 01:31:21 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC06577440@xmb-ams-337.emea.cisco.com> In-Reply-To: <38F26F36EAA981478A49D1F37F474A86020D01F8@xmb-ams-33d.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: hc-01 Thread-Index: AckpXZk/lBapnJ/tRry1ROKZRsoesgAOK0KA References: <38F26F36EAA981478A49D1F37F474A86020D01F8@xmb-ams-33d.emea.cisco.com> From: "Pascal Thubert (pthubert)" To: "Julien Abeille (jabeille)" , "Jonathan Hui" X-OriginalArrivalTime: 08 Oct 2008 23:31:28.0886 (UTC) FILETIME=[FD0CF960:01C9299D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5989; t=1223508689; x=1224372689; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20hc-01 |Sender:=20; bh=D3/YO/KbpwGIT+DTzxb6GDUP4hdc2imcFaUGECe6dp0=; b=s/KO0W/G49goejO14kTdf26tV1Hwnxot2EyOgFzJCdQmOIq0iITmeK1Ahy KVItmnbo5MEJHeft19jltiQEFKINf3eAeeAJKEydZg704TS5E0OH8YlYY3EQ 47f4lbCHja; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] hc-01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Julien: I think you're right, we need to dig a little bit more. So starting from Jonathan's encoding, maybe we can refine was was CTX 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 0 | 1 | 0 | 0 | 1 | DDF | TF |NH | HLIM | SAM | DAM | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - Dispatch: 8-15 - DDF: Destination dependant fiels - 00: Destination is global (or ULA), no context byte after the HC field - 01: Destination is global (or ULA), one byte context byte after the HC = field - 10: Destination is Link local - 11: Destination is multicast scoped address - TF: Traffic Class, Flow Label - 00: 4-bit Pad + Traffic Class + Flow Label (4 bytes) - 01: ECN + 2-bit Pad + Flow Label (3 bytes) - 10: Traffic Class (1 byte) - 11: No Traffic Class and Flow Label - NH: Next Header compression - HLIM: Hop Limit - 00: uncompressed - 01: 1 - 10: 64 - 11: 255 When destination is link local: ------------------------------- prefix is FC80::/64 when compressed - SAM: Source Address Mode - prefix is link-local, when compressed - 00: 128 bits - 01: 64 bits - 10: 16 bits = - 11: 0 bits - DAM: Destination Address Mode - prefix is link-local, when compressed - 00: 128 bits - 01: 64 bits - 10: 16 bits - 11: 0 bits = When destination is multicast: ------------------------------- prefix is FF02::/64 when compressed - SAM: Source Address Mode - 00: 0 bits, unspecified address - 01: 64 bits, prefix is link local - 10: 16 bits, prefix is link local - 11: 0 bits, derived from the IID, prefix is link local - DAM: Destination Address Mode - prefix is link-local, when compressed - 00: 8 bits, prefix is compressed, suffix is 7 octets of zeroes, then t= his octet - 01: 24 bits, prefix is compressed, suffix is 4 octets of zeroes, then o= ne octet 0xFF then this octet - 10: 16 bits. 4 bits flags, 4 bits scope, 1 byte suffix. Prefix as defined in RFC 4291, suffix is 7 octets of zeroes, then this suff= ix octet - 11: 24 bits 4 bits flags, 4 bits scope, 2 bytes suffix = Prefix as defined in RFC 4291, suffix is 6 octets of zeroes, then those suf= fix octets = When destination is ULA or global: = ------------------------------- The prefix is found from the context table. = If there is no context octet after the HC field then this is the default pr= efix. - SAM: Source Address Mode - 00: 128 bits - 01: 64 bits - 10: 16 bits - 11: 0 bits - DAM: Destination Address Mode - 00: 128 bits - 01: 64 bits - 10: 16 bits - 11: 0 bits Notes: With this change, the 16 bits format of Link local and ULA and global reall= y means the last 16 bits ( apposed to 15 in http://tools.ietf.org/html/draf= t-ietf-6lowpan-hc-00 2.2. IPv6 Unicast Address Compression. = With this change, we have the most useful mcast cases covered: DAM of 00 compresses FF02::XX, so you get all routers on link, etc... DAM of 01 compresses FF02::FFXX:YYZZ, sollicited node mcast address DAM of 10 and 11 compress all permanently-assigned multicast addresses defi= ned today for all scopes What do you think? Pascal ________________________________________ From: Julien Abeille (jabeille) = Sent: mercredi 8 octobre 2008 17:51 To: Jonathan Hui Cc: Pascal Thubert (pthubert) Subject: hc-01 Hi Jonathan, =A0 I send unicast because my thought will not be clear, and to make a quick pr= esentation and bind it to "cisco sensor team". I did my master thesis in 2005 at Cisco in Sophia Antipolis. My project man= ager was Patrick Wetterwald (IPSO president) and I worked with Pascal on tr= ee discovery and bubbles protocols. I joined Cisco as employee in july last= year, and have been working on sensors with Patrick as project manager, Pa= scal and a few others as engineers. I met JP Vasseur a year ago and we have= frequent calls and meetings, as he recently moved 150km from switzerland w= here my office is. I work most closely with Mathilde Durvy=A0whom you met f= or IPSO interop calls. =A0 after discussion with Pascal about address compression, I try to clarify my= thoughts: - 64 last bits compression in unicast address compression is only feasible = if last 64 bits are based on IID (either 64 bit MAC address or PAN ID+0+16b= it address). I thought it would be nice to be able to compress as well addr= esses with bytes 8 to 13 =3D 0. (e.g. a::1) - could be nice as well to compress the IID only when the prefix is not com= pressable? - for multicast address compression, i thought stateless compression could = be nice. This works well with permanently assigned addresses (Pascal, the l= ink i promissed: http://www.iana.org/assignments/ipv6-multicast-addresses),= as many bytes are 0 after the two first ones - for multicast again, it would be nice to=A0be able to compress addresses = with more than 9-bit non 0 (a few permanently assigned ones apply there, li= ke all-dhcp-agents) - regarding the 16-bit compressed format, i would prefer not having one bit= or more in the compressed field with a special meaning (first bit 0 =3D un= icast, 3 first bits 101 =3D multicast), but keep all these bits in the enco= ding -=A0I was wondering if assuming flags are 0 cannot be an issue. = =A0 These are just thoughts, as i am not extremely clear on the important scena= rios where we want to compress (e.g. solicited node multicast compression m= ight not be needed as with ND optimizations, there will not be many NS), an= d am not clear either about multicast addresses except permanently assigned= ones. More preciely i do not know if we want to support unicast prefix bas= ed multicast addresses or rendez vous point addresses, and what they look l= ike. =A0 hope this helps in the discussion, regards, Julien =A0 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Oct 8 16:49:01 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F0F428C106; Wed, 8 Oct 2008 16:49:01 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 167E03A6C0A for <6lowpan@core3.amsl.com>; Wed, 8 Oct 2008 16:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqbIrnD6cP+V for <6lowpan@core3.amsl.com>; Wed, 8 Oct 2008 16:48:58 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id C7E683A6C01 for <6lowpan@ietf.org>; Wed, 8 Oct 2008 16:48:58 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 20123AF901; Wed, 8 Oct 2008 16:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aMf-m3zQrch; Wed, 8 Oct 2008 16:49:40 -0700 (PDT) Received: from [192.168.7.75] (69-12-164-137.sfo.archrock.com [69.12.164.137]) by mail.sf.archrock.com (Postfix) with ESMTP id BCFCBAF86C; Wed, 8 Oct 2008 16:49:39 -0700 (PDT) Message-Id: <179B90FC-33BF-4FF1-908C-9B539E6AE82A@archrock.com> From: Jonathan Hui To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC06577440@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 8 Oct 2008 16:49:38 -0700 References: <38F26F36EAA981478A49D1F37F474A86020D01F8@xmb-ams-33d.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC06577440@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] hc-01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Pascal, I think this looks great. It covers the cases we care about (unicast and multicast) without using any extra bits that my initial proposal. The small thing I would change is moving the "DDF" field to bits 10-11 (shifting TF and NH 2 bits to the left). Then TF would not span a byte boundary. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 0 | 1 | 0 | 0 | 1 | TF |NH | HLIM | DDF | SAM | DAM | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ -- Jonathan Hui On Oct 8, 2008, at 4:31 PM, Pascal Thubert (pthubert) wrote: > Hi Julien: > > I think you're right, we need to dig a little bit more. > > So starting from Jonathan's encoding, maybe we can refine was was CTX > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > | 0 | 1 | 0 | 0 | 1 | DDF | TF |NH | HLIM | SAM | DAM | > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > > - Dispatch: 8-15 > - DDF: Destination dependant fiels > - 00: Destination is global (or ULA), no context byte after the HC > field > - 01: Destination is global (or ULA), one byte context byte after > the HC field > - 10: Destination is Link local > - 11: Destination is multicast scoped address > > - TF: Traffic Class, Flow Label > - 00: 4-bit Pad + Traffic Class + Flow Label (4 bytes) > - 01: ECN + 2-bit Pad + Flow Label (3 bytes) > - 10: Traffic Class (1 byte) > - 11: No Traffic Class and Flow Label > > - NH: Next Header compression > > - HLIM: Hop Limit > - 00: uncompressed > - 01: 1 > - 10: 64 > - 11: 255 > > When destination is link local: > ------------------------------- > prefix is FC80::/64 when compressed > > - SAM: Source Address Mode - prefix is link-local, when compressed > - 00: 128 bits > - 01: 64 bits > - 10: 16 bits > - 11: 0 bits > - DAM: Destination Address Mode - prefix is link-local, when > compressed > - 00: 128 bits > - 01: 64 bits > - 10: 16 bits > - 11: 0 bits > > When destination is multicast: > ------------------------------- > prefix is FF02::/64 when compressed > > - SAM: Source Address Mode > - 00: 0 bits, unspecified address > - 01: 64 bits, prefix is link local > - 10: 16 bits, prefix is link local > - 11: 0 bits, derived from the IID, prefix is link local > - DAM: Destination Address Mode - prefix is link-local, when > compressed > - 00: 8 bits, prefix is compressed, suffix is 7 octets of zeroes, > then this octet > - 01: 24 bits, prefix is compressed, suffix is 4 octets of zeroes, > then one octet 0xFF then this octet > - 10: 16 bits. 4 bits flags, 4 bits scope, 1 byte suffix. > Prefix as defined in RFC 4291, suffix is 7 octets of zeroes, then > this suffix octet > - 11: 24 bits 4 bits flags, 4 bits scope, 2 bytes suffix > Prefix as defined in RFC 4291, suffix is 6 octets of zeroes, then > those suffix octets > > When destination is ULA or global: > ------------------------------- > The prefix is found from the context table. > If there is no context octet after the HC field then this is the > default prefix. > > - SAM: Source Address Mode > - 00: 128 bits > - 01: 64 bits > - 10: 16 bits > - 11: 0 bits > - DAM: Destination Address Mode > - 00: 128 bits > - 01: 64 bits > - 10: 16 bits > - 11: 0 bits > > Notes: > > With this change, the 16 bits format of Link local and ULA and > global really means the last 16 bits ( apposed to 15 in http://tools.ietf.org/html/draft-ietf-6lowpan-hc-00 > 2.2. IPv6 Unicast Address Compression. > > With this change, we have the most useful mcast cases covered: > DAM of 00 compresses FF02::XX, so you get all routers on link, etc... > DAM of 01 compresses FF02::FFXX:YYZZ, sollicited node mcast address > DAM of 10 and 11 compress all permanently-assigned multicast > addresses defined today for all scopes > > What do you think? > > Pascal > ________________________________________ > From: Julien Abeille (jabeille) > Sent: mercredi 8 octobre 2008 17:51 > To: Jonathan Hui > Cc: Pascal Thubert (pthubert) > Subject: hc-01 > > Hi Jonathan, > > I send unicast because my thought will not be clear, and to make a > quick presentation and bind it to "cisco sensor team". > I did my master thesis in 2005 at Cisco in Sophia Antipolis. My > project manager was Patrick Wetterwald (IPSO president) and I worked > with Pascal on tree discovery and bubbles protocols. I joined Cisco > as employee in july last year, and have been working on sensors with > Patrick as project manager, Pascal and a few others as engineers. I > met JP Vasseur a year ago and we have frequent calls and meetings, > as he recently moved 150km from switzerland where my office is. I > work most closely with Mathilde Durvy whom you met for IPSO interop > calls. > > after discussion with Pascal about address compression, I try to > clarify my thoughts: > - 64 last bits compression in unicast address compression is only > feasible if last 64 bits are based on IID (either 64 bit MAC address > or PAN ID+0+16bit address). I thought it would be nice to be able to > compress as well addresses with bytes 8 to 13 = 0. (e.g. a::1) > - could be nice as well to compress the IID only when the prefix is > not compressable? > - for multicast address compression, i thought stateless compression > could be nice. This works well with permanently assigned addresses > (Pascal, the link i promissed: http://www.iana.org/assignments/ipv6-multicast-addresses) > , as many bytes are 0 after the two first ones > - for multicast again, it would be nice to be able to compress > addresses with more than 9-bit non 0 (a few permanently assigned > ones apply there, like all-dhcp-agents) > - regarding the 16-bit compressed format, i would prefer not having > one bit or more in the compressed field with a special meaning > (first bit 0 = unicast, 3 first bits 101 = multicast), but keep all > these bits in the encoding > - I was wondering if assuming flags are 0 cannot be an issue. > > These are just thoughts, as i am not extremely clear on the > important scenarios where we want to compress (e.g. solicited node > multicast compression might not be needed as with ND optimizations, > there will not be many NS), and am not clear either about multicast > addresses except permanently assigned ones. More preciely i do not > know if we want to support unicast prefix based multicast addresses > or rendez vous point addresses, and what they look like. > > hope this helps in the discussion, > regards, > Julien > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Oct 8 19:20:31 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA8113A6C2C; Wed, 8 Oct 2008 19:20:31 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA5D53A6C1C for <6lowpan@core3.amsl.com>; Wed, 8 Oct 2008 19:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySA9IlqoaJrx for <6lowpan@core3.amsl.com>; Wed, 8 Oct 2008 19:20:30 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 070D73A6C16 for <6lowpan@ietf.org>; Wed, 8 Oct 2008 19:20:30 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 92A43AF92F for <6lowpan@ietf.org>; Wed, 8 Oct 2008 19:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUAy7fWjkEOs for <6lowpan@ietf.org>; Wed, 8 Oct 2008 19:20:53 -0700 (PDT) Received: from [192.168.7.75] (69-12-164-137.sfo.archrock.com [69.12.164.137]) by mail.sf.archrock.com (Postfix) with ESMTP id DC325AF81E for <6lowpan@ietf.org>; Wed, 8 Oct 2008 19:20:52 -0700 (PDT) Message-Id: From: Jonathan Hui To: 6lowpan <6lowpan@ietf.org> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 8 Oct 2008 19:20:51 -0700 References: <20081009021535.C8E823A6959@core3.amsl.com> X-Mailer: Apple Mail (2.929.2) Subject: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-hc-01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org http://tools.ietf.org/html/draft-ietf-6lowpan-hc This new version reflects the recent discussions on the list. The changes are: - HC back to 1 byte by default by stealing a few bits from the dispatch field. - Added better support for multicast address compression. - Fixed alignment for UDP port compression. - Better support for Traffic Class and Flow Label compression. - Pascal joined as an author. Happy reading! -- Jonathan Hui Begin forwarded message: > From: IETF I-D Submission Tool > Date: October 8, 2008 7:15:35 PM PDT > To: jhui@archrock.com > Cc: pthubert@cisco.com > Subject: New Version Notification for draft-ietf-6lowpan-hc-01 > > > A new version of I-D, draft-ietf-6lowpan-hc-01.txt has been > successfuly submitted by Jonathan Hui and posted to the IETF > repository. > > Filename: draft-ietf-6lowpan-hc > Revision: 01 > Title: Compression Format for IPv6 Datagrams in 6LoWPAN Networks > Creation_date: 2008-10-09 > WG ID: 6lowpan > Number_of_pages: 15 > > Abstract: > This document specifies an IPv6 header compression format for IPv6 > packet delivery in 6LoWPAN networks. The compression format relies > on shared context to allow compression of arbitrary prefixes. This > document specifies compression of multicast addresses and a framework > for compressing next headers. This framework specifies UDP > compression and is prepared for additional transports. > > > > The IETF Secretariat. > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Oct 9 05:45:57 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4E243A692B; Thu, 9 Oct 2008 05:45:57 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4B933A68C3 for <6lowpan@core3.amsl.com>; Thu, 9 Oct 2008 05:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.311 X-Spam-Level: X-Spam-Status: No, score=-6.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5twgiATkYPV0 for <6lowpan@core3.amsl.com>; Thu, 9 Oct 2008 05:45:54 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 596443A68F9 for <6lowpan@ietf.org>; Thu, 9 Oct 2008 05:45:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,382,1220227200"; d="scan'208";a="22096542" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 Oct 2008 12:45:36 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m99CjaMb006133; Thu, 9 Oct 2008 14:45:36 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m99Cjaa5005621; Thu, 9 Oct 2008 12:45:36 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Oct 2008 14:45:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 9 Oct 2008 14:45:29 +0200 Message-ID: <38F26F36EAA981478A49D1F37F474A86020D05FC@xmb-ams-33d.emea.cisco.com> In-Reply-To: <179B90FC-33BF-4FF1-908C-9B539E6AE82A@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: hc-01 Thread-Index: AckpoIywmdeEPdl6SZiMY2WljdNRlwAZoGrg References: <38F26F36EAA981478A49D1F37F474A86020D01F8@xmb-ams-33d.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC06577440@xmb-ams-337.emea.cisco.com> <179B90FC-33BF-4FF1-908C-9B539E6AE82A@archrock.com> From: "Julien Abeille (jabeille)" To: "Jonathan Hui" , "Pascal Thubert (pthubert)" X-OriginalArrivalTime: 09 Oct 2008 12:45:36.0507 (UTC) FILETIME=[ED3EF4B0:01C92A0C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9919; t=1223556336; x=1224420336; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20RE=3A=20hc-01 |Sender:=20; bh=yxLQupqLntDzY8SLxpSNQAj5oFsJpnSEUTt/2VYP+ko=; b=qacsErZDbYOEuHxQy6H7Eb06bk2q1KHVsUOy8o3vRRdKGeAeO6bAUM6mV0 YQ2t7aNGsTMc9hgUNZ7y7sujbMZxkT44pQrm37oukHn54dMy2x2KKXt7s6LX TScsLfd8ku; Authentication-Results: ams-dkim-1; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] hc-01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Pascal, Jonathan, For addresses I see an issue with a few scenarios: - dest multicast, source global non compressable (SAM does not define 128 bits format) - some dest multicast are not in either of the 4 DAM cases, e.g FF3E:0040:aaaa:a:a:a:1:1 (address based on prefix aaaa:a:a:a::/64, with 32 bit group id = 1:1) Pascal, can you clarify the DDF = 01 case I tried to make my ideas clear by listing all current multicast scenarios , based on http://www.iana.org/assignments/ipv6-multicast-addresses and RFC 3306 + 3956 (unicast prefix based multicast addresses) A 128, not compressed B FF02::XX 1 byte needed C FF0X::00XX:XXXX 4 bytes needed D FF0X::00XX:XXXX:XXXX 6 bytes needed E unicast prefix based address, not embedding rendez vous point: 5 bytes needed F unicast prefix based address, embedding rendez vous point: 6 bytes needed A covers unicast prefix based multicast addresses with prefix not in context B covers most useful link local cases (see IANA) e.g. LL all nodes, FF02::1 C covers longer well known cases (see IANA) e.g. all-dhcp-servers FF05::1:3 D covers solicited node and node information queries FF02::1:FFXX:XXXX and FF02::2:FFXX:XXXX E covers format defined in RFC3306, when the prefix used is in the default context. | 8 | 4 | 4 | 8 | 8 | 64 | 32 | +--------+----+----+--------+----+----------------+----------+ |11111111|flgs|scop|reserved|plen| network prefix | group ID | +--------+----+----+--------+----+----------------+----------+ Here flags are 0011 (e.g. not embedding rendez vous point, unicast prefix based, non permanently assigned) We only need to send flags, scope, group ID (5 bytes) F covers format defined in RFC3956, when the prefix used is in the default context. | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | +--------+----+----+----+----+----+----------------+----------+ |11111111|flgs|scop|rsvd|RIID|plen| network prefix | group ID | +--------+----+----+----+----+----+----------------+----------+ Here flags are 0111 (e.g. embedding rendez vous point, unicast prefix based, non permanently assigned) We only need flags, scope, reserved + RIID, group ID (6bytes) Questions: - do we want to support all this? - do we want to group some cases: we could group C and D, E and F, then we have 4 cases only - what do we do for dest multicast, source non compressable. - Do we keep unspecified support? - do we afford one more bit (this would be 7 bits for addresses) and use dispatch e.g. 1101xxxx? - do we keep src and dest encoding linked. For now we have 2 bits common to src and dest (DDF), plus SAM and DAM. This makes 16 cases for both src and dest, 32 in total. Cheers, Julien -----Original Message----- From: Jonathan Hui [mailto:jhui@archrock.com] Sent: jeudi 9 octobre 2008 01:50 To: Pascal Thubert (pthubert) Cc: Julien Abeille (jabeille); 6lowpan@ietf.org Subject: Re: hc-01 Hi Pascal, I think this looks great. It covers the cases we care about (unicast and multicast) without using any extra bits that my initial proposal. The small thing I would change is moving the "DDF" field to bits 10-11 (shifting TF and NH 2 bits to the left). Then TF would not span a byte boundary. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 0 | 1 | 0 | 0 | 1 | TF |NH | HLIM | DDF | SAM | DAM | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ -- Jonathan Hui On Oct 8, 2008, at 4:31 PM, Pascal Thubert (pthubert) wrote: > Hi Julien: > > I think you're right, we need to dig a little bit more. > > So starting from Jonathan's encoding, maybe we can refine was was CTX > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > | 0 | 1 | 0 | 0 | 1 | DDF | TF |NH | HLIM | SAM | DAM | > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > > - Dispatch: 8-15 > - DDF: Destination dependant fiels > - 00: Destination is global (or ULA), no context byte after the HC > field > - 01: Destination is global (or ULA), one byte context byte after the > HC field > - 10: Destination is Link local > - 11: Destination is multicast scoped address > > - TF: Traffic Class, Flow Label > - 00: 4-bit Pad + Traffic Class + Flow Label (4 bytes) > - 01: ECN + 2-bit Pad + Flow Label (3 bytes) > - 10: Traffic Class (1 byte) > - 11: No Traffic Class and Flow Label > > - NH: Next Header compression > > - HLIM: Hop Limit > - 00: uncompressed > - 01: 1 > - 10: 64 > - 11: 255 > > When destination is link local: > ------------------------------- > prefix is FC80::/64 when compressed > > - SAM: Source Address Mode - prefix is link-local, when compressed > - 00: 128 bits > - 01: 64 bits > - 10: 16 bits > - 11: 0 bits > - DAM: Destination Address Mode - prefix is link-local, when > compressed > - 00: 128 bits > - 01: 64 bits > - 10: 16 bits > - 11: 0 bits > > When destination is multicast: > ------------------------------- > prefix is FF02::/64 when compressed > > - SAM: Source Address Mode > - 00: 0 bits, unspecified address > - 01: 64 bits, prefix is link local > - 10: 16 bits, prefix is link local > - 11: 0 bits, derived from the IID, prefix is link local > - DAM: Destination Address Mode - prefix is link-local, when > compressed > - 00: 8 bits, prefix is compressed, suffix is 7 octets of zeroes, > then this octet > - 01: 24 bits, prefix is compressed, suffix is 4 octets of zeroes, > then one octet 0xFF then this octet > - 10: 16 bits. 4 bits flags, 4 bits scope, 1 byte suffix. > Prefix as defined in RFC 4291, suffix is 7 octets of zeroes, then this > suffix octet > - 11: 24 bits 4 bits flags, 4 bits scope, 2 bytes suffix Prefix as > defined in RFC 4291, suffix is 6 octets of zeroes, then those suffix > octets > > When destination is ULA or global: > ------------------------------- > The prefix is found from the context table. > If there is no context octet after the HC field then this is the > default prefix. > > - SAM: Source Address Mode > - 00: 128 bits > - 01: 64 bits > - 10: 16 bits > - 11: 0 bits > - DAM: Destination Address Mode > - 00: 128 bits > - 01: 64 bits > - 10: 16 bits > - 11: 0 bits > > Notes: > > With this change, the 16 bits format of Link local and ULA and global > really means the last 16 bits ( apposed to 15 in > http://tools.ietf.org/html/draft-ietf-6lowpan-hc-00 > 2.2. IPv6 Unicast Address Compression. > > With this change, we have the most useful mcast cases covered: > DAM of 00 compresses FF02::XX, so you get all routers on link, etc... > DAM of 01 compresses FF02::FFXX:YYZZ, sollicited node mcast address > DAM of 10 and 11 compress all permanently-assigned multicast addresses > defined today for all scopes > > What do you think? > > Pascal > ________________________________________ > From: Julien Abeille (jabeille) > Sent: mercredi 8 octobre 2008 17:51 > To: Jonathan Hui > Cc: Pascal Thubert (pthubert) > Subject: hc-01 > > Hi Jonathan, > > I send unicast because my thought will not be clear, and to make a > quick presentation and bind it to "cisco sensor team". > I did my master thesis in 2005 at Cisco in Sophia Antipolis. My > project manager was Patrick Wetterwald (IPSO president) and I worked > with Pascal on tree discovery and bubbles protocols. I joined Cisco as > employee in july last year, and have been working on sensors with > Patrick as project manager, Pascal and a few others as engineers. I > met JP Vasseur a year ago and we have frequent calls and meetings, as > he recently moved 150km from switzerland where my office is. I work > most closely with Mathilde Durvy whom you met for IPSO interop calls. > > after discussion with Pascal about address compression, I try to > clarify my thoughts: > - 64 last bits compression in unicast address compression is only > feasible if last 64 bits are based on IID (either 64 bit MAC address > or PAN ID+0+16bit address). I thought it would be nice to be able to > compress as well addresses with bytes 8 to 13 = 0. (e.g. a::1) > - could be nice as well to compress the IID only when the prefix is > not compressable? > - for multicast address compression, i thought stateless compression > could be nice. This works well with permanently assigned addresses > (Pascal, the link i promissed: > http://www.iana.org/assignments/ipv6-multicast-addresses) > , as many bytes are 0 after the two first ones > - for multicast again, it would be nice to be able to compress > addresses with more than 9-bit non 0 (a few permanently assigned ones > apply there, like all-dhcp-agents) > - regarding the 16-bit compressed format, i would prefer not having > one bit or more in the compressed field with a special meaning (first > bit 0 = unicast, 3 first bits 101 = multicast), but keep all these > bits in the encoding > - I was wondering if assuming flags are 0 cannot be an issue. > > These are just thoughts, as i am not extremely clear on the important > scenarios where we want to compress (e.g. solicited node multicast > compression might not be needed as with ND optimizations, there will > not be many NS), and am not clear either about multicast addresses > except permanently assigned ones. More preciely i do not know if we > want to support unicast prefix based multicast addresses or rendez > vous point addresses, and what they look like. > > hope this helps in the discussion, > regards, > Julien > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Oct 9 07:09:12 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51F633A6BA8; Thu, 9 Oct 2008 07:09:12 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC46B3A6AA4 for <6lowpan@core3.amsl.com>; Thu, 9 Oct 2008 07:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.368 X-Spam-Level: X-Spam-Status: No, score=-6.368 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Whf90KSTVH7k for <6lowpan@core3.amsl.com>; Thu, 9 Oct 2008 07:09:05 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id AEEF43A6AA2 for <6lowpan@ietf.org>; Thu, 9 Oct 2008 07:09:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,383,1220227200"; d="scan'208,217";a="22108399" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 Oct 2008 14:09:23 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m99E9NEW003204 for <6lowpan@ietf.org>; Thu, 9 Oct 2008 16:09:23 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m99E9NKL005438 for <6lowpan@ietf.org>; Thu, 9 Oct 2008 14:09:23 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Oct 2008 16:09:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 9 Oct 2008 16:09:22 +0200 Message-ID: <38F26F36EAA981478A49D1F37F474A86020D06DA@xmb-ams-33d.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: rfc4944, hc and dispatchs Thread-Index: AckqGKEwf3NXwEplQxG5ziuOynGZbQ== From: "Julien Abeille (jabeille)" To: <6lowpan@ietf.org> X-OriginalArrivalTime: 09 Oct 2008 14:09:23.0548 (UTC) FILETIME=[A19889C0:01C92A18] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9946; t=1223561363; x=1224425363; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20rfc4944,=20hc=20and=20dispatchs |Sender:=20; bh=FDGIE8nCBlal0TqYApbJf1FujNiicDLZqG6PReO888E=; b=JoyMZqEYDKt0562xR6wAVIAO6bFEHa7uZJLORkqV5hEHoy9WcjSO0RA+tf M7rK+sjNKQOXyektd5d4IIhuwkfORwkIrEECBqAmYEWjEE2zYuX3ckFk8bNv pkYDdNpXi3; Authentication-Results: ams-dkim-1; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [6lowpan] rfc4944, hc and dispatchs X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0003152673==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============0003152673== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C92A18.A18F2229" This is a multi-part message in MIME format. ------_=_NextPart_001_01C92A18.A18F2229 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi all, =20 questions about rfc4944 and the new header compression scheme: - does it officialy deprecate the old header compression scheme? - are there other things we discovered can be improved or deprecated in rfc4944? - regarding hc: after recent discussions, and as we want to keep one byte only for the new encoding, would it be ok to revise dispatch values? I would propose to take two more bits for address compression, hence we would need 13 bits =20 For now there are 148 dispatch values used, 108 free. I feel the 64 for "not a lowpan frame" could be replaced by 1, which would mean 85 values used, 171 free.=20 New HC with 13 bits would use 32 of them, leaving 139 reserved... =20 I would propose something like: 00000000 not a lowpan frame (1 value) 00000001 ipv6 (1 value) 00000010 escape - additional dispatch byte follows (1 value) 00000011 broadcast (1 value) 000001xx reserved (4 reserved) 00001xxx frag 1 (8 values) 00010xxx frag n (8 values)=20 00011xxx (8 reserved) 001xxxxx HC (32) 01xxxxxx mesh (64) 11xxxxxx (128 reserved) =20 Note that this way, the reserved blocks are easily usable, meaning that if you want 32 values, you can have them with the same first 3 bits, which is not feasible with the dispatchs values from 4944... =20 What do you think? Cheers, Julien =20 =20 ------_=_NextPart_001_01C92A18.A18F2229 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
questions about=20 rfc4944 and the new header compression scheme:
- does = it officialy=20 deprecate the old header compression scheme?
- are = there other=20 things we discovered can be improved or deprecated in=20 rfc4944?
- = regarding hc:=20 after recent discussions, and as we want to keep one byte only for the = new=20 encoding, would it be ok to revise dispatch values?
I = would propose to=20 take two more bits for address compression, hence we would need 13=20 bits
 
For = now there are=20 148 dispatch values used, 108 free. I feel the 64 for "not a lowpan = frame" could=20 be replaced by 1, which would mean 85 values used, 171 free.=20
New HC = with 13 bits=20 would use 32 of them, leaving 139 reserved...
 
I = would propose=20 something like:
00000000 not a=20 lowpan=20 frame           &n= bsp;           &nb= sp;     =20   (1 value)
00000001=20 ipv6           &nb= sp;           &nbs= p;            = ;            =    =20   (1 value)
00000010 escape -=20 additional dispatch byte follows (1 value)
00000011=20 broadcast          &nbs= p;            = ;            =          =20 (1 value)
000001xx=20 reserved           = ;            =             &= nbsp;           (4= =20 reserved)
00001xxx frag=20 1            =             &= nbsp;           &n= bsp;           &nb= sp; =20 (8 values)
00010xxx frag=20 n            =             &= nbsp;           &n= bsp;           &nb= sp; =20 (8 values)
00011xxx         &n= bsp;           &nb= sp;           &nbs= p;            = ;            =   (8=20 reserved)
001xxxxx HC        =             &= nbsp;           &n= bsp;           &nb= sp;         =20 (32)           &nb= sp;   =20
01xxxxxx=20 mesh           &nb= sp;           &nbs= p;            = ;            =  =20  (64)
11xxxxxx         &n= bsp;           &nb= sp;           &nbs= p;            = ;            =  =20 (128 reserved)
 
Note = that this way,=20 the reserved blocks are easily usable, meaning that if you want 32 = values, you=20 can have them with the same first 3 bits, which is not feasible with=20 the dispatchs values from 4944...
 
What = do you=20 think?
Cheers,
Julien
 
 
------_=_NextPart_001_01C92A18.A18F2229-- --===============0003152673== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan --===============0003152673==-- From 6lowpan-bounces@ietf.org Thu Oct 9 07:42:09 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 770B23A695D; Thu, 9 Oct 2008 07:42:09 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5D603A695D for <6lowpan@core3.amsl.com>; Thu, 9 Oct 2008 07:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lg7g1ONsn+Sk for <6lowpan@core3.amsl.com>; Thu, 9 Oct 2008 07:42:08 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id D37B23A68F9 for <6lowpan@ietf.org>; Thu, 9 Oct 2008 07:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m99EgeqX000544; Thu, 9 Oct 2008 16:42:43 +0200 (CEST) Message-Id: <105175C7-A788-4225-9E5A-845A07AA3621@tzi.org> From: Carsten Bormann To: "Julien Abeille (jabeille)" In-Reply-To: <38F26F36EAA981478A49D1F37F474A86020D06DA@xmb-ams-33d.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Thu, 9 Oct 2008 16:42:39 +0200 References: <38F26F36EAA981478A49D1F37F474A86020D06DA@xmb-ams-33d.emea.cisco.com> X-Mailer: Apple Mail (2.926) Cc: Carsten Bormann , 6lowpan@ietf.org Subject: Re: [6lowpan] rfc4944, hc and dispatchs X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org On Oct 09 2008, at 16:09, Julien Abeille (jabeille) wrote: > - does it officialy deprecate the old header compression scheme? My impression of the mailing list consensus is that this is what the WG wants to achieve. At the time this was discussed, I cautioned that it is premature to decide on replacing something existing with known flaws with something not yet quite cooked (and, hence, with unknown flaws). So I expect we'll ultimately decide this question at the time HC and the related specs come up for WGLC. Clearly, the stated intention of many WG members is to make this happen, as it would be wasteful to support two HC schemes in tiny implementations. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Oct 9 07:52:22 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 622923A6C85; Thu, 9 Oct 2008 07:52:22 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A84913A6C85 for <6lowpan@core3.amsl.com>; Thu, 9 Oct 2008 07:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7zSpGZTRKKf for <6lowpan@core3.amsl.com>; Thu, 9 Oct 2008 07:52:19 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 4F7F53A67A5 for <6lowpan@ietf.org>; Thu, 9 Oct 2008 07:52:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,383,1220227200"; d="scan'208";a="22115106" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 Oct 2008 14:52:50 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m99EqoP0019297; Thu, 9 Oct 2008 16:52:50 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m99EqoMg021817; Thu, 9 Oct 2008 14:52:50 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Oct 2008 16:52:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 9 Oct 2008 16:52:30 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC065C28BC@xmb-ams-337.emea.cisco.com> In-Reply-To: <38F26F36EAA981478A49D1F37F474A86020D05FC@xmb-ams-33d.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: hc-01 Thread-Index: AckpoIywmdeEPdl6SZiMY2WljdNRlwAZoGrgAATM2nA= References: <38F26F36EAA981478A49D1F37F474A86020D01F8@xmb-ams-33d.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC06577440@xmb-ams-337.emea.cisco.com> <179B90FC-33BF-4FF1-908C-9B539E6AE82A@archrock.com> <38F26F36EAA981478A49D1F37F474A86020D05FC@xmb-ams-33d.emea.cisco.com> From: "Pascal Thubert (pthubert)" To: "Julien Abeille (jabeille)" , "Jonathan Hui" X-OriginalArrivalTime: 09 Oct 2008 14:52:49.0557 (UTC) FILETIME=[B2E5F450:01C92A1E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12571; t=1223563970; x=1224427970; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20hc-01 |Sender:=20; bh=P1zn6YdBW3wbml8Ems+dMpXU8P962a85MLlb0qZTM9E=; b=frgUy6Y/bD2Z+d6YqWajrB+yWhrBUaHLEfOK3lxZAVihAr2Jj3+mjOyJIe Fby4KrZiIGtTSGzI8MBo9e576QX+FnLTany8GM2P9XbTTq4Ual2C9Bb5keHK zf+wc7hVmD; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] hc-01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Julien: We used 3 compression mechanisms for the addresses in this spec: - compress specific types of addresses that are commonly when a large part of the address is a constant. This is applies to link local and some multicast addresses. We can only go that far with that model because of the explosion of cases. So we covered only the most commonly used and did not attempt to be exhaustive and we applied that to Link Local and some multicast addresses - use a stateless mechanism when part of field can be inferred from another part (e.g. when the IP address is formed out of the EUI-64 or EUI-48 address) - use a stateful mechanism when none of the above applies or if preferred for a even better compression. And: we default to no compression when none of the above applies, using the global format. Motes do not have to implement all the compression mechanisms but they should be able to decompress everything. This is the part where we need to modify / refine the draft: - The text seems to imply that if the destination is multicast then DDF is 11. The compression mechanism does not really care about routing, whether an address is unicast, multicast or anycast. All it cares for multicast is if there is a sufficiently large part that is a well known constant and if that case is sufficiently used to deserve some specific code in a mote to compress it. - So, if the destination is multicast, the sender SHOULD attempt to apply DDF 01 or 11. If it has no context for the destination and none of the covered cases in 11 applies, then he will resort to use DDF 01, and in the worst case none of the addresses will be compressed. The text could thus be a bit more clear on the following rules: - If there is nothing more specific that fits, last resort is to compress an address as if it was global. So there's always a way. - if you do not want to compress, you do not have to. For instance, a mote that will never or almost never send a multicast packet does not have to support DDF of 11 in its compression algorithm. We are making a lot of efforts to propose a ND mechanism in 6LoWPAN that doesn't need multicast. - still a mote should be able to decompress everything specified here. But that seems a bit easier then compressing, is that right? Pascal >-----Original Message----- >From: Julien Abeille (jabeille) >Sent: jeudi 9 octobre 2008 14:45 >To: Jonathan Hui; Pascal Thubert (pthubert) >Cc: 6lowpan@ietf.org >Subject: RE: hc-01 > >Hi Pascal, Jonathan, > >For addresses I see an issue with a few scenarios: >- dest multicast, source global non compressable (SAM does not define 128 bits format) >- some dest multicast are not in either of the 4 DAM cases, e.g FF3E:0040:aaaa:a:a:a:1:1 (address >based on prefix aaaa:a:a:a::/64, with 32 bit group id = 1:1) > >Pascal, can you clarify the DDF = 01 case > >I tried to make my ideas clear by listing all current multicast scenarios , based on >http://www.iana.org/assignments/ipv6-multicast-addresses and RFC 3306 + 3956 (unicast prefix based >multicast addresses) > >A 128, not compressed >B FF02::XX 1 byte needed >C FF0X::00XX:XXXX 4 bytes needed >D FF0X::00XX:XXXX:XXXX 6 bytes needed >E unicast prefix based address, not embedding rendez vous point: 5 bytes needed >F unicast prefix based address, embedding rendez vous point: 6 bytes needed > >A covers unicast prefix based multicast addresses with prefix not in context >B covers most useful link local cases (see IANA) e.g. LL all nodes, FF02::1 >C covers longer well known cases (see IANA) e.g. all-dhcp-servers FF05::1:3 >D covers solicited node and node information queries FF02::1:FFXX:XXXX and FF02::2:FFXX:XXXX >E covers format defined in RFC3306, when the prefix used is in the default context. > >| 8 | 4 | 4 | 8 | 8 | 64 | 32 | >+--------+----+----+--------+----+----------------+----------+ >|11111111|flgs|scop|reserved|plen| network prefix | group ID | >+--------+----+----+--------+----+----------------+----------+ >Here flags are 0011 (e.g. not embedding rendez vous point, unicast prefix based, non permanently >assigned) >We only need to send flags, scope, group ID (5 bytes) > >F covers format defined in RFC3956, when the prefix used is in the default context. > >| 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | >+--------+----+----+----+----+----+----------------+----------+ >|11111111|flgs|scop|rsvd|RIID|plen| network prefix | group ID | >+--------+----+----+----+----+----+----------------+----------+ >Here flags are 0111 (e.g. embedding rendez vous point, unicast prefix based, non permanently >assigned) >We only need flags, scope, reserved + RIID, group ID (6bytes) > > >Questions: >- do we want to support all this? >- do we want to group some cases: we could group C and D, E and F, then we have 4 cases only >- what do we do for dest multicast, source non compressable. >- Do we keep unspecified support? >- do we afford one more bit (this would be 7 bits for addresses) and use dispatch e.g. 1101xxxx? >- do we keep src and dest encoding linked. For now we have 2 bits common to src and dest (DDF), plus >SAM and DAM. This makes 16 cases for both src and dest, 32 in total. > >Cheers, >Julien > > >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com] >Sent: jeudi 9 octobre 2008 01:50 >To: Pascal Thubert (pthubert) >Cc: Julien Abeille (jabeille); 6lowpan@ietf.org >Subject: Re: hc-01 > > >Hi Pascal, > >I think this looks great. It covers the cases we care about (unicast and multicast) without using any >extra bits that my initial proposal. >The small thing I would change is moving the "DDF" field to bits 10-11 (shifting TF and NH 2 bits to >the left). Then TF would not span a byte boundary. > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > | 0 | 1 | 0 | 0 | 1 | TF |NH | HLIM | DDF | SAM | DAM | > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > >-- >Jonathan Hui > > > >On Oct 8, 2008, at 4:31 PM, Pascal Thubert (pthubert) wrote: > >> Hi Julien: >> >> I think you're right, we need to dig a little bit more. >> >> So starting from Jonathan's encoding, maybe we can refine was was CTX >> >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >> | 0 | 1 | 0 | 0 | 1 | DDF | TF |NH | HLIM | SAM | DAM | >> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >> >> - Dispatch: 8-15 >> - DDF: Destination dependant fiels >> - 00: Destination is global (or ULA), no context byte after the HC >> field >> - 01: Destination is global (or ULA), one byte context byte after the >> HC field >> - 10: Destination is Link local >> - 11: Destination is multicast scoped address >> >> - TF: Traffic Class, Flow Label >> - 00: 4-bit Pad + Traffic Class + Flow Label (4 bytes) >> - 01: ECN + 2-bit Pad + Flow Label (3 bytes) >> - 10: Traffic Class (1 byte) >> - 11: No Traffic Class and Flow Label >> >> - NH: Next Header compression >> >> - HLIM: Hop Limit >> - 00: uncompressed >> - 01: 1 >> - 10: 64 >> - 11: 255 >> >> When destination is link local: >> ------------------------------- >> prefix is FC80::/64 when compressed >> >> - SAM: Source Address Mode - prefix is link-local, when compressed >> - 00: 128 bits >> - 01: 64 bits >> - 10: 16 bits >> - 11: 0 bits >> - DAM: Destination Address Mode - prefix is link-local, when >> compressed >> - 00: 128 bits >> - 01: 64 bits >> - 10: 16 bits >> - 11: 0 bits >> >> When destination is multicast: >> ------------------------------- >> prefix is FF02::/64 when compressed >> >> - SAM: Source Address Mode >> - 00: 0 bits, unspecified address >> - 01: 64 bits, prefix is link local >> - 10: 16 bits, prefix is link local >> - 11: 0 bits, derived from the IID, prefix is link local >> - DAM: Destination Address Mode - prefix is link-local, when >> compressed >> - 00: 8 bits, prefix is compressed, suffix is 7 octets of zeroes, >> then this octet >> - 01: 24 bits, prefix is compressed, suffix is 4 octets of zeroes, >> then one octet 0xFF then this octet >> - 10: 16 bits. 4 bits flags, 4 bits scope, 1 byte suffix. >> Prefix as defined in RFC 4291, suffix is 7 octets of zeroes, then this >> suffix octet >> - 11: 24 bits 4 bits flags, 4 bits scope, 2 bytes suffix Prefix as >> defined in RFC 4291, suffix is 6 octets of zeroes, then those suffix >> octets >> >> When destination is ULA or global: >> ------------------------------- >> The prefix is found from the context table. >> If there is no context octet after the HC field then this is the >> default prefix. >> >> - SAM: Source Address Mode >> - 00: 128 bits >> - 01: 64 bits >> - 10: 16 bits >> - 11: 0 bits >> - DAM: Destination Address Mode >> - 00: 128 bits >> - 01: 64 bits >> - 10: 16 bits >> - 11: 0 bits >> >> Notes: >> >> With this change, the 16 bits format of Link local and ULA and global >> really means the last 16 bits ( apposed to 15 in >> http://tools.ietf.org/html/draft-ietf-6lowpan-hc-00 >> 2.2. IPv6 Unicast Address Compression. >> >> With this change, we have the most useful mcast cases covered: >> DAM of 00 compresses FF02::XX, so you get all routers on link, etc... >> DAM of 01 compresses FF02::FFXX:YYZZ, sollicited node mcast address >> DAM of 10 and 11 compress all permanently-assigned multicast addresses >> defined today for all scopes >> >> What do you think? >> >> Pascal >> ________________________________________ >> From: Julien Abeille (jabeille) >> Sent: mercredi 8 octobre 2008 17:51 >> To: Jonathan Hui >> Cc: Pascal Thubert (pthubert) >> Subject: hc-01 >> >> Hi Jonathan, >> >> I send unicast because my thought will not be clear, and to make a >> quick presentation and bind it to "cisco sensor team". >> I did my master thesis in 2005 at Cisco in Sophia Antipolis. My >> project manager was Patrick Wetterwald (IPSO president) and I worked >> with Pascal on tree discovery and bubbles protocols. I joined Cisco as >> employee in july last year, and have been working on sensors with >> Patrick as project manager, Pascal and a few others as engineers. I >> met JP Vasseur a year ago and we have frequent calls and meetings, as >> he recently moved 150km from switzerland where my office is. I work >> most closely with Mathilde Durvy whom you met for IPSO interop calls. >> >> after discussion with Pascal about address compression, I try to >> clarify my thoughts: >> - 64 last bits compression in unicast address compression is only >> feasible if last 64 bits are based on IID (either 64 bit MAC address >> or PAN ID+0+16bit address). I thought it would be nice to be able to >> compress as well addresses with bytes 8 to 13 = 0. (e.g. a::1) >> - could be nice as well to compress the IID only when the prefix is >> not compressable? >> - for multicast address compression, i thought stateless compression >> could be nice. This works well with permanently assigned addresses >> (Pascal, the link i promissed: >> http://www.iana.org/assignments/ipv6-multicast-addresses) >> , as many bytes are 0 after the two first ones >> - for multicast again, it would be nice to be able to compress >> addresses with more than 9-bit non 0 (a few permanently assigned ones >> apply there, like all-dhcp-agents) >> - regarding the 16-bit compressed format, i would prefer not having >> one bit or more in the compressed field with a special meaning (first >> bit 0 = unicast, 3 first bits 101 = multicast), but keep all these >> bits in the encoding >> - I was wondering if assuming flags are 0 cannot be an issue. >> >> These are just thoughts, as i am not extremely clear on the important >> scenarios where we want to compress (e.g. solicited node multicast >> compression might not be needed as with ND optimizations, there will >> not be many NS), and am not clear either about multicast addresses >> except permanently assigned ones. More preciely i do not know if we >> want to support unicast prefix based multicast addresses or rendez >> vous point addresses, and what they look like. >> >> hope this helps in the discussion, >> regards, >> Julien >> _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Oct 9 11:44:37 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECC593A69B9; Thu, 9 Oct 2008 11:44:36 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 065C73A69B9 for <6lowpan@core3.amsl.com>; Thu, 9 Oct 2008 11:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXHs9ix1uq+Y for <6lowpan@core3.amsl.com>; Thu, 9 Oct 2008 11:44:33 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 761A73A68DC for <6lowpan@ietf.org>; Thu, 9 Oct 2008 11:44:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,384,1220227200"; d="scan'208";a="22133978" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 09 Oct 2008 17:41:25 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m99HfL36002858; Thu, 9 Oct 2008 19:41:21 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m99HfLS1014079; Thu, 9 Oct 2008 17:41:21 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Oct 2008 19:41:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 9 Oct 2008 19:41:15 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC065C29B2@xmb-ams-337.emea.cisco.com> In-Reply-To: <105175C7-A788-4225-9E5A-845A07AA3621@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] rfc4944, hc and dispatchs Thread-Index: AckqHW1LChKdlCKaRPuE9NOS1dcFGwAFeDtg References: <38F26F36EAA981478A49D1F37F474A86020D06DA@xmb-ams-33d.emea.cisco.com> <105175C7-A788-4225-9E5A-845A07AA3621@tzi.org> From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" , "Geoff Mulligan" X-OriginalArrivalTime: 09 Oct 2008 17:41:21.0292 (UTC) FILETIME=[3DF644C0:01C92A36] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2911; t=1223574081; x=1224438081; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20rfc4944,=20hc=20and=20dispa tchs |Sender:=20; bh=kKFybgCK+rl7wZNe12UbMXYJR0juk60Irc+zMNGL7Hw=; b=Vn9Nuc+7skYn0xeo1mB6Kb7JAYQVYxCyhqQgaexV61bEcrKo5GDjYmMkII N9HxlRoVLAD7muAaZtcdd1YSDBn5eYPB2PeauCmJPApoacauRrDdeM1dQ6lb OozgrEwMVo; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] rfc4944, hc and dispatchs X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Carsten: Some implementations and dependant standards would require a timeline for this. Leaving it up in the air does not help our users do their product planning? Considering the attention and the work on the new LOWPAN_IPHC, I expect that we'll be ready for WGLC after 2/3 more respins. That could be achieved by Minneapolis time if we can rally all interested parties to comment on the existing published spec. So could you chairs please: >>>>>>>>>> propose a time line to the WG along those lines <<<<<<<<<<<< >>>>>>>>>> raise WG attention on this work? <<<<<<<<<<<< Also by or at Minneapolis, my sensation is that we should not only discuss the terms of deprecating RFC 4944 HC but also consider the spec as a whole: - Mesh Header is a layer violation. I talked to implementers and their message is that they do not use it because it's never exactely what that specific radio needs; so they end up with their own mesh header anyway and will not duplicate things for the sake of comliance. Instead we might need a Routing header, pretty useful for source routing in route over. - Fragments are not recovered individually. We have enough experience to know where that leads should a 6LoWPAN network experience either high load or high BER. We have a draft on the works to deprecate that with recoverable fragments. - The Current HC WG doc covers all the compression cases in RFC 4944, bigger and badder. So what's left? My proposal is to start a 4944bis that would focus on the addressing architecture, would be the placeholder to control the dispatch type but would defer to the drafts/RFCs that actually detail the operation of each dispatch type. What do you think? Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann >Sent: jeudi 9 octobre 2008 16:43 >To: Julien Abeille (jabeille) >Cc: Carsten Bormann; 6lowpan@ietf.org >Subject: Re: [6lowpan] rfc4944, hc and dispatchs > >On Oct 09 2008, at 16:09, Julien Abeille (jabeille) wrote: > >> - does it officialy deprecate the old header compression scheme? > >My impression of the mailing list consensus is that this is what the >WG wants to achieve. >At the time this was discussed, I cautioned that it is premature to >decide on replacing something existing with known flaws with something >not yet quite cooked (and, hence, with unknown flaws). >So I expect we'll ultimately decide this question at the time HC and >the related specs come up for WGLC. >Clearly, the stated intention of many WG members is to make this >happen, as it would be wasteful to support two HC schemes in tiny >implementations. > >Gruesse, Carsten > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Oct 9 12:02:13 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EC6B28C19F; Thu, 9 Oct 2008 12:02:13 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B277628C0EF for <6lowpan@core3.amsl.com>; Thu, 9 Oct 2008 12:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkwrXWQ-+Q+C for <6lowpan@core3.amsl.com>; Thu, 9 Oct 2008 12:02:10 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id DF96428C1DE for <6lowpan@ietf.org>; Thu, 9 Oct 2008 12:00:32 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 7C2A0AF891; Thu, 9 Oct 2008 12:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0Bd7aG3CZA6; Thu, 9 Oct 2008 12:00:50 -0700 (PDT) Received: from [192.168.7.78] (69-12-164-140.sfo.archrock.com [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id 80608AF8AF; Thu, 9 Oct 2008 12:00:48 -0700 (PDT) Message-Id: <9DDB4F7F-D00C-4873-A28A-849B46FE67DF@archrock.com> From: Jonathan Hui To: Julien Abeille (jabeille) In-Reply-To: <38F26F36EAA981478A49D1F37F474A86020D05FC@xmb-ams-33d.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 9 Oct 2008 12:00:46 -0700 References: <38F26F36EAA981478A49D1F37F474A86020D01F8@xmb-ams-33d.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC06577440@xmb-ams-337.emea.cisco.com> <179B90FC-33BF-4FF1-908C-9B539E6AE82A@archrock.com> <38F26F36EAA981478A49D1F37F474A86020D05FC@xmb-ams-33d.emea.cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] hc-01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Julien, Your comments are valid. By adding a single bit, I think we can support all the cases you mention without compromising any of the cases we currently support. So here is a proposed modification: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | X | X | X | X | TF | HLIM |NH | CTX | SAM | M | DAM | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - CTX (context identifier for both source and destination addrs, if applicable): - 00: Link-local - 01: Unspecified Address (valid only for source addr with mcast) - 10: Global w/ Default - 11: Global w/ Context Identifier Extension - SAM: - 00: 128-bit - 01: 64-bit - 10: 16-bit - 11: 0-bit - M: Multicat - 0: Unicast Destination - 1: Multicast Destination - DAM: - When M = 0: - 00: 128-bit - 01: 64-bit - 10: 16-bit - 11: 0-bit - When M = 1: - 00: 128-bit - 01: 48-bit (FFXX:XXplen::prefix:XXXX:XXXX) - 10: 48-bit (FF0X::XX:XXXX:XXXX) - 11: 8-bit (FF02::XX) This covers all the multicast cases you care about. It also covers multicast with a global source address. And it covers all the unicast formats that we've supported since the beginning (link-local, global with default context, global with other contexts). Whether or not we want to support all of the cases you outlined is a question, but given that it only adds a single bit to the format, I think it's little added overhead. How does that look to you? -- Jonathan Hui On Oct 9, 2008, at 5:45 AM, Julien Abeille (jabeille) wrote: > Hi Pascal, Jonathan, > > For addresses I see an issue with a few scenarios: > - dest multicast, source global non compressable (SAM does not define > 128 bits format) > - some dest multicast are not in either of the 4 DAM cases, e.g > FF3E:0040:aaaa:a:a:a:1:1 (address based on prefix aaaa:a:a:a::/64, > with > 32 bit group id = 1:1) > > Pascal, can you clarify the DDF = 01 case > > I tried to make my ideas clear by listing all current multicast > scenarios , based on > http://www.iana.org/assignments/ipv6-multicast-addresses and RFC > 3306 + > 3956 (unicast prefix based multicast addresses) > > A 128, not compressed > B FF02::XX 1 byte needed > C FF0X::00XX:XXXX 4 bytes needed > D FF0X::00XX:XXXX:XXXX 6 bytes needed > E unicast prefix based address, not embedding rendez vous point: 5 > bytes > needed > F unicast prefix based address, embedding rendez vous point: 6 bytes > needed > > A covers unicast prefix based multicast addresses with prefix not in > context > B covers most useful link local cases (see IANA) e.g. LL all nodes, > FF02::1 > C covers longer well known cases (see IANA) e.g. all-dhcp-servers > FF05::1:3 > D covers solicited node and node information queries FF02::1:FFXX:XXXX > and FF02::2:FFXX:XXXX > E covers format defined in RFC3306, when the prefix used is in the > default context. > > | 8 | 4 | 4 | 8 | 8 | 64 | 32 | > +--------+----+----+--------+----+----------------+----------+ > |11111111|flgs|scop|reserved|plen| network prefix | group ID | > +--------+----+----+--------+----+----------------+----------+ > Here flags are 0011 (e.g. not embedding rendez vous point, unicast > prefix based, non permanently assigned) > We only need to send flags, scope, group ID (5 bytes) > > F covers format defined in RFC3956, when the prefix used is in the > default context. > > | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | > +--------+----+----+----+----+----+----------------+----------+ > |11111111|flgs|scop|rsvd|RIID|plen| network prefix | group ID | > +--------+----+----+----+----+----+----------------+----------+ > Here flags are 0111 (e.g. embedding rendez vous point, unicast prefix > based, non permanently assigned) > We only need flags, scope, reserved + RIID, group ID (6bytes) > > > Questions: > - do we want to support all this? > - do we want to group some cases: we could group C and D, E and F, > then > we have 4 cases only > - what do we do for dest multicast, source non compressable. > - Do we keep unspecified support? > - do we afford one more bit (this would be 7 bits for addresses) and > use > dispatch e.g. 1101xxxx? > - do we keep src and dest encoding linked. For now we have 2 bits > common > to src and dest (DDF), plus SAM and DAM. This makes 16 cases for both > src and dest, 32 in total. > > Cheers, > Julien > > > -----Original Message----- > From: Jonathan Hui [mailto:jhui@archrock.com] > Sent: jeudi 9 octobre 2008 01:50 > To: Pascal Thubert (pthubert) > Cc: Julien Abeille (jabeille); 6lowpan@ietf.org > Subject: Re: hc-01 > > > Hi Pascal, > > I think this looks great. It covers the cases we care about (unicast > and > multicast) without using any extra bits that my initial proposal. > The small thing I would change is moving the "DDF" field to bits 10-11 > (shifting TF and NH 2 bits to the left). Then TF would not span a byte > boundary. > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > | 0 | 1 | 0 | 0 | 1 | TF |NH | HLIM | DDF | SAM | DAM | > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > > -- > Jonathan Hui > > > > On Oct 8, 2008, at 4:31 PM, Pascal Thubert (pthubert) wrote: > >> Hi Julien: >> >> I think you're right, we need to dig a little bit more. >> >> So starting from Jonathan's encoding, maybe we can refine was was CTX >> >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >> | 0 | 1 | 0 | 0 | 1 | DDF | TF |NH | HLIM | SAM | DAM | >> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >> >> - Dispatch: 8-15 >> - DDF: Destination dependant fiels >> - 00: Destination is global (or ULA), no context byte after the HC >> field >> - 01: Destination is global (or ULA), one byte context byte after the > >> HC field >> - 10: Destination is Link local >> - 11: Destination is multicast scoped address >> >> - TF: Traffic Class, Flow Label >> - 00: 4-bit Pad + Traffic Class + Flow Label (4 bytes) >> - 01: ECN + 2-bit Pad + Flow Label (3 bytes) >> - 10: Traffic Class (1 byte) >> - 11: No Traffic Class and Flow Label >> >> - NH: Next Header compression >> >> - HLIM: Hop Limit >> - 00: uncompressed >> - 01: 1 >> - 10: 64 >> - 11: 255 >> >> When destination is link local: >> ------------------------------- >> prefix is FC80::/64 when compressed >> >> - SAM: Source Address Mode - prefix is link-local, when compressed >> - 00: 128 bits >> - 01: 64 bits >> - 10: 16 bits >> - 11: 0 bits >> - DAM: Destination Address Mode - prefix is link-local, when >> compressed >> - 00: 128 bits >> - 01: 64 bits >> - 10: 16 bits >> - 11: 0 bits >> >> When destination is multicast: >> ------------------------------- >> prefix is FF02::/64 when compressed >> >> - SAM: Source Address Mode >> - 00: 0 bits, unspecified address >> - 01: 64 bits, prefix is link local >> - 10: 16 bits, prefix is link local >> - 11: 0 bits, derived from the IID, prefix is link local >> - DAM: Destination Address Mode - prefix is link-local, when >> compressed >> - 00: 8 bits, prefix is compressed, suffix is 7 octets of zeroes, >> then this octet >> - 01: 24 bits, prefix is compressed, suffix is 4 octets of zeroes, >> then one octet 0xFF then this octet >> - 10: 16 bits. 4 bits flags, 4 bits scope, 1 byte suffix. >> Prefix as defined in RFC 4291, suffix is 7 octets of zeroes, then >> this > >> suffix octet >> - 11: 24 bits 4 bits flags, 4 bits scope, 2 bytes suffix Prefix as >> defined in RFC 4291, suffix is 6 octets of zeroes, then those suffix >> octets >> >> When destination is ULA or global: >> ------------------------------- >> The prefix is found from the context table. >> If there is no context octet after the HC field then this is the >> default prefix. >> >> - SAM: Source Address Mode >> - 00: 128 bits >> - 01: 64 bits >> - 10: 16 bits >> - 11: 0 bits >> - DAM: Destination Address Mode >> - 00: 128 bits >> - 01: 64 bits >> - 10: 16 bits >> - 11: 0 bits >> >> Notes: >> >> With this change, the 16 bits format of Link local and ULA and global >> really means the last 16 bits ( apposed to 15 in >> http://tools.ietf.org/html/draft-ietf-6lowpan-hc-00 >> 2.2. IPv6 Unicast Address Compression. >> >> With this change, we have the most useful mcast cases covered: >> DAM of 00 compresses FF02::XX, so you get all routers on link, etc... >> DAM of 01 compresses FF02::FFXX:YYZZ, sollicited node mcast address >> DAM of 10 and 11 compress all permanently-assigned multicast >> addresses > >> defined today for all scopes >> >> What do you think? >> >> Pascal >> ________________________________________ >> From: Julien Abeille (jabeille) >> Sent: mercredi 8 octobre 2008 17:51 >> To: Jonathan Hui >> Cc: Pascal Thubert (pthubert) >> Subject: hc-01 >> >> Hi Jonathan, >> >> I send unicast because my thought will not be clear, and to make a >> quick presentation and bind it to "cisco sensor team". >> I did my master thesis in 2005 at Cisco in Sophia Antipolis. My >> project manager was Patrick Wetterwald (IPSO president) and I worked >> with Pascal on tree discovery and bubbles protocols. I joined Cisco >> as > >> employee in july last year, and have been working on sensors with >> Patrick as project manager, Pascal and a few others as engineers. I >> met JP Vasseur a year ago and we have frequent calls and meetings, as >> he recently moved 150km from switzerland where my office is. I work >> most closely with Mathilde Durvy whom you met for IPSO interop calls. >> >> after discussion with Pascal about address compression, I try to >> clarify my thoughts: >> - 64 last bits compression in unicast address compression is only >> feasible if last 64 bits are based on IID (either 64 bit MAC address >> or PAN ID+0+16bit address). I thought it would be nice to be able to >> compress as well addresses with bytes 8 to 13 = 0. (e.g. a::1) >> - could be nice as well to compress the IID only when the prefix is >> not compressable? >> - for multicast address compression, i thought stateless compression >> could be nice. This works well with permanently assigned addresses >> (Pascal, the link i promissed: >> http://www.iana.org/assignments/ipv6-multicast-addresses) >> , as many bytes are 0 after the two first ones >> - for multicast again, it would be nice to be able to compress >> addresses with more than 9-bit non 0 (a few permanently assigned ones >> apply there, like all-dhcp-agents) >> - regarding the 16-bit compressed format, i would prefer not having >> one bit or more in the compressed field with a special meaning (first >> bit 0 = unicast, 3 first bits 101 = multicast), but keep all these >> bits in the encoding >> - I was wondering if assuming flags are 0 cannot be an issue. >> >> These are just thoughts, as i am not extremely clear on the important >> scenarios where we want to compress (e.g. solicited node multicast >> compression might not be needed as with ND optimizations, there will >> not be many NS), and am not clear either about multicast addresses >> except permanently assigned ones. More preciely i do not know if we >> want to support unicast prefix based multicast addresses or rendez >> vous point addresses, and what they look like. >> >> hope this helps in the discussion, >> regards, >> Julien >> > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Oct 9 12:17:34 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1E843A6AC0; Thu, 9 Oct 2008 12:17:33 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 515F128C190 for <6lowpan@core3.amsl.com>; Thu, 9 Oct 2008 12:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jbm6J0SkbfoM for <6lowpan@core3.amsl.com>; Thu, 9 Oct 2008 12:17:32 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 648E03A6AE0 for <6lowpan@ietf.org>; Thu, 9 Oct 2008 12:17:32 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 82F17AF8B4; Thu, 9 Oct 2008 12:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-IPhKneQpT3; Thu, 9 Oct 2008 12:17:22 -0700 (PDT) Received: from [192.168.7.78] (69-12-164-140.sfo.archrock.com [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id 82D9BAF8B1; Thu, 9 Oct 2008 12:17:22 -0700 (PDT) Message-Id: <641900E3-3665-4BED-9FA5-F8FB1667092F@archrock.com> From: Jonathan Hui To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC065C29B2@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 9 Oct 2008 12:17:21 -0700 References: <38F26F36EAA981478A49D1F37F474A86020D06DA@xmb-ams-33d.emea.cisco.com> <105175C7-A788-4225-9E5A-845A07AA3621@tzi.org> <7892795E1A87F04CADFCCF41FADD00FC065C29B2@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: Carsten Bormann , 6lowpan@ietf.org, Geoff Mulligan Subject: Re: [6lowpan] rfc4944, hc and dispatchs X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org In general, I'm in support of Pascal's proposal. Cleaning up the format to use a stacked-header format was just one of the items and there were many other things we wanted to fix before pushing out RFC 4944. But we were far too late to the game in doing a complete overhaul of the doc. I think *now* is the time to make improvements to RFC 4944. -- Jonathan Hui On Oct 9, 2008, at 10:41 AM, Pascal Thubert (pthubert) wrote: > Hi Carsten: > > Some implementations and dependant standards would require a timeline > for this. Leaving it up in the air does not help our users do their > product planning? > > Considering the attention and the work on the new LOWPAN_IPHC, I > expect > that we'll be ready for WGLC after 2/3 more respins. That could be > achieved by Minneapolis time if we can rally all interested parties to > comment on the existing published spec. So could you chairs please: > >>>>>>>>>>> propose a time line to the WG along those lines <<<<<<<<<<<< >>>>>>>>>>> raise WG attention on this work? <<<<<<<<<<<< > > Also by or at Minneapolis, my sensation is that we should not only > discuss the terms of deprecating RFC 4944 HC but also consider the > spec > as a whole: > > - Mesh Header is a layer violation. I talked to implementers and their > message is that they do not use it because it's never exactely what > that > specific radio needs; so they end up with their own mesh header anyway > and will not duplicate things for the sake of comliance. Instead we > might need a Routing header, pretty useful for source routing in route > over. > > - Fragments are not recovered individually. We have enough > experience to > know where that leads should a 6LoWPAN network experience either high > load or high BER. We have a draft on the works to deprecate that with > recoverable fragments. > > - The Current HC WG doc covers all the compression cases in RFC 4944, > bigger and badder. > > So what's left? > > My proposal is to start a 4944bis that would focus on the addressing > architecture, would be the placeholder to control the dispatch type > but > would defer to the drafts/RFCs that actually detail the operation of > each dispatch type. > > What do you think? > > Pascal > >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Carsten Bormann >> Sent: jeudi 9 octobre 2008 16:43 >> To: Julien Abeille (jabeille) >> Cc: Carsten Bormann; 6lowpan@ietf.org >> Subject: Re: [6lowpan] rfc4944, hc and dispatchs >> >> On Oct 09 2008, at 16:09, Julien Abeille (jabeille) wrote: >> >>> - does it officialy deprecate the old header compression scheme? >> >> My impression of the mailing list consensus is that this is what the >> WG wants to achieve. >> At the time this was discussed, I cautioned that it is premature to >> decide on replacing something existing with known flaws with >> something >> not yet quite cooked (and, hence, with unknown flaws). >> So I expect we'll ultimately decide this question at the time HC and >> the related specs come up for WGLC. >> Clearly, the stated intention of many WG members is to make this >> happen, as it would be wasteful to support two HC schemes in tiny >> implementations. >> >> Gruesse, Carsten >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Oct 9 16:51:04 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C45253A6949; Thu, 9 Oct 2008 16:51:04 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F7523A68C1 for <6lowpan@core3.amsl.com>; Thu, 9 Oct 2008 16:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZualXJcQ7XN for <6lowpan@core3.amsl.com>; Thu, 9 Oct 2008 16:51:02 -0700 (PDT) Received: from server1.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id 96BA73A67EC for <6lowpan@ietf.org>; Thu, 9 Oct 2008 16:51:02 -0700 (PDT) Received: from [192.168.174.29] ([207.236.117.244]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id m99Norh0020020 for <6lowpan@ietf.org>; Thu, 9 Oct 2008 17:50:55 -0600 (MDT) From: Geoff Mulligan To: 6lowpan <6lowpan@ietf.org> Date: Thu, 09 Oct 2008 17:50:48 -0600 Message-Id: <1223596248.7321.33.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: [6lowpan] HC-01 draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Folks, The draft of the new HC format has been published as a WG document: http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-hc-01.txt There has been some good discussion around this, but would everyone take up that task to read and review the current draft and provide feedback. Jonathan do you already have updates for the draft or is -01 the most current thoughts? So that we can close on this document sooner rather than later I am going to continue to bug the group to deal with this document. Please read it now and send comments to the list. geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Oct 9 17:08:43 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FE4C3A6AD4; Thu, 9 Oct 2008 17:08:43 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C023F3A69CB for <6lowpan@core3.amsl.com>; Thu, 9 Oct 2008 17:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBGnpMFt5VGK for <6lowpan@core3.amsl.com>; Thu, 9 Oct 2008 17:08:42 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 12ED23A6AD4 for <6lowpan@ietf.org>; Thu, 9 Oct 2008 17:08:42 -0700 (PDT) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id m9A08oIC006508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 9 Oct 2008 17:09:10 -0700 (PDT) Message-ID: <48EE9D0D.9080707@eecs.berkeley.edu> Date: Thu, 09 Oct 2008 17:08:45 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: David Culler References: In-Reply-To: Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] I-D of interest to this list - Zigbee Application Protocol over UDP/IP, including 6LoPWAN X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1320390192==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============1320390192== Content-Type: multipart/alternative; boundary="------------060905070807000205050207" This is a multi-part message in MIME format. --------------060905070807000205050207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Nice. The beginning of the end for the Zigbee network stack. Few will mourn it's passing. ksjp David Culler wrote: > http://tools.ietf.org/html/draft-tolle-cap-00 > > ------------------------------------------------------------------------ > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > --------------060905070807000205050207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nice.  The beginning of the end for the Zigbee network stack.  Few will mourn it's passing.

ksjp

David Culler wrote: 

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
--------------060905070807000205050207-- --===============1320390192== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan --===============1320390192==-- From 6lowpan-bounces@ietf.org Thu Oct 9 17:16:13 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3BE63A6A5F; Thu, 9 Oct 2008 17:16:12 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FF5D3A68C1 for <6lowpan@core3.amsl.com>; Thu, 9 Oct 2008 17:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZG7Vtw6ugB81 for <6lowpan@core3.amsl.com>; Thu, 9 Oct 2008 17:14:51 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 3E5C63A68AC for <6lowpan@ietf.org>; Thu, 9 Oct 2008 17:14:51 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 9so124166eyd.31 for <6lowpan@ietf.org>; Thu, 09 Oct 2008 17:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=ff3VnfIGFZd9QG7kQ/SW57qE8P7cTqdam7CToS1DsLk=; b=WYmtvutdjo3tzWqeF86oQHJAGcdc4riTxHzSW4LaBk30XUEHWoiIaRGGBq3xYCJmo7 KAjgqOu81sFJwWSIyehI5BzOoB6FgB3790lPSbc7O5BwbUBzTqsiaBVKFRk8U0VHukRr BjXUOwHkq6LEq/KSeV+o7lHwS1ysXImiXXFD4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=Zh31xXnQzejKERZ8qNS7xCK9z29PNd5vSIF2nYTs6K+WVviO1eEQzXNEgyfXOgPSLb xJIW3s69DpNxMGFYzzknxml8vjmQezsPWzcG1FO+nbqL8su2uBsBVWQ7bAzHW5ZPqbwE um5vBiYKIhePy16OYs2AsM5WFIugUtcAOUViY= Received: by 10.210.142.10 with SMTP id p10mr952579ebd.38.1223597734982; Thu, 09 Oct 2008 17:15:34 -0700 (PDT) Received: by 10.210.123.1 with HTTP; Thu, 9 Oct 2008 17:15:34 -0700 (PDT) Message-ID: <1edd46e70810091715waf749e8ye94763c3b3dbb7f2@mail.gmail.com> Date: Thu, 9 Oct 2008 17:15:34 -0700 From: "Joe Polastre" To: "David Culler" In-Reply-To: <48EE9D0D.9080707@eecs.berkeley.edu> MIME-Version: 1.0 Content-Disposition: inline References: <48EE9D0D.9080707@eecs.berkeley.edu> X-Google-Sender-Auth: 73c5214c728d98db Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] I-D of interest to this list - Zigbee Application Protocol over UDP/IP, including 6LoPWAN X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org David and Gil, Is there any possibility of working with the Zigbee Alliance to allow alternate networking (namely 6lowpan) underneath the Zigbee Application Protocol in future revisions of the Zigbee Specification? This would be the biggest win for customers, since the IETF informational draft you sent describes a fork of the Zigbee Specification. While technically this makes quite a bit of sense, it will only add additional confusion to multitude of networking options that customers and integrators are struggling to understand. -Joe On Thu, Oct 9, 2008 at 5:08 PM, Kris Pister wrote: > Nice. The beginning of the end for the Zigbee network stack. Few will > mourn it's passing. > > ksjp > > David Culler wrote: > > http://tools.ietf.org/html/draft-tolle-cap-00 > > ________________________________ > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Oct 9 20:04:36 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EFD53A68BC; Thu, 9 Oct 2008 20:04:36 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1DDD3A68BC for <6lowpan@core3.amsl.com>; Thu, 9 Oct 2008 20:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ca+0YW3bUTuf for <6lowpan@core3.amsl.com>; Thu, 9 Oct 2008 20:04:31 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id E873E3A6359 for <6lowpan@ietf.org>; Thu, 9 Oct 2008 20:04:31 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id BBC84AF8B6; Thu, 9 Oct 2008 20:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJpFSRlZJSxY; Thu, 9 Oct 2008 20:05:04 -0700 (PDT) Received: from [10.0.1.198] (adsl-71-142-65-236.dsl.pltn13.pacbell.net [71.142.65.236]) by mail.sf.archrock.com (Postfix) with ESMTP id 6825AAF8B1; Thu, 9 Oct 2008 20:05:04 -0700 (PDT) Message-Id: <23F4D81C-9DDA-40A7-A295-6F95C3BA4DF5@archrock.com> From: Jonathan Hui To: Jonathan Hui In-Reply-To: <9DDB4F7F-D00C-4873-A28A-849B46FE67DF@archrock.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 9 Oct 2008 20:05:02 -0700 References: <38F26F36EAA981478A49D1F37F474A86020D01F8@xmb-ams-33d.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC06577440@xmb-ams-337.emea.cisco.com> <179B90FC-33BF-4FF1-908C-9B539E6AE82A@archrock.com> <38F26F36EAA981478A49D1F37F474A86020D05FC@xmb-ams-33d.emea.cisco.com> <9DDB4F7F-D00C-4873-A28A-849B46FE67DF@archrock.com> X-Mailer: Apple Mail (2.929.2) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] hc-01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Julien, I realized that the 128-bit case for both unicast and multicast is redundant. So I made a minor change to add extra support for multicast compression. See below: > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > | X | X | X | X | TF | HLIM |NH | CTX | SAM | M | DAM | > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > > - CTX (context identifier for both source and destination addrs, if > applicable): > - 00: Link-local > - 01: Unspecified Address (valid only for source addr with mcast) > - 10: Global w/ Default > - 11: Global w/ Context Identifier Extension > > - SAM: > - 00: 128-bit > - 01: 64-bit > - 10: 16-bit > - 11: 0-bit > > - M: Multicat Compression > - 0: Prefix Compression > - 1: Multicast Compression > > - DAM: > - When M = 0: > - 00: 128-bit > - 01: 64-bit > - 10: 16-bit > - 11: 0-bit > - When M = 1: > - 00: 48-bit (FFXX:XXplen::prefix:XXXX:XXXX) > - 01: 48-bit (FF0X::XX:XXXX:XXXX) > - 10: 32-bit (FF0X::XX:XXXX) > - 11: 8-bit (FF02::XX) -- Jonathan Hui > > > This covers all the multicast cases you care about. It also covers > multicast with a global source address. And it covers all the > unicast formats that we've supported since the beginning (link- > local, global with default context, global with other contexts). > Whether or not we want to support all of the cases you outlined is a > question, but given that it only adds a single bit to the format, I > think it's little added overhead. > > How does that look to you? > > -- > Jonathan Hui > > > > On Oct 9, 2008, at 5:45 AM, Julien Abeille (jabeille) wrote: > >> Hi Pascal, Jonathan, >> >> For addresses I see an issue with a few scenarios: >> - dest multicast, source global non compressable (SAM does not define >> 128 bits format) >> - some dest multicast are not in either of the 4 DAM cases, e.g >> FF3E:0040:aaaa:a:a:a:1:1 (address based on prefix aaaa:a:a:a::/64, >> with >> 32 bit group id = 1:1) >> >> Pascal, can you clarify the DDF = 01 case >> >> I tried to make my ideas clear by listing all current multicast >> scenarios , based on >> http://www.iana.org/assignments/ipv6-multicast-addresses and RFC >> 3306 + >> 3956 (unicast prefix based multicast addresses) >> >> A 128, not compressed >> B FF02::XX 1 byte needed >> C FF0X::00XX:XXXX 4 bytes needed >> D FF0X::00XX:XXXX:XXXX 6 bytes needed >> E unicast prefix based address, not embedding rendez vous point: 5 >> bytes >> needed >> F unicast prefix based address, embedding rendez vous point: 6 bytes >> needed >> >> A covers unicast prefix based multicast addresses with prefix not in >> context >> B covers most useful link local cases (see IANA) e.g. LL all nodes, >> FF02::1 >> C covers longer well known cases (see IANA) e.g. all-dhcp-servers >> FF05::1:3 >> D covers solicited node and node information queries >> FF02::1:FFXX:XXXX >> and FF02::2:FFXX:XXXX >> E covers format defined in RFC3306, when the prefix used is in the >> default context. >> >> | 8 | 4 | 4 | 8 | 8 | 64 | 32 | >> +--------+----+----+--------+----+----------------+----------+ >> |11111111|flgs|scop|reserved|plen| network prefix | group ID | >> +--------+----+----+--------+----+----------------+----------+ >> Here flags are 0011 (e.g. not embedding rendez vous point, unicast >> prefix based, non permanently assigned) >> We only need to send flags, scope, group ID (5 bytes) >> >> F covers format defined in RFC3956, when the prefix used is in the >> default context. >> >> | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | >> +--------+----+----+----+----+----+----------------+----------+ >> |11111111|flgs|scop|rsvd|RIID|plen| network prefix | group ID | >> +--------+----+----+----+----+----+----------------+----------+ >> Here flags are 0111 (e.g. embedding rendez vous point, unicast prefix >> based, non permanently assigned) >> We only need flags, scope, reserved + RIID, group ID (6bytes) >> >> >> Questions: >> - do we want to support all this? >> - do we want to group some cases: we could group C and D, E and F, >> then >> we have 4 cases only >> - what do we do for dest multicast, source non compressable. >> - Do we keep unspecified support? >> - do we afford one more bit (this would be 7 bits for addresses) >> and use >> dispatch e.g. 1101xxxx? >> - do we keep src and dest encoding linked. For now we have 2 bits >> common >> to src and dest (DDF), plus SAM and DAM. This makes 16 cases for both >> src and dest, 32 in total. >> >> Cheers, >> Julien >> >> >> -----Original Message----- >> From: Jonathan Hui [mailto:jhui@archrock.com] >> Sent: jeudi 9 octobre 2008 01:50 >> To: Pascal Thubert (pthubert) >> Cc: Julien Abeille (jabeille); 6lowpan@ietf.org >> Subject: Re: hc-01 >> >> >> Hi Pascal, >> >> I think this looks great. It covers the cases we care about >> (unicast and >> multicast) without using any extra bits that my initial proposal. >> The small thing I would change is moving the "DDF" field to bits >> 10-11 >> (shifting TF and NH 2 bits to the left). Then TF would not span a >> byte >> boundary. >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >> | 0 | 1 | 0 | 0 | 1 | TF |NH | HLIM | DDF | SAM | DAM | >> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >> >> -- >> Jonathan Hui >> >> >> >> On Oct 8, 2008, at 4:31 PM, Pascal Thubert (pthubert) wrote: >> >>> Hi Julien: >>> >>> I think you're right, we need to dig a little bit more. >>> >>> So starting from Jonathan's encoding, maybe we can refine was was >>> CTX >>> >>> >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>> | 0 | 1 | 0 | 0 | 1 | DDF | TF |NH | HLIM | SAM | DAM | >>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>> >>> - Dispatch: 8-15 >>> - DDF: Destination dependant fiels >>> - 00: Destination is global (or ULA), no context byte after the HC >>> field >>> - 01: Destination is global (or ULA), one byte context byte after >>> the >> >>> HC field >>> - 10: Destination is Link local >>> - 11: Destination is multicast scoped address >>> >>> - TF: Traffic Class, Flow Label >>> - 00: 4-bit Pad + Traffic Class + Flow Label (4 bytes) >>> - 01: ECN + 2-bit Pad + Flow Label (3 bytes) >>> - 10: Traffic Class (1 byte) >>> - 11: No Traffic Class and Flow Label >>> >>> - NH: Next Header compression >>> >>> - HLIM: Hop Limit >>> - 00: uncompressed >>> - 01: 1 >>> - 10: 64 >>> - 11: 255 >>> >>> When destination is link local: >>> ------------------------------- >>> prefix is FC80::/64 when compressed >>> >>> - SAM: Source Address Mode - prefix is link-local, when compressed >>> - 00: 128 bits >>> - 01: 64 bits >>> - 10: 16 bits >>> - 11: 0 bits >>> - DAM: Destination Address Mode - prefix is link-local, when >>> compressed >>> - 00: 128 bits >>> - 01: 64 bits >>> - 10: 16 bits >>> - 11: 0 bits >>> >>> When destination is multicast: >>> ------------------------------- >>> prefix is FF02::/64 when compressed >>> >>> - SAM: Source Address Mode >>> - 00: 0 bits, unspecified address >>> - 01: 64 bits, prefix is link local >>> - 10: 16 bits, prefix is link local >>> - 11: 0 bits, derived from the IID, prefix is link local >>> - DAM: Destination Address Mode - prefix is link-local, when >>> compressed >>> - 00: 8 bits, prefix is compressed, suffix is 7 octets of zeroes, >>> then this octet >>> - 01: 24 bits, prefix is compressed, suffix is 4 octets of zeroes, >>> then one octet 0xFF then this octet >>> - 10: 16 bits. 4 bits flags, 4 bits scope, 1 byte suffix. >>> Prefix as defined in RFC 4291, suffix is 7 octets of zeroes, then >>> this >> >>> suffix octet >>> - 11: 24 bits 4 bits flags, 4 bits scope, 2 bytes suffix Prefix as >>> defined in RFC 4291, suffix is 6 octets of zeroes, then those suffix >>> octets >>> >>> When destination is ULA or global: >>> ------------------------------- >>> The prefix is found from the context table. >>> If there is no context octet after the HC field then this is the >>> default prefix. >>> >>> - SAM: Source Address Mode >>> - 00: 128 bits >>> - 01: 64 bits >>> - 10: 16 bits >>> - 11: 0 bits >>> - DAM: Destination Address Mode >>> - 00: 128 bits >>> - 01: 64 bits >>> - 10: 16 bits >>> - 11: 0 bits >>> >>> Notes: >>> >>> With this change, the 16 bits format of Link local and ULA and >>> global >>> really means the last 16 bits ( apposed to 15 in >>> http://tools.ietf.org/html/draft-ietf-6lowpan-hc-00 >>> 2.2. IPv6 Unicast Address Compression. >>> >>> With this change, we have the most useful mcast cases covered: >>> DAM of 00 compresses FF02::XX, so you get all routers on link, >>> etc... >>> DAM of 01 compresses FF02::FFXX:YYZZ, sollicited node mcast address >>> DAM of 10 and 11 compress all permanently-assigned multicast >>> addresses >> >>> defined today for all scopes >>> >>> What do you think? >>> >>> Pascal >>> ________________________________________ >>> From: Julien Abeille (jabeille) >>> Sent: mercredi 8 octobre 2008 17:51 >>> To: Jonathan Hui >>> Cc: Pascal Thubert (pthubert) >>> Subject: hc-01 >>> >>> Hi Jonathan, >>> >>> I send unicast because my thought will not be clear, and to make a >>> quick presentation and bind it to "cisco sensor team". >>> I did my master thesis in 2005 at Cisco in Sophia Antipolis. My >>> project manager was Patrick Wetterwald (IPSO president) and I worked >>> with Pascal on tree discovery and bubbles protocols. I joined >>> Cisco as >> >>> employee in july last year, and have been working on sensors with >>> Patrick as project manager, Pascal and a few others as engineers. I >>> met JP Vasseur a year ago and we have frequent calls and meetings, >>> as >>> he recently moved 150km from switzerland where my office is. I work >>> most closely with Mathilde Durvy whom you met for IPSO interop >>> calls. >>> >>> after discussion with Pascal about address compression, I try to >>> clarify my thoughts: >>> - 64 last bits compression in unicast address compression is only >>> feasible if last 64 bits are based on IID (either 64 bit MAC address >>> or PAN ID+0+16bit address). I thought it would be nice to be able to >>> compress as well addresses with bytes 8 to 13 = 0. (e.g. a::1) >>> - could be nice as well to compress the IID only when the prefix is >>> not compressable? >>> - for multicast address compression, i thought stateless compression >>> could be nice. This works well with permanently assigned addresses >>> (Pascal, the link i promissed: >>> http://www.iana.org/assignments/ipv6-multicast-addresses) >>> , as many bytes are 0 after the two first ones >>> - for multicast again, it would be nice to be able to compress >>> addresses with more than 9-bit non 0 (a few permanently assigned >>> ones >>> apply there, like all-dhcp-agents) >>> - regarding the 16-bit compressed format, i would prefer not having >>> one bit or more in the compressed field with a special meaning >>> (first >>> bit 0 = unicast, 3 first bits 101 = multicast), but keep all these >>> bits in the encoding >>> - I was wondering if assuming flags are 0 cannot be an issue. >>> >>> These are just thoughts, as i am not extremely clear on the >>> important >>> scenarios where we want to compress (e.g. solicited node multicast >>> compression might not be needed as with ND optimizations, there will >>> not be many NS), and am not clear either about multicast addresses >>> except permanently assigned ones. More preciely i do not know if we >>> want to support unicast prefix based multicast addresses or rendez >>> vous point addresses, and what they look like. >>> >>> hope this helps in the discussion, >>> regards, >>> Julien >>> >> > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Oct 9 20:05:38 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0415A3A67AA; Thu, 9 Oct 2008 20:05:38 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A19C3A6831 for <6lowpan@core3.amsl.com>; Thu, 9 Oct 2008 20:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-rw+4vxyC6t for <6lowpan@core3.amsl.com>; Thu, 9 Oct 2008 20:05:35 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 6B4273A67AA for <6lowpan@ietf.org>; Thu, 9 Oct 2008 20:05:35 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 0E07FAF8B6; Thu, 9 Oct 2008 20:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAfduAvGZCBZ; Thu, 9 Oct 2008 20:06:12 -0700 (PDT) Received: from [10.0.1.198] (adsl-71-142-65-236.dsl.pltn13.pacbell.net [71.142.65.236]) by mail.sf.archrock.com (Postfix) with ESMTP id 8075BAF8B1; Thu, 9 Oct 2008 20:06:12 -0700 (PDT) Message-Id: <51B0D4E0-35AC-4657-818D-D037431B0127@archrock.com> From: Jonathan Hui To: Geoff Mulligan In-Reply-To: <1223596248.7321.33.camel@dellx1> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 9 Oct 2008 20:06:11 -0700 References: <1223596248.7321.33.camel@dellx1> X-Mailer: Apple Mail (2.929.2) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] HC-01 draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Geoff, On Oct 9, 2008, at 4:50 PM, Geoff Mulligan wrote: > Jonathan do you already have updates for the draft or is -01 the most > current thoughts? Julien has already provided good comments on 01 and we're currently discussion minor updates to address his concerns. Would love to get comments from others as well. Thanks. -- Jonathan Hui _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Oct 10 05:57:51 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D00983A69C9; Fri, 10 Oct 2008 05:57:51 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC35D3A69C9 for <6lowpan@core3.amsl.com>; Fri, 10 Oct 2008 05:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.216 X-Spam-Level: X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id py-v28mwtiA6 for <6lowpan@core3.amsl.com>; Fri, 10 Oct 2008 05:57:50 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id BBE713A684C for <6lowpan@ietf.org>; Fri, 10 Oct 2008 05:57:49 -0700 (PDT) Received: from h136223.gprs.dnafinland.fi (h136223.gprs.dnafinland.fi [87.93.136.223]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id m9ACwNmx029053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Oct 2008 15:58:25 +0300 Message-ID: <48EF5170.7050107@sensinode.com> Date: Fri, 10 Oct 2008 15:58:24 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Jonathan Hui References: <20081009021535.C8E823A6959@core3.amsl.com> In-Reply-To: Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-hc-01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi, Here are my comments on hc-01. Overall I think we are quite close with the comments from Pascal and Julien. I found the DDF name confusing. Now it has been renamed CTX in the latest formats on the list, great. As Pascal pointed out, nodes need to be able to decode all these options. One thing that worries me in having 16 contexts, is that nodes are forced to store them all. That is worst case 272 bytes of memory consumption. Worth it? Is it possible that an ultra-simple node would only have to understand the default context? The default context identifier '0000' could be clarified more in the draft. When CTX is '10' then the default context identifier '0000' is used. It should be made clear that this is the prefix advertised in RAs as useable for SAA. Regarding the ND for 6lowpan draft, HC-01 means we need to add a 4-bit context identifier flag to the 6LoWPAN Prefix Information Option. To make things clear that should always be '0000' if the A flag is '1'? - Zach Jonathan Hui wrote: > > http://tools.ietf.org/html/draft-ietf-6lowpan-hc > > This new version reflects the recent discussions on the list. The > changes are: > - HC back to 1 byte by default by stealing a few bits from the dispatch > field. > - Added better support for multicast address compression. > - Fixed alignment for UDP port compression. > - Better support for Traffic Class and Flow Label compression. > - Pascal joined as an author. > > Happy reading! > > -- > Jonathan Hui > > > > Begin forwarded message: > >> From: IETF I-D Submission Tool >> Date: October 8, 2008 7:15:35 PM PDT >> To: jhui@archrock.com >> Cc: pthubert@cisco.com >> Subject: New Version Notification for draft-ietf-6lowpan-hc-01 >> >> >> A new version of I-D, draft-ietf-6lowpan-hc-01.txt has been >> successfuly submitted by Jonathan Hui and posted to the IETF repository. >> >> Filename: draft-ietf-6lowpan-hc >> Revision: 01 >> Title: Compression Format for IPv6 Datagrams in 6LoWPAN Networks >> Creation_date: 2008-10-09 >> WG ID: 6lowpan >> Number_of_pages: 15 >> >> Abstract: >> This document specifies an IPv6 header compression format for IPv6 >> packet delivery in 6LoWPAN networks. The compression format relies >> on shared context to allow compression of arbitrary prefixes. This >> document specifies compression of multicast addresses and a framework >> for compressing next headers. This framework specifies UDP >> compression and is prepared for additional transports. >> >> >> >> The IETF Secretariat. >> >> > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan -- Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti FINLAND mobile: +358 40 7796297 This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Oct 10 08:30:25 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9AAF28C15F; Fri, 10 Oct 2008 08:30:25 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DCF63A698C for <6lowpan@core3.amsl.com>; Fri, 10 Oct 2008 08:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSlfEXdfkBGd for <6lowpan@core3.amsl.com>; Fri, 10 Oct 2008 08:30:24 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id D60D93A6829 for <6lowpan@ietf.org>; Fri, 10 Oct 2008 08:30:24 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 01B36AF8BA; Fri, 10 Oct 2008 08:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0oVTOn+uxal; Fri, 10 Oct 2008 08:31:10 -0700 (PDT) Received: from [192.168.175.26] (unknown [207.236.117.244]) by mail.sf.archrock.com (Postfix) with ESMTP id C9DCEAF8AC; Fri, 10 Oct 2008 08:31:09 -0700 (PDT) Message-Id: <701CEF05-ED77-4073-B95B-320B30F9B7A3@archrock.com> From: Gilman Tolle To: Joe Polastre In-Reply-To: <1edd46e70810091715waf749e8ye94763c3b3dbb7f2@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 10 Oct 2008 08:31:07 -0700 References: <48EE9D0D.9080707@eecs.berkeley.edu> <1edd46e70810091715waf749e8ye94763c3b3dbb7f2@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) Cc: 6lowpan@ietf.org, David Culler Subject: Re: [6lowpan] I-D of interest to this list - Zigbee Application Protocol over UDP/IP, including 6LoPWAN X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Joe, The draft is there to get people thinking about a way to use IP as a technical solution to some of the interoperability issues that are arising in the space. If folks in the ZigBee Alliance are interested in including the idea in their specification, I'd be happy to work with the them. Gil On Oct 9, 2008, at 5:15 PM, Joe Polastre wrote: > David and Gil, > > Is there any possibility of working with the Zigbee Alliance to > allow alternate networking (namely 6lowpan) underneath the Zigbee > Application Protocol in future revisions of the Zigbee Specification? > This would be the biggest win for customers, since the IETF > informational draft you sent describes a fork of the Zigbee > Specification. While technically this makes quite a bit of sense, it > will only add additional confusion to multitude of networking options > that customers and integrators are struggling to understand. > > -Joe > > On Thu, Oct 9, 2008 at 5:08 PM, Kris Pister > wrote: >> Nice. The beginning of the end for the Zigbee network stack. Few >> will >> mourn it's passing. >> >> ksjp >> >> David Culler wrote: >> >> http://tools.ietf.org/html/draft-tolle-cap-00 >> >> ________________________________ >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> >> > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Oct 10 08:50:54 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83E6B3A6ADF; Fri, 10 Oct 2008 08:50:54 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFAF63A687F for <6lowpan@core3.amsl.com>; Fri, 10 Oct 2008 08:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sA55QCGmQivD for <6lowpan@core3.amsl.com>; Fri, 10 Oct 2008 08:50:52 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 4F6B63A63D2 for <6lowpan@ietf.org>; Fri, 10 Oct 2008 08:50:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,390,1220227200"; d="scan'208";a="22285877" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 10 Oct 2008 15:51:36 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9AFpa5n026850; Fri, 10 Oct 2008 17:51:36 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9AFpZ2h003374; Fri, 10 Oct 2008 15:51:36 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Oct 2008 17:51:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 10 Oct 2008 17:51:14 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC065C2E40@xmb-ams-337.emea.cisco.com> In-Reply-To: <641900E3-3665-4BED-9FA5-F8FB1667092F@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] rfc4944, hc and dispatchs Thread-Index: AckqQ7xDcayeruwMSWuB9jGLTevgRAArBYng References: <38F26F36EAA981478A49D1F37F474A86020D06DA@xmb-ams-33d.emea.cisco.com> <105175C7-A788-4225-9E5A-845A07AA3621@tzi.org> <7892795E1A87F04CADFCCF41FADD00FC065C29B2@xmb-ams-337.emea.cisco.com> <641900E3-3665-4BED-9FA5-F8FB1667092F@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 10 Oct 2008 15:51:18.0075 (UTC) FILETIME=[088D10B0:01C92AF0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4212; t=1223653896; x=1224517896; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20rfc4944,=20hc=20and=20dispa tchs |Sender:=20; bh=dbVwjU8cXKing98z0qr6F6D60iW5rWcURhlaJ5EAdjo=; b=vUcM/K+thNl75i9QlvaNcHBA+5rqCF6u47dT/B3SmobnHpzrju+Kpy9WXs WR/pktyR95juf2pdPvgeQtd0fKG4qQyLX6h8i531TYfeooxAIOOlo683MC/h 233wadZtGc; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Carsten Bormann , 6lowpan@ietf.org, Geoff Mulligan Subject: Re: [6lowpan] rfc4944, hc and dispatchs X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org I'm all with you, Jonathan, as long as that does not delay HC. This is why I proposed a structured set of document that leaves HC with its current scope as opposed to making it a full revision of 4944. Makes sense? Pascal >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com] >Sent: jeudi 9 octobre 2008 21:17 >To: Pascal Thubert (pthubert) >Cc: Carsten Bormann; Geoff Mulligan; 6lowpan@ietf.org >Subject: Re: [6lowpan] rfc4944, hc and dispatchs > > >In general, I'm in support of Pascal's proposal. Cleaning up the >format to use a stacked-header format was just one of the items and >there were many other things we wanted to fix before pushing out RFC >4944. But we were far too late to the game in doing a complete >overhaul of the doc. I think *now* is the time to make improvements to >RFC 4944. > >-- >Jonathan Hui > > > >On Oct 9, 2008, at 10:41 AM, Pascal Thubert (pthubert) wrote: > >> Hi Carsten: >> >> Some implementations and dependant standards would require a timeline >> for this. Leaving it up in the air does not help our users do their >> product planning? >> >> Considering the attention and the work on the new LOWPAN_IPHC, I >> expect >> that we'll be ready for WGLC after 2/3 more respins. That could be >> achieved by Minneapolis time if we can rally all interested parties to >> comment on the existing published spec. So could you chairs please: >> >>>>>>>>>>>> propose a time line to the WG along those lines <<<<<<<<<<<< >>>>>>>>>>>> raise WG attention on this work? <<<<<<<<<<<< >> >> Also by or at Minneapolis, my sensation is that we should not only >> discuss the terms of deprecating RFC 4944 HC but also consider the >> spec >> as a whole: >> >> - Mesh Header is a layer violation. I talked to implementers and their >> message is that they do not use it because it's never exactely what >> that >> specific radio needs; so they end up with their own mesh header anyway >> and will not duplicate things for the sake of comliance. Instead we >> might need a Routing header, pretty useful for source routing in route >> over. >> >> - Fragments are not recovered individually. We have enough >> experience to >> know where that leads should a 6LoWPAN network experience either high >> load or high BER. We have a draft on the works to deprecate that with >> recoverable fragments. >> >> - The Current HC WG doc covers all the compression cases in RFC 4944, >> bigger and badder. >> >> So what's left? >> >> My proposal is to start a 4944bis that would focus on the addressing >> architecture, would be the placeholder to control the dispatch type >> but >> would defer to the drafts/RFCs that actually detail the operation of >> each dispatch type. >> >> What do you think? >> >> Pascal >> >>> -----Original Message----- >>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >> Behalf Of Carsten Bormann >>> Sent: jeudi 9 octobre 2008 16:43 >>> To: Julien Abeille (jabeille) >>> Cc: Carsten Bormann; 6lowpan@ietf.org >>> Subject: Re: [6lowpan] rfc4944, hc and dispatchs >>> >>> On Oct 09 2008, at 16:09, Julien Abeille (jabeille) wrote: >>> >>>> - does it officialy deprecate the old header compression scheme? >>> >>> My impression of the mailing list consensus is that this is what the >>> WG wants to achieve. >>> At the time this was discussed, I cautioned that it is premature to >>> decide on replacing something existing with known flaws with >>> something >>> not yet quite cooked (and, hence, with unknown flaws). >>> So I expect we'll ultimately decide this question at the time HC and >>> the related specs come up for WGLC. >>> Clearly, the stated intention of many WG members is to make this >>> happen, as it would be wasteful to support two HC schemes in tiny >>> implementations. >>> >>> Gruesse, Carsten >>> >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Oct 10 09:01:44 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 179633A698C; Fri, 10 Oct 2008 09:01:44 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D95CC3A686D for <6lowpan@core3.amsl.com>; Fri, 10 Oct 2008 09:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WOcYzFnRQSG for <6lowpan@core3.amsl.com>; Fri, 10 Oct 2008 09:01:41 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id E1FA93A6A2A for <6lowpan@ietf.org>; Fri, 10 Oct 2008 09:01:41 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 16872AF8C3; Fri, 10 Oct 2008 09:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbQKVRUn6jzr; Fri, 10 Oct 2008 09:02:27 -0700 (PDT) Received: from [192.168.7.78] (69-12-164-140.sfo.archrock.com [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id 1545DAF8B1; Fri, 10 Oct 2008 09:02:27 -0700 (PDT) Message-Id: From: Jonathan Hui To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC065C2E40@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 10 Oct 2008 09:02:25 -0700 References: <38F26F36EAA981478A49D1F37F474A86020D06DA@xmb-ams-33d.emea.cisco.com> <105175C7-A788-4225-9E5A-845A07AA3621@tzi.org> <7892795E1A87F04CADFCCF41FADD00FC065C29B2@xmb-ams-337.emea.cisco.com> <641900E3-3665-4BED-9FA5-F8FB1667092F@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC065C2E40@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: Carsten Bormann , 6lowpan@ietf.org, Geoff Mulligan Subject: Re: [6lowpan] rfc4944, hc and dispatchs X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Pascal: I'm for pushing HC through as quickly as possible. We are already behind according to the charter text. The one dependency I see is the structure of the dispatch byte. If we choose a dispatch value(s) that is compatible with RFC 4944, then we are fine, I think. But if we want extra bits by changing the layout of the dispatch values/identifiers for Frag/Mesh headers (as both I and Julien have proposed) then this creates a dependency on defining that new dispatch assignment scheme. -- Jonathan Hui On Oct 10, 2008, at 8:51 AM, Pascal Thubert (pthubert) wrote: > I'm all with you, Jonathan, as long as that does not delay HC. > > This is why I proposed a structured set of document that leaves HC > with > its current scope as opposed to making it a full revision of 4944. > Makes > sense? > > Pascal > >> -----Original Message----- >> From: Jonathan Hui [mailto:jhui@archrock.com] >> Sent: jeudi 9 octobre 2008 21:17 >> To: Pascal Thubert (pthubert) >> Cc: Carsten Bormann; Geoff Mulligan; 6lowpan@ietf.org >> Subject: Re: [6lowpan] rfc4944, hc and dispatchs >> >> >> In general, I'm in support of Pascal's proposal. Cleaning up the >> format to use a stacked-header format was just one of the items and >> there were many other things we wanted to fix before pushing out RFC >> 4944. But we were far too late to the game in doing a complete >> overhaul of the doc. I think *now* is the time to make improvements >> to >> RFC 4944. >> >> -- >> Jonathan Hui >> >> >> >> On Oct 9, 2008, at 10:41 AM, Pascal Thubert (pthubert) wrote: >> >>> Hi Carsten: >>> >>> Some implementations and dependant standards would require a >>> timeline >>> for this. Leaving it up in the air does not help our users do their >>> product planning? >>> >>> Considering the attention and the work on the new LOWPAN_IPHC, I >>> expect >>> that we'll be ready for WGLC after 2/3 more respins. That could be >>> achieved by Minneapolis time if we can rally all interested parties > to >>> comment on the existing published spec. So could you chairs please: >>> >>>>>>>>>>>>> propose a time line to the WG along those lines > <<<<<<<<<<<< >>>>>>>>>>>>> raise WG attention on this work? > <<<<<<<<<<<< >>> >>> Also by or at Minneapolis, my sensation is that we should not only >>> discuss the terms of deprecating RFC 4944 HC but also consider the >>> spec >>> as a whole: >>> >>> - Mesh Header is a layer violation. I talked to implementers and > their >>> message is that they do not use it because it's never exactely what >>> that >>> specific radio needs; so they end up with their own mesh header > anyway >>> and will not duplicate things for the sake of comliance. Instead we >>> might need a Routing header, pretty useful for source routing in > route >>> over. >>> >>> - Fragments are not recovered individually. We have enough >>> experience to >>> know where that leads should a 6LoWPAN network experience either >>> high >>> load or high BER. We have a draft on the works to deprecate that >>> with >>> recoverable fragments. >>> >>> - The Current HC WG doc covers all the compression cases in RFC >>> 4944, >>> bigger and badder. >>> >>> So what's left? >>> >>> My proposal is to start a 4944bis that would focus on the addressing >>> architecture, would be the placeholder to control the dispatch type >>> but >>> would defer to the drafts/RFCs that actually detail the operation of >>> each dispatch type. >>> >>> What do you think? >>> >>> Pascal >>> >>>> -----Original Message----- >>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >>> Behalf Of Carsten Bormann >>>> Sent: jeudi 9 octobre 2008 16:43 >>>> To: Julien Abeille (jabeille) >>>> Cc: Carsten Bormann; 6lowpan@ietf.org >>>> Subject: Re: [6lowpan] rfc4944, hc and dispatchs >>>> >>>> On Oct 09 2008, at 16:09, Julien Abeille (jabeille) wrote: >>>> >>>>> - does it officialy deprecate the old header compression scheme? >>>> >>>> My impression of the mailing list consensus is that this is what >>>> the >>>> WG wants to achieve. >>>> At the time this was discussed, I cautioned that it is premature to >>>> decide on replacing something existing with known flaws with >>>> something >>>> not yet quite cooked (and, hence, with unknown flaws). >>>> So I expect we'll ultimately decide this question at the time HC >>>> and >>>> the related specs come up for WGLC. >>>> Clearly, the stated intention of many WG members is to make this >>>> happen, as it would be wasteful to support two HC schemes in tiny >>>> implementations. >>>> >>>> Gruesse, Carsten >>>> >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> 6lowpan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Oct 10 09:10:56 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36DC93A686D; Fri, 10 Oct 2008 09:10:56 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1FD43A68AA for <6lowpan@core3.amsl.com>; Fri, 10 Oct 2008 09:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VT7RTKW7dEa for <6lowpan@core3.amsl.com>; Fri, 10 Oct 2008 09:10:53 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id E82AF3A63D2 for <6lowpan@ietf.org>; Fri, 10 Oct 2008 09:10:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 435AFAF8AC; Fri, 10 Oct 2008 09:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBZWMlaq36xW; Fri, 10 Oct 2008 09:11:20 -0700 (PDT) Received: from [192.168.7.78] (69-12-164-140.sfo.archrock.com [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id 2A139AF86C; Fri, 10 Oct 2008 09:11:20 -0700 (PDT) Message-Id: From: Jonathan Hui To: Zach Shelby In-Reply-To: <48EF5170.7050107@sensinode.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 10 Oct 2008 09:11:18 -0700 References: <20081009021535.C8E823A6959@core3.amsl.com> <48EF5170.7050107@sensinode.com> X-Mailer: Apple Mail (2.929.2) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-hc-01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Zach, On Oct 10, 2008, at 5:58 AM, Zach Shelby wrote: > Here are my comments on hc-01. Overall I think we are quite close > with the comments from Pascal and Julien. > > I found the DDF name confusing. Now it has been renamed CTX in the > latest formats on the list, great. > > As Pascal pointed out, nodes need to be able to decode all these > options. One thing that worries me in having 16 contexts, is that > nodes are forced to store them all. That is worst case 272 bytes of > memory consumption. Worth it? Is it possible that an ultra-simple > node would only have to understand the default context? [jhui] The number of contexts is an issue I raised on the list a few weeks ago. Many seemed to think that two contexts was okay. However, I wanted us to be sure that 2 was enough and as a result there was no change in the number of contexts from hc-00 to hc-01. With an extra bit (13 bits total) we can certainly support 2 contexts without a context identifier extension. With two extra bits (14 bits) we can support 3 contexts. Any more would require an extra byte, I think. Of course, we can stick with the current encoding but we can limit use to X < 16 contexts. What do people think? > The default context identifier '0000' could be clarified more in the > draft. When CTX is '10' then the default context identifier '0000' > is used. It should be made clear that this is the prefix advertised > in RAs as useable for SAA. > > > Regarding the ND for 6lowpan draft, HC-01 means we need to add a 4- > bit context identifier flag to the 6LoWPAN Prefix Information > Option. To make things clear that should always be '0000' if the A > flag is '1'? [jhui] Those that are arguing for more than 2 contexts see it useful for renumbering. If that is the case, then SAA must have the flexibility for use with contexts other than the default. For now, I think it's best to consider having a context identifier included with the 6LoWPAN Prefix Information Option. -- Jonathan Hui > > > - Zach > > > Jonathan Hui wrote: >> http://tools.ietf.org/html/draft-ietf-6lowpan-hc >> This new version reflects the recent discussions on the list. The >> changes are: >> - HC back to 1 byte by default by stealing a few bits from the >> dispatch field. >> - Added better support for multicast address compression. >> - Fixed alignment for UDP port compression. >> - Better support for Traffic Class and Flow Label compression. >> - Pascal joined as an author. >> Happy reading! >> -- >> Jonathan Hui >> Begin forwarded message: >>> From: IETF I-D Submission Tool >>> Date: October 8, 2008 7:15:35 PM PDT >>> To: jhui@archrock.com >>> Cc: pthubert@cisco.com >>> Subject: New Version Notification for draft-ietf-6lowpan-hc-01 >>> >>> >>> A new version of I-D, draft-ietf-6lowpan-hc-01.txt has been >>> successfuly submitted by Jonathan Hui and posted to the IETF >>> repository. >>> >>> Filename: draft-ietf-6lowpan-hc >>> Revision: 01 >>> Title: Compression Format for IPv6 Datagrams in 6LoWPAN >>> Networks >>> Creation_date: 2008-10-09 >>> WG ID: 6lowpan >>> Number_of_pages: 15 >>> >>> Abstract: >>> This document specifies an IPv6 header compression format for IPv6 >>> packet delivery in 6LoWPAN networks. The compression format relies >>> on shared context to allow compression of arbitrary prefixes. This >>> document specifies compression of multicast addresses and a >>> framework >>> for compressing next headers. This framework specifies UDP >>> compression and is prepared for additional transports. >>> >>> >>> >>> The IETF Secretariat. >>> >>> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > > -- > > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti > FINLAND > > mobile: +358 40 7796297 > > This e-mail and all attached material are confidential and may > contain legally privileged information. If you are not the intended > recipient, please contact the sender and delete the e-mail from your > system without producing, distributing or retaining copies thereof. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Oct 10 09:26:28 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12A2C3A68F3; Fri, 10 Oct 2008 09:26:28 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEB403A6880 for <6lowpan@core3.amsl.com>; Fri, 10 Oct 2008 09:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GgkGRIhED2x for <6lowpan@core3.amsl.com>; Fri, 10 Oct 2008 09:26:25 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 6EFA83A63D2 for <6lowpan@ietf.org>; Fri, 10 Oct 2008 09:26:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,390,1220227200"; d="scan'208";a="22289332" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 10 Oct 2008 16:26:57 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9AGQvwv004054; Fri, 10 Oct 2008 18:26:57 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9AGQvpj011818; Fri, 10 Oct 2008 16:26:57 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Oct 2008 18:26:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 10 Oct 2008 18:26:30 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC065C2E62@xmb-ams-337.emea.cisco.com> In-Reply-To: <9DDB4F7F-D00C-4873-A28A-849B46FE67DF@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: hc-01 Thread-Index: AckqQV24Bz2J2XtDT+WY0zBxKCkTygArX7ZQ References: <38F26F36EAA981478A49D1F37F474A86020D01F8@xmb-ams-33d.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC06577440@xmb-ams-337.emea.cisco.com> <179B90FC-33BF-4FF1-908C-9B539E6AE82A@archrock.com> <38F26F36EAA981478A49D1F37F474A86020D05FC@xmb-ams-33d.emea.cisco.com> <9DDB4F7F-D00C-4873-A28A-849B46FE67DF@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "Julien Abeille (jabeille)" , "Zach Shelby" X-OriginalArrivalTime: 10 Oct 2008 16:26:40.0395 (UTC) FILETIME=[F98D65B0:01C92AF4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14708; t=1223656017; x=1224520017; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20hc-01 |Sender:=20; bh=bolo3o1Mt78I29hm2Np0Ap0RuQdx6xBQx/1lSBzMMX4=; b=cZIDrD1HJPmBVzzkat1YWe2V1MIcRMYuuaG5bnVYLSr0mxNtMbvZKOAmwV DdFFavEzfn7keQfAErFTVqBxm6fG4SMs5aKU6mYg8GchwMqFJGfa8OPWuHMp M72zywwMuF; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] hc-01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Jonathan: The way I see it, comparing to http://tools.ietf.org/html/draft-ietf-6lowpan-hc-01 - This is cleaner and more readable - but consumes an additional bit, that is 8 more dispatches that can not be used for something - this is done to simplify the code for multicast addresses that will be little to not used if the whiteboard ND is generalized. - and at the end of the day there is nothing that is really useful and compressed better here (do I miss something here?) I am fine with moving to this proposal if implementors (Julien?) confirm that the implementation is really simpler and worth the cost of 8 consecutive dispatch values. If not, please consider the response I made to Julien. We are NOT missing cases; but there are cases we do not compress because they are deemed rare enough. Let me try to defend the formats we have for the sake of the discussion and the stability of the draft. I think the bigger inadequacy in hc-01 (my fault I assume it) is the name DDF (Zach seems to confirm that) and the description of the field that is oriented on the type of address (causing Julien's concerns). When I look at it what do we do with this DDF field, what's really behind it is the method of compression being applied. Renaming DDF to CM we'd get: Compression Method (CM): 00 = Stateless compression using MAC address and inline values. Also uses a default context state for full compression. Includes the "no address compression" last resort. 01 = Stateful compression using contextual states, context byte follows 10 = Stateless compression (using well known prefix and MAC address) for Link local addresses 11 = Stateless compression (using well known prefix and inline values) for multicast addresses With that description, it appears more clearly that multicast address may be compressed using 00: - there is no address pair that can not be described with the format (00 covers all) - the stateless mechanism can not compress all cases. In particular if source and destination have different scope (but is that worth spending bits and code space?) - implementation do not have to compress multicast addresses using method 11 though they have to decompress that method. What do you think? Pascal >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com] >Sent: jeudi 9 octobre 2008 21:01 >To: Julien Abeille (jabeille) >Cc: Pascal Thubert (pthubert); 6lowpan@ietf.org >Subject: Re: hc-01 > > >Hi Julien, > >Your comments are valid. By adding a single bit, I think we can >support all the cases you mention without compromising any of the >cases we currently support. So here is a proposed modification: > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > | X | X | X | X | TF | HLIM |NH | CTX | SAM | M | DAM | > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > >- CTX (context identifier for both source and destination addrs, if >applicable): > - 00: Link-local > - 01: Unspecified Address (valid only for source addr with mcast) > - 10: Global w/ Default > - 11: Global w/ Context Identifier Extension > >- SAM: > - 00: 128-bit > - 01: 64-bit > - 10: 16-bit > - 11: 0-bit > >- M: Multicat > - 0: Unicast Destination > - 1: Multicast Destination > >- DAM: > - When M = 0: > - 00: 128-bit > - 01: 64-bit > - 10: 16-bit > - 11: 0-bit > - When M = 1: > - 00: 128-bit > - 01: 48-bit (FFXX:XXplen::prefix:XXXX:XXXX) > - 10: 48-bit (FF0X::XX:XXXX:XXXX) > - 11: 8-bit (FF02::XX) > >This covers all the multicast cases you care about. It also covers >multicast with a global source address. And it covers all the unicast >formats that we've supported since the beginning (link-local, global >with default context, global with other contexts). Whether or not we >want to support all of the cases you outlined is a question, but given >that it only adds a single bit to the format, I think it's little >added overhead. > >How does that look to you? > >-- >Jonathan Hui > > > >On Oct 9, 2008, at 5:45 AM, Julien Abeille (jabeille) wrote: > >> Hi Pascal, Jonathan, >> >> For addresses I see an issue with a few scenarios: >> - dest multicast, source global non compressable (SAM does not define >> 128 bits format) >> - some dest multicast are not in either of the 4 DAM cases, e.g >> FF3E:0040:aaaa:a:a:a:1:1 (address based on prefix aaaa:a:a:a::/64, >> with >> 32 bit group id = 1:1) >> >> Pascal, can you clarify the DDF = 01 case >> >> I tried to make my ideas clear by listing all current multicast >> scenarios , based on >> http://www.iana.org/assignments/ipv6-multicast-addresses and RFC >> 3306 + >> 3956 (unicast prefix based multicast addresses) >> >> A 128, not compressed >> B FF02::XX 1 byte needed >> C FF0X::00XX:XXXX 4 bytes needed >> D FF0X::00XX:XXXX:XXXX 6 bytes needed >> E unicast prefix based address, not embedding rendez vous point: 5 >> bytes >> needed >> F unicast prefix based address, embedding rendez vous point: 6 bytes >> needed >> >> A covers unicast prefix based multicast addresses with prefix not in >> context >> B covers most useful link local cases (see IANA) e.g. LL all nodes, >> FF02::1 >> C covers longer well known cases (see IANA) e.g. all-dhcp-servers >> FF05::1:3 >> D covers solicited node and node information queries FF02::1:FFXX:XXXX >> and FF02::2:FFXX:XXXX >> E covers format defined in RFC3306, when the prefix used is in the >> default context. >> >> | 8 | 4 | 4 | 8 | 8 | 64 | 32 | >> +--------+----+----+--------+----+----------------+----------+ >> |11111111|flgs|scop|reserved|plen| network prefix | group ID | >> +--------+----+----+--------+----+----------------+----------+ >> Here flags are 0011 (e.g. not embedding rendez vous point, unicast >> prefix based, non permanently assigned) >> We only need to send flags, scope, group ID (5 bytes) >> >> F covers format defined in RFC3956, when the prefix used is in the >> default context. >> >> | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | >> +--------+----+----+----+----+----+----------------+----------+ >> |11111111|flgs|scop|rsvd|RIID|plen| network prefix | group ID | >> +--------+----+----+----+----+----+----------------+----------+ >> Here flags are 0111 (e.g. embedding rendez vous point, unicast prefix >> based, non permanently assigned) >> We only need flags, scope, reserved + RIID, group ID (6bytes) >> >> >> Questions: >> - do we want to support all this? >> - do we want to group some cases: we could group C and D, E and F, >> then >> we have 4 cases only >> - what do we do for dest multicast, source non compressable. >> - Do we keep unspecified support? >> - do we afford one more bit (this would be 7 bits for addresses) and >> use >> dispatch e.g. 1101xxxx? >> - do we keep src and dest encoding linked. For now we have 2 bits >> common >> to src and dest (DDF), plus SAM and DAM. This makes 16 cases for both >> src and dest, 32 in total. >> >> Cheers, >> Julien >> >> >> -----Original Message----- >> From: Jonathan Hui [mailto:jhui@archrock.com] >> Sent: jeudi 9 octobre 2008 01:50 >> To: Pascal Thubert (pthubert) >> Cc: Julien Abeille (jabeille); 6lowpan@ietf.org >> Subject: Re: hc-01 >> >> >> Hi Pascal, >> >> I think this looks great. It covers the cases we care about (unicast >> and >> multicast) without using any extra bits that my initial proposal. >> The small thing I would change is moving the "DDF" field to bits 10-11 >> (shifting TF and NH 2 bits to the left). Then TF would not span a byte >> boundary. >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >> | 0 | 1 | 0 | 0 | 1 | TF |NH | HLIM | DDF | SAM | DAM | >> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >> >> -- >> Jonathan Hui >> >> >> >> On Oct 8, 2008, at 4:31 PM, Pascal Thubert (pthubert) wrote: >> >>> Hi Julien: >>> >>> I think you're right, we need to dig a little bit more. >>> >>> So starting from Jonathan's encoding, maybe we can refine was was CTX >>> >>> >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>> | 0 | 1 | 0 | 0 | 1 | DDF | TF |NH | HLIM | SAM | DAM | >>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>> >>> - Dispatch: 8-15 >>> - DDF: Destination dependant fiels >>> - 00: Destination is global (or ULA), no context byte after the HC >>> field >>> - 01: Destination is global (or ULA), one byte context byte after the >> >>> HC field >>> - 10: Destination is Link local >>> - 11: Destination is multicast scoped address >>> >>> - TF: Traffic Class, Flow Label >>> - 00: 4-bit Pad + Traffic Class + Flow Label (4 bytes) >>> - 01: ECN + 2-bit Pad + Flow Label (3 bytes) >>> - 10: Traffic Class (1 byte) >>> - 11: No Traffic Class and Flow Label >>> >>> - NH: Next Header compression >>> >>> - HLIM: Hop Limit >>> - 00: uncompressed >>> - 01: 1 >>> - 10: 64 >>> - 11: 255 >>> >>> When destination is link local: >>> ------------------------------- >>> prefix is FC80::/64 when compressed >>> >>> - SAM: Source Address Mode - prefix is link-local, when compressed >>> - 00: 128 bits >>> - 01: 64 bits >>> - 10: 16 bits >>> - 11: 0 bits >>> - DAM: Destination Address Mode - prefix is link-local, when >>> compressed >>> - 00: 128 bits >>> - 01: 64 bits >>> - 10: 16 bits >>> - 11: 0 bits >>> >>> When destination is multicast: >>> ------------------------------- >>> prefix is FF02::/64 when compressed >>> >>> - SAM: Source Address Mode >>> - 00: 0 bits, unspecified address >>> - 01: 64 bits, prefix is link local >>> - 10: 16 bits, prefix is link local >>> - 11: 0 bits, derived from the IID, prefix is link local >>> - DAM: Destination Address Mode - prefix is link-local, when >>> compressed >>> - 00: 8 bits, prefix is compressed, suffix is 7 octets of zeroes, >>> then this octet >>> - 01: 24 bits, prefix is compressed, suffix is 4 octets of zeroes, >>> then one octet 0xFF then this octet >>> - 10: 16 bits. 4 bits flags, 4 bits scope, 1 byte suffix. >>> Prefix as defined in RFC 4291, suffix is 7 octets of zeroes, then >>> this >> >>> suffix octet >>> - 11: 24 bits 4 bits flags, 4 bits scope, 2 bytes suffix Prefix as >>> defined in RFC 4291, suffix is 6 octets of zeroes, then those suffix >>> octets >>> >>> When destination is ULA or global: >>> ------------------------------- >>> The prefix is found from the context table. >>> If there is no context octet after the HC field then this is the >>> default prefix. >>> >>> - SAM: Source Address Mode >>> - 00: 128 bits >>> - 01: 64 bits >>> - 10: 16 bits >>> - 11: 0 bits >>> - DAM: Destination Address Mode >>> - 00: 128 bits >>> - 01: 64 bits >>> - 10: 16 bits >>> - 11: 0 bits >>> >>> Notes: >>> >>> With this change, the 16 bits format of Link local and ULA and global >>> really means the last 16 bits ( apposed to 15 in >>> http://tools.ietf.org/html/draft-ietf-6lowpan-hc-00 >>> 2.2. IPv6 Unicast Address Compression. >>> >>> With this change, we have the most useful mcast cases covered: >>> DAM of 00 compresses FF02::XX, so you get all routers on link, etc... >>> DAM of 01 compresses FF02::FFXX:YYZZ, sollicited node mcast address >>> DAM of 10 and 11 compress all permanently-assigned multicast >>> addresses >> >>> defined today for all scopes >>> >>> What do you think? >>> >>> Pascal >>> ________________________________________ >>> From: Julien Abeille (jabeille) >>> Sent: mercredi 8 octobre 2008 17:51 >>> To: Jonathan Hui >>> Cc: Pascal Thubert (pthubert) >>> Subject: hc-01 >>> >>> Hi Jonathan, >>> >>> I send unicast because my thought will not be clear, and to make a >>> quick presentation and bind it to "cisco sensor team". >>> I did my master thesis in 2005 at Cisco in Sophia Antipolis. My >>> project manager was Patrick Wetterwald (IPSO president) and I worked >>> with Pascal on tree discovery and bubbles protocols. I joined Cisco >>> as >> >>> employee in july last year, and have been working on sensors with >>> Patrick as project manager, Pascal and a few others as engineers. I >>> met JP Vasseur a year ago and we have frequent calls and meetings, as >>> he recently moved 150km from switzerland where my office is. I work >>> most closely with Mathilde Durvy whom you met for IPSO interop calls. >>> >>> after discussion with Pascal about address compression, I try to >>> clarify my thoughts: >>> - 64 last bits compression in unicast address compression is only >>> feasible if last 64 bits are based on IID (either 64 bit MAC address >>> or PAN ID+0+16bit address). I thought it would be nice to be able to >>> compress as well addresses with bytes 8 to 13 = 0. (e.g. a::1) >>> - could be nice as well to compress the IID only when the prefix is >>> not compressable? >>> - for multicast address compression, i thought stateless compression >>> could be nice. This works well with permanently assigned addresses >>> (Pascal, the link i promissed: >>> http://www.iana.org/assignments/ipv6-multicast-addresses) >>> , as many bytes are 0 after the two first ones >>> - for multicast again, it would be nice to be able to compress >>> addresses with more than 9-bit non 0 (a few permanently assigned ones >>> apply there, like all-dhcp-agents) >>> - regarding the 16-bit compressed format, i would prefer not having >>> one bit or more in the compressed field with a special meaning (first >>> bit 0 = unicast, 3 first bits 101 = multicast), but keep all these >>> bits in the encoding >>> - I was wondering if assuming flags are 0 cannot be an issue. >>> >>> These are just thoughts, as i am not extremely clear on the important >>> scenarios where we want to compress (e.g. solicited node multicast >>> compression might not be needed as with ND optimizations, there will >>> not be many NS), and am not clear either about multicast addresses >>> except permanently assigned ones. More preciely i do not know if we >>> want to support unicast prefix based multicast addresses or rendez >>> vous point addresses, and what they look like. >>> >>> hope this helps in the discussion, >>> regards, >>> Julien >>> >> _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Oct 10 09:42:20 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB0703A68D4; Fri, 10 Oct 2008 09:42:20 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81E2A3A68AA for <6lowpan@core3.amsl.com>; Fri, 10 Oct 2008 09:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZB4whljrRuZK for <6lowpan@core3.amsl.com>; Fri, 10 Oct 2008 09:42:19 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D12253A68D4 for <6lowpan@ietf.org>; Fri, 10 Oct 2008 09:42:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,390,1220227200"; d="scan'208";a="22291118" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 10 Oct 2008 16:42:40 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9AGgeNQ008666; Fri, 10 Oct 2008 18:42:40 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9AGgeUU016507; Fri, 10 Oct 2008 16:42:40 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Oct 2008 18:42:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 10 Oct 2008 18:41:58 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC065C2E70@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] rfc4944, hc and dispatchs Thread-Index: Ackq8Z9qaELs/j1iRZ2KteTEwXnGvAABT/8w References: <38F26F36EAA981478A49D1F37F474A86020D06DA@xmb-ams-33d.emea.cisco.com> <105175C7-A788-4225-9E5A-845A07AA3621@tzi.org> <7892795E1A87F04CADFCCF41FADD00FC065C29B2@xmb-ams-337.emea.cisco.com> <641900E3-3665-4BED-9FA5-F8FB1667092F@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC065C2E40@xmb-ams-337.emea.cisco.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 10 Oct 2008 16:42:02.0464 (UTC) FILETIME=[1F25F600:01C92AF7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5633; t=1223656960; x=1224520960; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20rfc4944,=20hc=20and=20dispa tchs |Sender:=20; bh=DT2jeWuN0/zY7Vj/osqOYCDIt/sv2fUlIu+ErNsyF5c=; b=AIKtrRku1hXRSD3R6QIuZJeunOk5E102Gk45cEhxx8fxFILe6SNWWWm6QX WVCyww4uJPAPaD2z9h0I0HX6k/htEEmWTRhuLmBRRGZMbz9GRc6qLmO5DtZ5 vk+xgBV26B; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Carsten Bormann , 6lowpan@ietf.org, Geoff Mulligan Subject: Re: [6lowpan] rfc4944, hc and dispatchs X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Jonathan Maybe a good reason to stick to the current format and change the misleading wording around it, what do you think? In any case, I'm all for starting 4944bis and recoverable frags today, though. Pascal >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com] >Sent: vendredi 10 octobre 2008 18:02 >To: Pascal Thubert (pthubert) >Cc: Carsten Bormann; Geoff Mulligan; 6lowpan@ietf.org >Subject: Re: [6lowpan] rfc4944, hc and dispatchs > > >Hi Pascal: > >I'm for pushing HC through as quickly as possible. We are already >behind according to the charter text. > >The one dependency I see is the structure of the dispatch byte. If we >choose a dispatch value(s) that is compatible with RFC 4944, then we >are fine, I think. But if we want extra bits by changing the layout of >the dispatch values/identifiers for Frag/Mesh headers (as both I and >Julien have proposed) then this creates a dependency on defining that >new dispatch assignment scheme. > >-- >Jonathan Hui > > >On Oct 10, 2008, at 8:51 AM, Pascal Thubert (pthubert) wrote: > >> I'm all with you, Jonathan, as long as that does not delay HC. >> >> This is why I proposed a structured set of document that leaves HC >> with >> its current scope as opposed to making it a full revision of 4944. >> Makes >> sense? >> >> Pascal >> >>> -----Original Message----- >>> From: Jonathan Hui [mailto:jhui@archrock.com] >>> Sent: jeudi 9 octobre 2008 21:17 >>> To: Pascal Thubert (pthubert) >>> Cc: Carsten Bormann; Geoff Mulligan; 6lowpan@ietf.org >>> Subject: Re: [6lowpan] rfc4944, hc and dispatchs >>> >>> >>> In general, I'm in support of Pascal's proposal. Cleaning up the >>> format to use a stacked-header format was just one of the items and >>> there were many other things we wanted to fix before pushing out RFC >>> 4944. But we were far too late to the game in doing a complete >>> overhaul of the doc. I think *now* is the time to make improvements >>> to >>> RFC 4944. >>> >>> -- >>> Jonathan Hui >>> >>> >>> >>> On Oct 9, 2008, at 10:41 AM, Pascal Thubert (pthubert) wrote: >>> >>>> Hi Carsten: >>>> >>>> Some implementations and dependant standards would require a >>>> timeline >>>> for this. Leaving it up in the air does not help our users do their >>>> product planning? >>>> >>>> Considering the attention and the work on the new LOWPAN_IPHC, I >>>> expect >>>> that we'll be ready for WGLC after 2/3 more respins. That could be >>>> achieved by Minneapolis time if we can rally all interested parties >> to >>>> comment on the existing published spec. So could you chairs please: >>>> >>>>>>>>>>>>>> propose a time line to the WG along those lines >> <<<<<<<<<<<< >>>>>>>>>>>>>> raise WG attention on this work? >> <<<<<<<<<<<< >>>> >>>> Also by or at Minneapolis, my sensation is that we should not only >>>> discuss the terms of deprecating RFC 4944 HC but also consider the >>>> spec >>>> as a whole: >>>> >>>> - Mesh Header is a layer violation. I talked to implementers and >> their >>>> message is that they do not use it because it's never exactely what >>>> that >>>> specific radio needs; so they end up with their own mesh header >> anyway >>>> and will not duplicate things for the sake of comliance. Instead we >>>> might need a Routing header, pretty useful for source routing in >> route >>>> over. >>>> >>>> - Fragments are not recovered individually. We have enough >>>> experience to >>>> know where that leads should a 6LoWPAN network experience either >>>> high >>>> load or high BER. We have a draft on the works to deprecate that >>>> with >>>> recoverable fragments. >>>> >>>> - The Current HC WG doc covers all the compression cases in RFC >>>> 4944, >>>> bigger and badder. >>>> >>>> So what's left? >>>> >>>> My proposal is to start a 4944bis that would focus on the addressing >>>> architecture, would be the placeholder to control the dispatch type >>>> but >>>> would defer to the drafts/RFCs that actually detail the operation of >>>> each dispatch type. >>>> >>>> What do you think? >>>> >>>> Pascal >>>> >>>>> -----Original Message----- >>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >>>> Behalf Of Carsten Bormann >>>>> Sent: jeudi 9 octobre 2008 16:43 >>>>> To: Julien Abeille (jabeille) >>>>> Cc: Carsten Bormann; 6lowpan@ietf.org >>>>> Subject: Re: [6lowpan] rfc4944, hc and dispatchs >>>>> >>>>> On Oct 09 2008, at 16:09, Julien Abeille (jabeille) wrote: >>>>> >>>>>> - does it officialy deprecate the old header compression scheme? >>>>> >>>>> My impression of the mailing list consensus is that this is what >>>>> the >>>>> WG wants to achieve. >>>>> At the time this was discussed, I cautioned that it is premature to >>>>> decide on replacing something existing with known flaws with >>>>> something >>>>> not yet quite cooked (and, hence, with unknown flaws). >>>>> So I expect we'll ultimately decide this question at the time HC >>>>> and >>>>> the related specs come up for WGLC. >>>>> Clearly, the stated intention of many WG members is to make this >>>>> happen, as it would be wasteful to support two HC schemes in tiny >>>>> implementations. >>>>> >>>>> Gruesse, Carsten >>>>> >>>>> _______________________________________________ >>>>> 6lowpan mailing list >>>>> 6lowpan@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> 6lowpan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowpan >> _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Oct 10 09:51:58 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43A023A68F3; Fri, 10 Oct 2008 09:51:58 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D61143A67B0 for <6lowpan@core3.amsl.com>; Fri, 10 Oct 2008 09:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpTrHqULP5si for <6lowpan@core3.amsl.com>; Fri, 10 Oct 2008 09:51:56 -0700 (PDT) Received: from server1.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id D98E83A68F3 for <6lowpan@ietf.org>; Fri, 10 Oct 2008 09:51:55 -0700 (PDT) Received: from [192.168.174.29] ([207.236.117.244]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id m9AGqfac027698 for <6lowpan@ietf.org>; Fri, 10 Oct 2008 10:52:41 -0600 (MDT) From: Geoff Mulligan To: 6lowpan <6lowpan@ietf.org> Date: Fri, 10 Oct 2008 10:52:30 -0600 Message-Id: <1223657550.32120.31.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: [6lowpan] Use Case document X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org A week++ ago I asked what people thought about the Use Case draft and if it is ready to become a WG draft. We have had a few responses and most all of them positive with a few comments, typos and such that can be fixed. Eunsook can you please fix the typos and other changes identified and submit the draft as a WG draft. We look forward to completing this document. geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Oct 10 10:01:46 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98A533A68F3; Fri, 10 Oct 2008 10:01:46 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8024D3A676A for <6lowpan@core3.amsl.com>; Fri, 10 Oct 2008 10:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoNncrkNnyff for <6lowpan@core3.amsl.com>; Fri, 10 Oct 2008 10:01:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A94983A63D2 for <6lowpan@ietf.org>; Fri, 10 Oct 2008 10:01:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,390,1220227200"; d="scan'208";a="22292529" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 10 Oct 2008 17:02:28 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9AH2SZX012847; Fri, 10 Oct 2008 19:02:28 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9AH2S17020189; Fri, 10 Oct 2008 17:02:28 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Oct 2008 19:02:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 10 Oct 2008 19:02:27 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC065C2E85@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fwd: New Version Notification fordraft-ietf-6lowpan-hc-01 Thread-Index: Ackq8vlfJ4iFVGZWQnCx3gaMuvxixwABDQxQ References: <20081009021535.C8E823A6959@core3.amsl.com><48EF5170.7050107@sensinode.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "Zach Shelby" X-OriginalArrivalTime: 10 Oct 2008 17:02:28.0362 (UTC) FILETIME=[F9D726A0:01C92AF9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5577; t=1223658148; x=1224522148; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20Fwd=3A=20New=20Version=20No tification=20fordraft-ietf-6lowpan-hc-01 |Sender:=20; bh=GM9+819Ty55wvgeQ7UrfdtYPWEgODker1M99GPBfsgA=; b=iasr8FgOEHN0MMjVEK0TpovTIJAx0Gb/TzTGsMlLsRRhipU384szFuwYpv siBmUcT8thr3ZmXuZoUh2x+8ebJoyIXF8IAu8ePpV3iHz4Bw1tjM4fIYVK3f tbjE601sAL; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fwd: New Version Notification fordraft-ietf-6lowpan-hc-01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Jonathan and Zach; That's again my bad wording I guess; We can have up to 16 contexts both directions. Does not mean that all deployments will use 16 context. For a given deployment, there might be 3 of each. In that deployment, all nodes are required to allocate memory for 3. Some nodes might be physically incapable to join a network that requires more contexts than they can allocate. Is that acceptable? I like Zach's proposal to make the additional context fully optional (for nodes not routers). But then, the source must know that the destination does not support it, and we need to describe that. Then again, I see that the spec needs edition to be clearer but not a change in the formats. What do you think? Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Jonathan Hui >Sent: vendredi 10 octobre 2008 18:11 >To: Zach Shelby >Cc: 6lowpan >Subject: Re: [6lowpan] Fwd: New Version Notification fordraft-ietf-6lowpan-hc-01 > > >Hi Zach, > >On Oct 10, 2008, at 5:58 AM, Zach Shelby wrote: >> Here are my comments on hc-01. Overall I think we are quite close >> with the comments from Pascal and Julien. >> >> I found the DDF name confusing. Now it has been renamed CTX in the >> latest formats on the list, great. >> >> As Pascal pointed out, nodes need to be able to decode all these >> options. One thing that worries me in having 16 contexts, is that >> nodes are forced to store them all. That is worst case 272 bytes of >> memory consumption. Worth it? Is it possible that an ultra-simple >> node would only have to understand the default context? > >[jhui] The number of contexts is an issue I raised on the list a few >weeks ago. Many seemed to think that two contexts was okay. However, I >wanted us to be sure that 2 was enough and as a result there was no >change in the number of contexts from hc-00 to hc-01. With an extra >bit (13 bits total) we can certainly support 2 contexts without a >context identifier extension. With two extra bits (14 bits) we can >support 3 contexts. Any more would require an extra byte, I think. Of >course, we can stick with the current encoding but we can limit use to >X < 16 contexts. What do people think? > >> The default context identifier '0000' could be clarified more in the >> draft. When CTX is '10' then the default context identifier '0000' >> is used. It should be made clear that this is the prefix advertised >> in RAs as useable for SAA. >> >> >> Regarding the ND for 6lowpan draft, HC-01 means we need to add a 4- >> bit context identifier flag to the 6LoWPAN Prefix Information >> Option. To make things clear that should always be '0000' if the A >> flag is '1'? > >[jhui] Those that are arguing for more than 2 contexts see it useful >for renumbering. If that is the case, then SAA must have the >flexibility for use with contexts other than the default. For now, I >think it's best to consider having a context identifier included with >the 6LoWPAN Prefix Information Option. > >-- >Jonathan Hui > >> >> >> - Zach >> >> >> Jonathan Hui wrote: >>> http://tools.ietf.org/html/draft-ietf-6lowpan-hc >>> This new version reflects the recent discussions on the list. The >>> changes are: >>> - HC back to 1 byte by default by stealing a few bits from the >>> dispatch field. >>> - Added better support for multicast address compression. >>> - Fixed alignment for UDP port compression. >>> - Better support for Traffic Class and Flow Label compression. >>> - Pascal joined as an author. >>> Happy reading! >>> -- >>> Jonathan Hui >>> Begin forwarded message: >>>> From: IETF I-D Submission Tool >>>> Date: October 8, 2008 7:15:35 PM PDT >>>> To: jhui@archrock.com >>>> Cc: pthubert@cisco.com >>>> Subject: New Version Notification for draft-ietf-6lowpan-hc-01 >>>> >>>> >>>> A new version of I-D, draft-ietf-6lowpan-hc-01.txt has been >>>> successfuly submitted by Jonathan Hui and posted to the IETF >>>> repository. >>>> >>>> Filename: draft-ietf-6lowpan-hc >>>> Revision: 01 >>>> Title: Compression Format for IPv6 Datagrams in 6LoWPAN >>>> Networks >>>> Creation_date: 2008-10-09 >>>> WG ID: 6lowpan >>>> Number_of_pages: 15 >>>> >>>> Abstract: >>>> This document specifies an IPv6 header compression format for IPv6 >>>> packet delivery in 6LoWPAN networks. The compression format relies >>>> on shared context to allow compression of arbitrary prefixes. This >>>> document specifies compression of multicast addresses and a >>>> framework >>>> for compressing next headers. This framework specifies UDP >>>> compression and is prepared for additional transports. >>>> >>>> >>>> >>>> The IETF Secretariat. >>>> >>>> >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >> >> -- >> >> Zach Shelby >> Head of Research >> Sensinode Ltd. >> Kidekuja 2 >> 88610 Vuokatti >> FINLAND >> >> mobile: +358 40 7796297 >> >> This e-mail and all attached material are confidential and may >> contain legally privileged information. If you are not the intended >> recipient, please contact the sender and delete the e-mail from your >> system without producing, distributing or retaining copies thereof. > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Oct 10 10:07:56 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A88513A6A64; Fri, 10 Oct 2008 10:07:56 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A84A33A6A64 for <6lowpan@core3.amsl.com>; Fri, 10 Oct 2008 10:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBEFGNpRq6Tc for <6lowpan@core3.amsl.com>; Fri, 10 Oct 2008 10:07:54 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 80E073A6A42 for <6lowpan@ietf.org>; Fri, 10 Oct 2008 10:07:54 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 74157AF8BA; Fri, 10 Oct 2008 10:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8w49MAfdpqW; Fri, 10 Oct 2008 10:08:40 -0700 (PDT) Received: from [192.168.7.78] (69-12-164-140.sfo.archrock.com [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id EFB34AF8B7; Fri, 10 Oct 2008 10:08:38 -0700 (PDT) Message-Id: From: Jonathan Hui To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC065C2E70@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 10 Oct 2008 10:08:37 -0700 References: <38F26F36EAA981478A49D1F37F474A86020D06DA@xmb-ams-33d.emea.cisco.com> <105175C7-A788-4225-9E5A-845A07AA3621@tzi.org> <7892795E1A87F04CADFCCF41FADD00FC065C29B2@xmb-ams-337.emea.cisco.com> <641900E3-3665-4BED-9FA5-F8FB1667092F@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC065C2E40@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC065C2E70@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: Carsten Bormann , 6lowpan@ietf.org, Geoff Mulligan Subject: Re: [6lowpan] rfc4944, hc and dispatchs X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Pascal, Yes, you are right - hc-01 supports all header values (just carry everything in-line). Regarding Julien's comments, I think hc-01 and the format proposed to support Julien's cases are straight-forward to implement. I think the more important issue is whether Julien's cases will be common in 6LoWPAN applications. We (Arch Rock) do not commonly use the cases that Julien wishes to add compression for. But if Julien/others can demonstrate a strong need for them (i.e. cases that will be used fairly often in relevant 6LoWPAN applications), then I do think we should consider them. Julien, can you explain important commonly used cases that would not be supported by hc-01? -- Jonathan Hui On Oct 10, 2008, at 9:41 AM, Pascal Thubert (pthubert) wrote: > Hi Jonathan > > Maybe a good reason to stick to the current format and change the > misleading wording around it, what do you think? In any case, I'm all > for starting 4944bis and recoverable frags today, though. > > Pascal > >> -----Original Message----- >> From: Jonathan Hui [mailto:jhui@archrock.com] >> Sent: vendredi 10 octobre 2008 18:02 >> To: Pascal Thubert (pthubert) >> Cc: Carsten Bormann; Geoff Mulligan; 6lowpan@ietf.org >> Subject: Re: [6lowpan] rfc4944, hc and dispatchs >> >> >> Hi Pascal: >> >> I'm for pushing HC through as quickly as possible. We are already >> behind according to the charter text. >> >> The one dependency I see is the structure of the dispatch byte. If we >> choose a dispatch value(s) that is compatible with RFC 4944, then we >> are fine, I think. But if we want extra bits by changing the layout >> of >> the dispatch values/identifiers for Frag/Mesh headers (as both I and >> Julien have proposed) then this creates a dependency on defining that >> new dispatch assignment scheme. >> >> -- >> Jonathan Hui >> >> >> On Oct 10, 2008, at 8:51 AM, Pascal Thubert (pthubert) wrote: >> >>> I'm all with you, Jonathan, as long as that does not delay HC. >>> >>> This is why I proposed a structured set of document that leaves HC >>> with >>> its current scope as opposed to making it a full revision of 4944. >>> Makes >>> sense? >>> >>> Pascal >>> >>>> -----Original Message----- >>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>> Sent: jeudi 9 octobre 2008 21:17 >>>> To: Pascal Thubert (pthubert) >>>> Cc: Carsten Bormann; Geoff Mulligan; 6lowpan@ietf.org >>>> Subject: Re: [6lowpan] rfc4944, hc and dispatchs >>>> >>>> >>>> In general, I'm in support of Pascal's proposal. Cleaning up the >>>> format to use a stacked-header format was just one of the items and >>>> there were many other things we wanted to fix before pushing out >>>> RFC >>>> 4944. But we were far too late to the game in doing a complete >>>> overhaul of the doc. I think *now* is the time to make improvements >>>> to >>>> RFC 4944. >>>> >>>> -- >>>> Jonathan Hui >>>> >>>> >>>> >>>> On Oct 9, 2008, at 10:41 AM, Pascal Thubert (pthubert) wrote: >>>> >>>>> Hi Carsten: >>>>> >>>>> Some implementations and dependant standards would require a >>>>> timeline >>>>> for this. Leaving it up in the air does not help our users do >>>>> their >>>>> product planning? >>>>> >>>>> Considering the attention and the work on the new LOWPAN_IPHC, I >>>>> expect >>>>> that we'll be ready for WGLC after 2/3 more respins. That could be >>>>> achieved by Minneapolis time if we can rally all interested >>>>> parties >>> to >>>>> comment on the existing published spec. So could you chairs >>>>> please: >>>>> >>>>>>>>>>>>>>> propose a time line to the WG along those lines >>> <<<<<<<<<<<< >>>>>>>>>>>>>>> raise WG attention on this work? >>> <<<<<<<<<<<< >>>>> >>>>> Also by or at Minneapolis, my sensation is that we should not only >>>>> discuss the terms of deprecating RFC 4944 HC but also consider the >>>>> spec >>>>> as a whole: >>>>> >>>>> - Mesh Header is a layer violation. I talked to implementers and >>> their >>>>> message is that they do not use it because it's never exactely >>>>> what >>>>> that >>>>> specific radio needs; so they end up with their own mesh header >>> anyway >>>>> and will not duplicate things for the sake of comliance. Instead >>>>> we >>>>> might need a Routing header, pretty useful for source routing in >>> route >>>>> over. >>>>> >>>>> - Fragments are not recovered individually. We have enough >>>>> experience to >>>>> know where that leads should a 6LoWPAN network experience either >>>>> high >>>>> load or high BER. We have a draft on the works to deprecate that >>>>> with >>>>> recoverable fragments. >>>>> >>>>> - The Current HC WG doc covers all the compression cases in RFC >>>>> 4944, >>>>> bigger and badder. >>>>> >>>>> So what's left? >>>>> >>>>> My proposal is to start a 4944bis that would focus on the > addressing >>>>> architecture, would be the placeholder to control the dispatch >>>>> type >>>>> but >>>>> would defer to the drafts/RFCs that actually detail the operation > of >>>>> each dispatch type. >>>>> >>>>> What do you think? >>>>> >>>>> Pascal >>>>> >>>>>> -----Original Message----- >>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] > On >>>>> Behalf Of Carsten Bormann >>>>>> Sent: jeudi 9 octobre 2008 16:43 >>>>>> To: Julien Abeille (jabeille) >>>>>> Cc: Carsten Bormann; 6lowpan@ietf.org >>>>>> Subject: Re: [6lowpan] rfc4944, hc and dispatchs >>>>>> >>>>>> On Oct 09 2008, at 16:09, Julien Abeille (jabeille) wrote: >>>>>> >>>>>>> - does it officialy deprecate the old header compression scheme? >>>>>> >>>>>> My impression of the mailing list consensus is that this is what >>>>>> the >>>>>> WG wants to achieve. >>>>>> At the time this was discussed, I cautioned that it is premature > to >>>>>> decide on replacing something existing with known flaws with >>>>>> something >>>>>> not yet quite cooked (and, hence, with unknown flaws). >>>>>> So I expect we'll ultimately decide this question at the time HC >>>>>> and >>>>>> the related specs come up for WGLC. >>>>>> Clearly, the stated intention of many WG members is to make this >>>>>> happen, as it would be wasteful to support two HC schemes in tiny >>>>>> implementations. >>>>>> >>>>>> Gruesse, Carsten >>>>>> >>>>>> _______________________________________________ >>>>>> 6lowpan mailing list >>>>>> 6lowpan@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>> _______________________________________________ >>>>> 6lowpan mailing list >>>>> 6lowpan@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>> > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Oct 10 10:26:37 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DCCD3A67A2; Fri, 10 Oct 2008 10:26:37 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B5593A67D4 for <6lowpan@core3.amsl.com>; Fri, 10 Oct 2008 10:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3FpfsNCzu3y for <6lowpan@core3.amsl.com>; Fri, 10 Oct 2008 10:26:35 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 906AA3A635F for <6lowpan@ietf.org>; Fri, 10 Oct 2008 10:26:35 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id AB3F6AF8BA; Fri, 10 Oct 2008 10:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPN37fVn-g50; Fri, 10 Oct 2008 10:27:22 -0700 (PDT) Received: from [192.168.7.78] (69-12-164-140.sfo.archrock.com [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id B4BA2AF86C; Fri, 10 Oct 2008 10:27:21 -0700 (PDT) Message-Id: <09868BF5-3657-40C7-B4F3-F2521031114D@archrock.com> From: Jonathan Hui To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC065C2E85@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 10 Oct 2008 10:27:20 -0700 References: <20081009021535.C8E823A6959@core3.amsl.com><48EF5170.7050107@sensinode.com> <7892795E1A87F04CADFCCF41FADD00FC065C2E85@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fwd: New Version Notification fordraft-ietf-6lowpan-hc-01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Pascal: On Oct 10, 2008, at 10:02 AM, Pascal Thubert (pthubert) wrote: > That's again my bad wording I guess; We can have up to 16 contexts > both > directions. Does not mean that all deployments will use 16 context. > For > a given deployment, there might be 3 of each. In that deployment, all > nodes are required to allocate memory for 3. Some nodes might be > physically incapable to join a network that requires more contexts > than > they can allocate. > > Is that acceptable? [jhui] My initial inclination is that this would be a bad idea for the market in general. Doing this would essentially create nodes (specifically, routers in a route-over configuration) that have different capability levels and nodes that are less capable will not be able to join those that use extra capabilities. However, it does offer more flexibility to implementors on the kinds of networks they want to support. WiFi had it easy because APs and clients are in direct contact with each other. > I like Zach's proposal to make the additional context fully optional > (for nodes not routers). But then, the source must know that the > destination does not support it, and we need to describe that. [jhui] I think this is workable (more so in a mesh-under configuration than a route-over one). The definition of "source" could be a bit loose - essentially a node along the path could reformat the header to something consumable by the destination. > Then again, I see that the spec needs edition to be clearer but not a > change in the formats. What do you think? [jhui] Agree. -- JOnathan Hui > > > Pascal > >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Jonathan Hui >> Sent: vendredi 10 octobre 2008 18:11 >> To: Zach Shelby >> Cc: 6lowpan >> Subject: Re: [6lowpan] Fwd: New Version Notification > fordraft-ietf-6lowpan-hc-01 >> >> >> Hi Zach, >> >> On Oct 10, 2008, at 5:58 AM, Zach Shelby wrote: >>> Here are my comments on hc-01. Overall I think we are quite close >>> with the comments from Pascal and Julien. >>> >>> I found the DDF name confusing. Now it has been renamed CTX in the >>> latest formats on the list, great. >>> >>> As Pascal pointed out, nodes need to be able to decode all these >>> options. One thing that worries me in having 16 contexts, is that >>> nodes are forced to store them all. That is worst case 272 bytes of >>> memory consumption. Worth it? Is it possible that an ultra-simple >>> node would only have to understand the default context? >> >> [jhui] The number of contexts is an issue I raised on the list a few >> weeks ago. Many seemed to think that two contexts was okay. >> However, I >> wanted us to be sure that 2 was enough and as a result there was no >> change in the number of contexts from hc-00 to hc-01. With an extra >> bit (13 bits total) we can certainly support 2 contexts without a >> context identifier extension. With two extra bits (14 bits) we can >> support 3 contexts. Any more would require an extra byte, I think. Of >> course, we can stick with the current encoding but we can limit use >> to >> X < 16 contexts. What do people think? >> >>> The default context identifier '0000' could be clarified more in the >>> draft. When CTX is '10' then the default context identifier '0000' >>> is used. It should be made clear that this is the prefix advertised >>> in RAs as useable for SAA. >>> >>> >>> Regarding the ND for 6lowpan draft, HC-01 means we need to add a 4- >>> bit context identifier flag to the 6LoWPAN Prefix Information >>> Option. To make things clear that should always be '0000' if the A >>> flag is '1'? >> >> [jhui] Those that are arguing for more than 2 contexts see it useful >> for renumbering. If that is the case, then SAA must have the >> flexibility for use with contexts other than the default. For now, I >> think it's best to consider having a context identifier included with >> the 6LoWPAN Prefix Information Option. >> >> -- >> Jonathan Hui >> >>> >>> >>> - Zach >>> >>> >>> Jonathan Hui wrote: >>>> http://tools.ietf.org/html/draft-ietf-6lowpan-hc >>>> This new version reflects the recent discussions on the list. The >>>> changes are: >>>> - HC back to 1 byte by default by stealing a few bits from the >>>> dispatch field. >>>> - Added better support for multicast address compression. >>>> - Fixed alignment for UDP port compression. >>>> - Better support for Traffic Class and Flow Label compression. >>>> - Pascal joined as an author. >>>> Happy reading! >>>> -- >>>> Jonathan Hui >>>> Begin forwarded message: >>>>> From: IETF I-D Submission Tool >>>>> Date: October 8, 2008 7:15:35 PM PDT >>>>> To: jhui@archrock.com >>>>> Cc: pthubert@cisco.com >>>>> Subject: New Version Notification for draft-ietf-6lowpan-hc-01 >>>>> >>>>> >>>>> A new version of I-D, draft-ietf-6lowpan-hc-01.txt has been >>>>> successfuly submitted by Jonathan Hui and posted to the IETF >>>>> repository. >>>>> >>>>> Filename: draft-ietf-6lowpan-hc >>>>> Revision: 01 >>>>> Title: Compression Format for IPv6 Datagrams in 6LoWPAN >>>>> Networks >>>>> Creation_date: 2008-10-09 >>>>> WG ID: 6lowpan >>>>> Number_of_pages: 15 >>>>> >>>>> Abstract: >>>>> This document specifies an IPv6 header compression format for IPv6 >>>>> packet delivery in 6LoWPAN networks. The compression format >>>>> relies >>>>> on shared context to allow compression of arbitrary prefixes. >>>>> This >>>>> document specifies compression of multicast addresses and a >>>>> framework >>>>> for compressing next headers. This framework specifies UDP >>>>> compression and is prepared for additional transports. >>>>> >>>>> >>>>> >>>>> The IETF Secretariat. >>>>> >>>>> >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> 6lowpan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>> >>> -- >>> >>> Zach Shelby >>> Head of Research >>> Sensinode Ltd. >>> Kidekuja 2 >>> 88610 Vuokatti >>> FINLAND >>> >>> mobile: +358 40 7796297 >>> >>> This e-mail and all attached material are confidential and may >>> contain legally privileged information. If you are not the intended >>> recipient, please contact the sender and delete the e-mail from your >>> system without producing, distributing or retaining copies thereof. >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Oct 10 10:52:13 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E52353A697B; Fri, 10 Oct 2008 10:52:13 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 750A13A676A for <6lowpan@core3.amsl.com>; Fri, 10 Oct 2008 10:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ej5eqquY258P for <6lowpan@core3.amsl.com>; Fri, 10 Oct 2008 10:52:07 -0700 (PDT) Received: from mailhost.jennic.co.uk (proxy.jennic.co.uk [213.143.5.74]) by core3.amsl.com (Postfix) with ESMTP id E4B483A697B for <6lowpan@ietf.org>; Fri, 10 Oct 2008 10:52:06 -0700 (PDT) Received: from jenpc629.jennic.com ([10.99.97.208]) by jendns02.jennic.com with esmtpa (Exim 4.60) (envelope-from ) id 1KoMAU-0002gB-4m; Fri, 10 Oct 2008 18:52:50 +0100 Message-ID: <48EF9672.6020502@jennic.com> Date: Fri, 10 Oct 2008 18:52:50 +0100 From: Robert Cragie User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Kris Pister References: <48EE9D0D.9080707@eecs.berkeley.edu> In-Reply-To: <48EE9D0D.9080707@eecs.berkeley.edu> Cc: 6lowpan@ietf.org, David Culler Subject: Re: [6lowpan] I-D of interest to this list - Zigbee Application Protocol over UDP/IP, including 6LoPWAN X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1285688563==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --===============1285688563== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Kris,

Some points to consider here. I should add these are my personal views and do not necessarily represent the official views of the ZigBee Alliance.

1) It is easy to write a specification. Taking a specification, developing and refining it and getting a large number of real-world implementers to join together in an alliance to develop and test products based on the specification to produce stable, interoperable products, in conjunction with a concerted marketing activity to promote such work is a huge undertaking and should not be underestimated.

2) The fact that this draft has been developed suggests that value is seen in the work done by the ZigBee Alliance to develop the application profiles.

3) There are a number of potential models to enable IP connectivity in low power wireless networks, each with their advantages and disadvantages, which in turn present their own suitability to low power wireless networks with distinct properties. Ideally a technology which can support all models would be developed. The ZigBee Alliance recognises this and has an IP connectivity task group to look at these models.

4) There is a strong and ever growing demand for low power wireless networks in a number of key markets, for example, what is generally known as the 'Smart Grid'. Products using ZigBee’s Smart Energy profile have been selected by a large number of utilities to provide intelligent wireless Demand and Response and Energy Management solutions. I don't think anyone would disagree that we would all benefit from collaboration between the ongoing efforts to produce technology which is prolific and usable.

So I personally welcome this input and look upon it as a vindication that there is a desire to converge efforts for the benefit of the technology as a whole.

Robert Cragie,

Chair, IP Connectivity Task Group, ZigBee Alliance

-- 
Robert Cragie, Design Engineer
_______________________________________________________________
Jennic Ltd, Furnival Street, Sheffield, S1 4QT,  UK
http://www.jennic.com  Tel: +44 (0) 114 281 2655
_______________________________________________________________

Kris Pister wrote:
Nice.  The beginning of the end for the Zigbee network stack.  Few will mourn it's passing.

ksjp

David Culler wrote: 

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
  

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
  

-- 
Robert Cragie, Design Engineer

Direct: +44 (0) 114 281 4512
_______________________________________________________________
Jennic Ltd, Furnival Street, Sheffield, S1 4QT,  UK
http://www.jennic.com  Tel: +44 (0) 114 281 2655   Confidential
_______________________________________________________________
--===============1285688563== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan --===============1285688563==-- From 6lowpan-bounces@ietf.org Sat Oct 11 10:29:49 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57E483A6B38; Sat, 11 Oct 2008 10:29:49 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C95E53A6B19 for <6lowpan@core3.amsl.com>; Sat, 11 Oct 2008 10:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qqpsmzo7nkCN for <6lowpan@core3.amsl.com>; Sat, 11 Oct 2008 10:29:46 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 574983A6988 for <6lowpan@ietf.org>; Sat, 11 Oct 2008 10:29:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,394,1220227200"; d="scan'208";a="22335260" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 11 Oct 2008 17:30:34 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m9BHUYWP016356; Sat, 11 Oct 2008 19:30:34 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9BHUYCG005802; Sat, 11 Oct 2008 17:30:34 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Oct 2008 19:30:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 11 Oct 2008 19:30:29 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC065C2F55@xmb-ams-337.emea.cisco.com> In-Reply-To: <1223596248.7321.33.camel@dellx1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] HC-01 draft Thread-Index: Ackqag8JyFNH8QjfQCShNylTanTiDABWIxaQ References: <1223596248.7321.33.camel@dellx1> From: "Pascal Thubert (pthubert)" To: "Geoff Mulligan" X-OriginalArrivalTime: 11 Oct 2008 17:30:34.0602 (UTC) FILETIME=[1154B4A0:01C92BC7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2599; t=1223746234; x=1224610234; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20HC-01=20draft |Sender:=20; bh=xSQwzLNfZqKg+DejPz9bDf3y+vaXxLgEbqZf95O/g6k=; b=T8cJ4dD33y7fAxZDUU6ei4pDJD2YlewRoPsZA1uOFOQVNYAUnH5G6UrdwB 3tA+gyMZnvFruqGF1yjBvBeQerCJactY1kBy39zJAsH/l92ejN/Xo8VGoBLh DYdjzlPhzE; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] HC-01 draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Geoff: Thanks for your help here. We certainly need some from all the WG at this point. This draft is a trade off between: - compression coverage - ease/size of code - size of the dispatch/hc As Julien commented in the list, we do not compress all types of multicast addresses, and only compress matching scopes between source and destination as follows: - Global/ULA <--> Global/ULA - Link local <--> Link local - Link local --> Multicast - unspecified --> Multicast Also use 4 methods of compression: - Stateful with 16 contexts - Stateless based on MAC header - Stateless based on well-known prefix (link local, default global) - Stateless based on well-known patterns (multicast, zeroed out suffix header) Zach mentioned in the list that the stateful method might be too expensive for some devices out there. In fact, the draft needs to clarify which methods: - MAY/SHOULD/MUST be supported for encoding - MAY/SHOULD/MUST be supported for decoding. The more cases we support, the more bits are required in the frame to describe the encoding and the more code is necessary to encode/decode; so we picked a trade-off based on existing experience. Clearly we need more feedback from this group to feel whether the trade off is acceptable or should be tuned, in particular from the angles of: - ease of implementation. Are complexity and code size acceptable? - coverage. Need more? Too much already? - Make stateful compression 16 contexts a MAY? Make --> Multicast a MAY or a SHOULD ? Please provide your thoughts along these line on the list. Time is running out. Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Geoff Mulligan >Sent: vendredi 10 octobre 2008 01:51 >To: 6lowpan >Subject: [6lowpan] HC-01 draft > >Folks, > The draft of the new HC format has been published as a WG document: >http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-hc-01.txt > >There has been some good discussion around this, but would everyone take >up that task to read and review the current draft and provide feedback. > >Jonathan do you already have updates for the draft or is -01 the most >current thoughts? > >So that we can close on this document sooner rather than later I am >going to continue to bug the group to deal with this document. > >Please read it now and send comments to the list. > > geoff > > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 13 01:13:54 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 907473A681B; Mon, 13 Oct 2008 01:13:54 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D48903A681B for <6lowpan@core3.amsl.com>; Mon, 13 Oct 2008 01:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.345 X-Spam-Level: X-Spam-Status: No, score=-6.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sGr-L0YgbtU for <6lowpan@core3.amsl.com>; Mon, 13 Oct 2008 01:13:52 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id F18133A659B for <6lowpan@ietf.org>; Mon, 13 Oct 2008 01:13:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,401,1220227200"; d="scan'208";a="22398356" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 13 Oct 2008 08:13:56 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9D8DuOJ007609; Mon, 13 Oct 2008 10:13:56 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9D8DuEx014055; Mon, 13 Oct 2008 08:13:56 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Oct 2008 10:13:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 13 Oct 2008 10:13:55 +0200 Message-ID: <38F26F36EAA981478A49D1F37F474A8602115D1F@xmb-ams-33d.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] rfc4944, hc and dispatchs Thread-Index: Ackq+ugV/DiDB1qsSoKk/BI6in6LxQCDoBog References: <38F26F36EAA981478A49D1F37F474A86020D06DA@xmb-ams-33d.emea.cisco.com><105175C7-A788-4225-9E5A-845A07AA3621@tzi.org><7892795E1A87F04CADFCCF41FADD00FC065C29B2@xmb-ams-337.emea.cisco.com><641900E3-3665-4BED-9FA5-F8FB1667092F@archrock.com><7892795E1A87F04CADFCCF41FADD00FC065C2E40@xmb-ams-337.emea.cisco.com><7892795E1A87F04CADFCCF41FADD00FC065C2E70@xmb-ams-337.emea.cisco.com> From: "Julien Abeille (jabeille)" To: "Jonathan Hui" , "Pascal Thubert (pthubert)" , "Carsten Bormann" , <6lowpan@ietf.org>, "Geoff Mulligan" X-OriginalArrivalTime: 13 Oct 2008 08:13:56.0661 (UTC) FILETIME=[A36ED650:01C92D0B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8248; t=1223885636; x=1224749636; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20RE=3A=20[6lowpan]=20rfc4944,=20hc=20and=20dispa tchs |Sender:=20; bh=/54SrUY+E7p83SynKfmj4E9rPPjP11MfSb0y3GZblH0=; b=GI6AY9Wjw4svojK2qHwn1qjDUL59z0exQI3P+mnNUhmL7ORAuwKG0Tmfiz zVjkqmdxXOuWEqRTLbJRXQcGAqqG3jPUOHODCZK+3koU9CBR+mYNEzb8dnns vQa94VjeWd; Authentication-Results: ams-dkim-1; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [6lowpan] rfc4944, hc and dispatchs X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Jonathan , all, I do not have particular use cases in mind for specific address types. My approach is the following: - how many bits can we afford? - with this amount of bits, let's try to support as many IP scenarios as possible, keeping a low level of complexity and a high level of clarity. For the first question: - there are currently around 150/255 dispatch values used. - A priori I would be in favor of deprecating some (mesh, not a lowpan frame), or at least do you agree they are less important than HC. This would drag the number of values to 25/255 - I do foresee some new 6lowpan specs will take some of them, but not that many. Do you see anything else appart from fragment recovery? Hence I am convinced taking 32 values is very acceptable (this is 8 bits for address compression) Do you agree with this? For the second question: - with 8 bits for address compression, we can do something very clean and easy to implement, handling all IP addressing scenarios. I will send today an example on 8bits and pseudo code to be able to compare 7-bit/8-bit complexity Regards, Julien -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Jonathan Hui Sent: vendredi 10 octobre 2008 19:09 To: Pascal Thubert (pthubert) Cc: Carsten Bormann; 6lowpan@ietf.org; Geoff Mulligan Subject: Re: [6lowpan] rfc4944, hc and dispatchs Hi Pascal, Yes, you are right - hc-01 supports all header values (just carry everything in-line). Regarding Julien's comments, I think hc-01 and the format proposed to support Julien's cases are straight-forward to implement. I think the more important issue is whether Julien's cases will be common in 6LoWPAN applications. We (Arch Rock) do not commonly use the cases that Julien wishes to add compression for. But if Julien/others can demonstrate a strong need for them (i.e. cases that will be used fairly often in relevant 6LoWPAN applications), then I do think we should consider them. Julien, can you explain important commonly used cases that would not be supported by hc-01? -- Jonathan Hui On Oct 10, 2008, at 9:41 AM, Pascal Thubert (pthubert) wrote: > Hi Jonathan > > Maybe a good reason to stick to the current format and change the > misleading wording around it, what do you think? In any case, I'm all > for starting 4944bis and recoverable frags today, though. > > Pascal > >> -----Original Message----- >> From: Jonathan Hui [mailto:jhui@archrock.com] >> Sent: vendredi 10 octobre 2008 18:02 >> To: Pascal Thubert (pthubert) >> Cc: Carsten Bormann; Geoff Mulligan; 6lowpan@ietf.org >> Subject: Re: [6lowpan] rfc4944, hc and dispatchs >> >> >> Hi Pascal: >> >> I'm for pushing HC through as quickly as possible. We are already >> behind according to the charter text. >> >> The one dependency I see is the structure of the dispatch byte. If we >> choose a dispatch value(s) that is compatible with RFC 4944, then we >> are fine, I think. But if we want extra bits by changing the layout >> of the dispatch values/identifiers for Frag/Mesh headers (as both I >> and Julien have proposed) then this creates a dependency on defining >> that new dispatch assignment scheme. >> >> -- >> Jonathan Hui >> >> >> On Oct 10, 2008, at 8:51 AM, Pascal Thubert (pthubert) wrote: >> >>> I'm all with you, Jonathan, as long as that does not delay HC. >>> >>> This is why I proposed a structured set of document that leaves HC >>> with its current scope as opposed to making it a full revision of >>> 4944. >>> Makes >>> sense? >>> >>> Pascal >>> >>>> -----Original Message----- >>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>> Sent: jeudi 9 octobre 2008 21:17 >>>> To: Pascal Thubert (pthubert) >>>> Cc: Carsten Bormann; Geoff Mulligan; 6lowpan@ietf.org >>>> Subject: Re: [6lowpan] rfc4944, hc and dispatchs >>>> >>>> >>>> In general, I'm in support of Pascal's proposal. Cleaning up the >>>> format to use a stacked-header format was just one of the items and >>>> there were many other things we wanted to fix before pushing out >>>> RFC 4944. But we were far too late to the game in doing a complete >>>> overhaul of the doc. I think *now* is the time to make improvements >>>> to RFC 4944. >>>> >>>> -- >>>> Jonathan Hui >>>> >>>> >>>> >>>> On Oct 9, 2008, at 10:41 AM, Pascal Thubert (pthubert) wrote: >>>> >>>>> Hi Carsten: >>>>> >>>>> Some implementations and dependant standards would require a >>>>> timeline for this. Leaving it up in the air does not help our >>>>> users do their product planning? >>>>> >>>>> Considering the attention and the work on the new LOWPAN_IPHC, I >>>>> expect that we'll be ready for WGLC after 2/3 more respins. That >>>>> could be achieved by Minneapolis time if we can rally all >>>>> interested parties >>> to >>>>> comment on the existing published spec. So could you chairs >>>>> please: >>>>> >>>>>>>>>>>>>>> propose a time line to the WG along those lines >>> <<<<<<<<<<<< >>>>>>>>>>>>>>> raise WG attention on this work? >>> <<<<<<<<<<<< >>>>> >>>>> Also by or at Minneapolis, my sensation is that we should not only >>>>> discuss the terms of deprecating RFC 4944 HC but also consider the >>>>> spec as a whole: >>>>> >>>>> - Mesh Header is a layer violation. I talked to implementers and >>> their >>>>> message is that they do not use it because it's never exactely >>>>> what that specific radio needs; so they end up with their own mesh >>>>> header >>> anyway >>>>> and will not duplicate things for the sake of comliance. Instead >>>>> we might need a Routing header, pretty useful for source routing >>>>> in >>> route >>>>> over. >>>>> >>>>> - Fragments are not recovered individually. We have enough >>>>> experience to know where that leads should a 6LoWPAN network >>>>> experience either high load or high BER. We have a draft on the >>>>> works to deprecate that with recoverable fragments. >>>>> >>>>> - The Current HC WG doc covers all the compression cases in RFC >>>>> 4944, bigger and badder. >>>>> >>>>> So what's left? >>>>> >>>>> My proposal is to start a 4944bis that would focus on the > addressing >>>>> architecture, would be the placeholder to control the dispatch >>>>> type but would defer to the drafts/RFCs that actually detail the >>>>> operation > of >>>>> each dispatch type. >>>>> >>>>> What do you think? >>>>> >>>>> Pascal >>>>> >>>>>> -----Original Message----- >>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] > On >>>>> Behalf Of Carsten Bormann >>>>>> Sent: jeudi 9 octobre 2008 16:43 >>>>>> To: Julien Abeille (jabeille) >>>>>> Cc: Carsten Bormann; 6lowpan@ietf.org >>>>>> Subject: Re: [6lowpan] rfc4944, hc and dispatchs >>>>>> >>>>>> On Oct 09 2008, at 16:09, Julien Abeille (jabeille) wrote: >>>>>> >>>>>>> - does it officialy deprecate the old header compression scheme? >>>>>> >>>>>> My impression of the mailing list consensus is that this is what >>>>>> the WG wants to achieve. >>>>>> At the time this was discussed, I cautioned that it is premature > to >>>>>> decide on replacing something existing with known flaws with >>>>>> something not yet quite cooked (and, hence, with unknown flaws). >>>>>> So I expect we'll ultimately decide this question at the time HC >>>>>> and the related specs come up for WGLC. >>>>>> Clearly, the stated intention of many WG members is to make this >>>>>> happen, as it would be wasteful to support two HC schemes in tiny >>>>>> implementations. >>>>>> >>>>>> Gruesse, Carsten >>>>>> >>>>>> _______________________________________________ >>>>>> 6lowpan mailing list >>>>>> 6lowpan@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>> _______________________________________________ >>>>> 6lowpan mailing list >>>>> 6lowpan@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>> > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 13 01:24:50 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A7093A6800; Mon, 13 Oct 2008 01:24:50 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1663F3A6800 for <6lowpan@core3.amsl.com>; Mon, 13 Oct 2008 01:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.373 X-Spam-Level: X-Spam-Status: No, score=-6.373 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZWmNIBjy0FP for <6lowpan@core3.amsl.com>; Mon, 13 Oct 2008 01:24:48 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9E17D3A657C for <6lowpan@ietf.org>; Mon, 13 Oct 2008 01:24:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,401,1220227200"; d="scan'208";a="22400027" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 13 Oct 2008 08:24:19 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9D8OJnU011674; Mon, 13 Oct 2008 10:24:19 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9D8OJOu018301; Mon, 13 Oct 2008 08:24:19 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Oct 2008 10:24:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 13 Oct 2008 10:24:18 +0200 Message-ID: <38F26F36EAA981478A49D1F37F474A8602115D33@xmb-ams-33d.emea.cisco.com> In-Reply-To: <48EF5170.7050107@sensinode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fwd: New Version Notification fordraft-ietf-6lowpan-hc-01 Thread-Index: Ackq1/TiR06CpfxDSNGsxS73vAqF4QCNFfcA References: <20081009021535.C8E823A6959@core3.amsl.com> <48EF5170.7050107@sensinode.com> From: "Julien Abeille (jabeille)" To: "Zach Shelby" , "Jonathan Hui" X-OriginalArrivalTime: 13 Oct 2008 08:24:19.0318 (UTC) FILETIME=[1690C160:01C92D0D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3998; t=1223886259; x=1224750259; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20RE=3A=20[6lowpan]=20Fwd=3A=20New=20Version=20No tification=20fordraft-ietf-6lowpan-hc-01 |Sender:=20; bh=298FvHW4EUs36vSI4+eAIll6XXTyDkd0S+mqcqotV2g=; b=IynmG14fyTEYSpGBtWtbDslKZnI40AXn78Ir1yTWUetRXSxHz12hi+Q/+J guw6dv220Z45uSaWEe8VJq5SA2yBjjIDpZS42UNp8cLKJj6TXGqO5rlfZNAW F8aZEpZH5j; Authentication-Results: ams-dkim-1; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fwd: New Version Notification fordraft-ietf-6lowpan-hc-01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Zach, I second your concern There was recently a discussion specifically about the number of contexts needed. There seemed to be a consensus that multiple contexts was useful for renumbering only, which is rare, and that 2 contexts was enough. Was there new input since then which justifies the use of 4-bit contexts? Cheers, Julien -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Zach Shelby Sent: vendredi 10 octobre 2008 14:58 To: Jonathan Hui Cc: 6lowpan Subject: Re: [6lowpan] Fwd: New Version Notification fordraft-ietf-6lowpan-hc-01 Hi, Here are my comments on hc-01. Overall I think we are quite close with the comments from Pascal and Julien. I found the DDF name confusing. Now it has been renamed CTX in the latest formats on the list, great. As Pascal pointed out, nodes need to be able to decode all these options. One thing that worries me in having 16 contexts, is that nodes are forced to store them all. That is worst case 272 bytes of memory consumption. Worth it? Is it possible that an ultra-simple node would only have to understand the default context? The default context identifier '0000' could be clarified more in the draft. When CTX is '10' then the default context identifier '0000' is used. It should be made clear that this is the prefix advertised in RAs as useable for SAA. Regarding the ND for 6lowpan draft, HC-01 means we need to add a 4-bit context identifier flag to the 6LoWPAN Prefix Information Option. To make things clear that should always be '0000' if the A flag is '1'? - Zach Jonathan Hui wrote: > > http://tools.ietf.org/html/draft-ietf-6lowpan-hc > > This new version reflects the recent discussions on the list. The > changes are: > - HC back to 1 byte by default by stealing a few bits from the > dispatch field. > - Added better support for multicast address compression. > - Fixed alignment for UDP port compression. > - Better support for Traffic Class and Flow Label compression. > - Pascal joined as an author. > > Happy reading! > > -- > Jonathan Hui > > > > Begin forwarded message: > >> From: IETF I-D Submission Tool >> Date: October 8, 2008 7:15:35 PM PDT >> To: jhui@archrock.com >> Cc: pthubert@cisco.com >> Subject: New Version Notification for draft-ietf-6lowpan-hc-01 >> >> >> A new version of I-D, draft-ietf-6lowpan-hc-01.txt has been >> successfuly submitted by Jonathan Hui and posted to the IETF repository. >> >> Filename: draft-ietf-6lowpan-hc >> Revision: 01 >> Title: Compression Format for IPv6 Datagrams in 6LoWPAN Networks >> Creation_date: 2008-10-09 >> WG ID: 6lowpan >> Number_of_pages: 15 >> >> Abstract: >> This document specifies an IPv6 header compression format for IPv6 >> packet delivery in 6LoWPAN networks. The compression format relies >> on shared context to allow compression of arbitrary prefixes. This >> document specifies compression of multicast addresses and a framework >> for compressing next headers. This framework specifies UDP >> compression and is prepared for additional transports. >> >> >> >> The IETF Secretariat. >> >> > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan -- Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti FINLAND mobile: +358 40 7796297 This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 13 02:15:21 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6C793A68A2; Mon, 13 Oct 2008 02:15:21 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A511E3A68A2 for <6lowpan@core3.amsl.com>; Mon, 13 Oct 2008 02:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.312 X-Spam-Level: X-Spam-Status: No, score=-3.312 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAOByd+BviLz for <6lowpan@core3.amsl.com>; Mon, 13 Oct 2008 02:15:19 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 556463A657C for <6lowpan@ietf.org>; Mon, 13 Oct 2008 02:15:18 -0700 (PDT) Received: from h180245.gprs.dnafinland.fi (h180245.gprs.dnafinland.fi [87.93.180.245]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id m9D9ETXB004372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 12:14:30 +0300 Message-ID: <48F31161.7080600@sensinode.com> Date: Mon, 13 Oct 2008 12:14:09 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: "Julien Abeille (jabeille)" References: <20081009021535.C8E823A6959@core3.amsl.com> <48EF5170.7050107@sensinode.com> <38F26F36EAA981478A49D1F37F474A8602115D33@xmb-ams-33d.emea.cisco.com> In-Reply-To: <38F26F36EAA981478A49D1F37F474A8602115D33@xmb-ams-33d.emea.cisco.com> Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fwd: New Version Notification fordraft-ietf-6lowpan-hc-01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi, I don't think the consensus changed from that 2 contexts is enough.. it was just mentioned that with more someone may figure out what to do with them (renumbering). If renumbering is the only case for having a 4-bit context identifier, then I recommend Jonathan tries to integrate a short 1-2 bit context identifier into the base format as he mentioned is possible, thus avoiding the 1 byte extension for 4-bit identifiers. 2-4 contexts will be plenty, and thus we wouldn't be using memory on all nodes, or having to deal with some nodes supporting 16 and some supporting 2. Considering that we have only a link-local context in RFC4944, having 2-4 global contexts is already a huge improvement! So I would give like to see 1-2 context ID bits for source/dest in the base header, as a priority over supporting a large range of multicast address types. - Zach Julien Abeille (jabeille) wrote: > Hi Zach, > > I second your concern > > There was recently a discussion specifically about the number of > contexts needed. > There seemed to be a consensus that multiple contexts was useful for > renumbering only, which is rare, and that 2 contexts was enough. > Was there new input since then which justifies the use of 4-bit > contexts? > > Cheers, > Julien > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Zach Shelby > Sent: vendredi 10 octobre 2008 14:58 > To: Jonathan Hui > Cc: 6lowpan > Subject: Re: [6lowpan] Fwd: New Version Notification > fordraft-ietf-6lowpan-hc-01 > > Hi, > > Here are my comments on hc-01. Overall I think we are quite close with > the comments from Pascal and Julien. > > I found the DDF name confusing. Now it has been renamed CTX in the > latest formats on the list, great. > > As Pascal pointed out, nodes need to be able to decode all these > options. One thing that worries me in having 16 contexts, is that nodes > are forced to store them all. That is worst case 272 bytes of memory > consumption. Worth it? Is it possible that an ultra-simple node would > only have to understand the default context? > > The default context identifier '0000' could be clarified more in the > draft. When CTX is '10' then the default context identifier '0000' is > used. It should be made clear that this is the prefix advertised in RAs > as useable for SAA. > > Regarding the ND for 6lowpan draft, HC-01 means we need to add a 4-bit > context identifier flag to the 6LoWPAN Prefix Information Option. To > make things clear that should always be '0000' if the A flag is '1'? > > - Zach > > > Jonathan Hui wrote: >> http://tools.ietf.org/html/draft-ietf-6lowpan-hc >> >> This new version reflects the recent discussions on the list. The >> changes are: >> - HC back to 1 byte by default by stealing a few bits from the >> dispatch field. >> - Added better support for multicast address compression. >> - Fixed alignment for UDP port compression. >> - Better support for Traffic Class and Flow Label compression. >> - Pascal joined as an author. >> >> Happy reading! >> >> -- >> Jonathan Hui >> >> >> >> Begin forwarded message: >> >>> From: IETF I-D Submission Tool >>> Date: October 8, 2008 7:15:35 PM PDT >>> To: jhui@archrock.com >>> Cc: pthubert@cisco.com >>> Subject: New Version Notification for draft-ietf-6lowpan-hc-01 >>> >>> >>> A new version of I-D, draft-ietf-6lowpan-hc-01.txt has been >>> successfuly submitted by Jonathan Hui and posted to the IETF > repository. >>> Filename: draft-ietf-6lowpan-hc >>> Revision: 01 >>> Title: Compression Format for IPv6 Datagrams in 6LoWPAN > Networks >>> Creation_date: 2008-10-09 >>> WG ID: 6lowpan >>> Number_of_pages: 15 >>> >>> Abstract: >>> This document specifies an IPv6 header compression format for IPv6 >>> packet delivery in 6LoWPAN networks. The compression format relies >>> on shared context to allow compression of arbitrary prefixes. This >>> document specifies compression of multicast addresses and a framework > >>> for compressing next headers. This framework specifies UDP >>> compression and is prepared for additional transports. >>> >>> >>> >>> The IETF Secretariat. >>> >>> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > -- Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti FINLAND mobile: +358 40 7796297 This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 13 03:15:40 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1B543A6A27; Mon, 13 Oct 2008 03:15:40 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2D4C3A6A27 for <6lowpan@core3.amsl.com>; Mon, 13 Oct 2008 03:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bV-hJD+IRICx for <6lowpan@core3.amsl.com>; Mon, 13 Oct 2008 03:15:38 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D3A0D3A68F7 for <6lowpan@ietf.org>; Mon, 13 Oct 2008 03:15:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,402,1220227200"; d="scan'208";a="22420589" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 13 Oct 2008 10:15:52 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9DAFqDx026830; Mon, 13 Oct 2008 12:15:52 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9DAFqxj008004; Mon, 13 Oct 2008 10:15:52 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Oct 2008 12:15:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 13 Oct 2008 12:15:52 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC065C31F8@xmb-ams-337.emea.cisco.com> In-Reply-To: <48F31161.7080600@sensinode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fwd: New Version Notificationfordraft-ietf-6lowpan-hc-01 Thread-Index: AcktFF7k1u+X/3AnQIinXO3Fy7i6fwAAbTdw References: <20081009021535.C8E823A6959@core3.amsl.com><48EF5170.7050107@sensinode.com><38F26F36EAA981478A49D1F37F474A8602115D33@xmb-ams-33d.emea.cisco.com> <48F31161.7080600@sensinode.com> From: "Pascal Thubert (pthubert)" To: "Zach Shelby" , "Julien Abeille (jabeille)" X-OriginalArrivalTime: 13 Oct 2008 10:15:52.0587 (UTC) FILETIME=[AC108DB0:01C92D1C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7053; t=1223892952; x=1224756952; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20Fwd=3A=20New=20Version=20No tificationfordraft-ietf-6lowpan-hc-01 |Sender:=20; bh=HuV09SkW5KwuyeDU8VPVLQU2ZgqfAvIMhMo3Z/eSEtw=; b=jFCFTBl0o2o4ayBApM+1jse/qwJeEu4pGFDDo5KP7shiQ+vCvA9L9q9/pN HOdL1A1lYP/jHgUrDdBjBDSU+rTI0FTuHRBFqo2GQfIpE6Q4xTO6cK4tDvto nXHBooiAX/; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fwd: New Version Notificationfordraft-ietf-6lowpan-hc-01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Zach: The 2 bits were integrated in HC when we passed the HC to 2 bytes (that was hc_00). With hc_01, we are back to one byte and not too ready to bounce again. I mean, there are many things we could do with more bits in HC but then we're loosing the value of compression in the first place. Since most times the default context is the right one, we decided to handle the exception by putting the context information in an optional byte that should "almost" never by there if the context is used for renumbering only. At that point we have that additional byte, we can shoot for 16 contexts both directions. This might not be the best use of that byte, and we should discuss that furthermore. But a context might not be limited to a prefix. We can use a context to (state)fully compress an address like the address of an edge router. One byte against 8 or 16 per packet might be worth an entry in memory. Now you made it very clear that not all nodes can support 16 many contexts. Fine. We need to work on how the option is really optional, and how a node may not have to support all contexts. OTOH, the consensus on 2 contexts had to do with the cost in bits in every packet. Now we moved to a cost that is only paid by exceptional packets, 16 MAX might become a good value after all. I think that all this requires more thoughts. Once we really understand what we do with contexts and what the cost is per type of context entry, then we can figure out what the right value is, and whether all entries are globally significant or not. What do you think? Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Zach Shelby >Sent: lundi 13 octobre 2008 11:14 >To: Julien Abeille (jabeille) >Cc: 6lowpan >Subject: Re: [6lowpan] Fwd: New Version Notificationfordraft-ietf-6lowpan-hc-01 > >Hi, > >I don't think the consensus changed from that 2 contexts is enough.. it >was just mentioned that with more someone may figure out what to do with >them (renumbering). If renumbering is the only case for having a 4-bit >context identifier, then I recommend Jonathan tries to integrate a short >1-2 bit context identifier into the base format as he mentioned is >possible, thus avoiding the 1 byte extension for 4-bit identifiers. 2-4 >contexts will be plenty, and thus we wouldn't be using memory on all >nodes, or having to deal with some nodes supporting 16 and some >supporting 2. Considering that we have only a link-local context in >RFC4944, having 2-4 global contexts is already a huge improvement! > >So I would give like to see 1-2 context ID bits for source/dest in the >base header, as a priority over supporting a large range of multicast >address types. > >- Zach > >Julien Abeille (jabeille) wrote: >> Hi Zach, >> >> I second your concern >> >> There was recently a discussion specifically about the number of >> contexts needed. >> There seemed to be a consensus that multiple contexts was useful for >> renumbering only, which is rare, and that 2 contexts was enough. >> Was there new input since then which justifies the use of 4-bit >> contexts? >> >> Cheers, >> Julien >> >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >> Behalf Of Zach Shelby >> Sent: vendredi 10 octobre 2008 14:58 >> To: Jonathan Hui >> Cc: 6lowpan >> Subject: Re: [6lowpan] Fwd: New Version Notification >> fordraft-ietf-6lowpan-hc-01 >> >> Hi, >> >> Here are my comments on hc-01. Overall I think we are quite close with >> the comments from Pascal and Julien. >> >> I found the DDF name confusing. Now it has been renamed CTX in the >> latest formats on the list, great. >> >> As Pascal pointed out, nodes need to be able to decode all these >> options. One thing that worries me in having 16 contexts, is that nodes >> are forced to store them all. That is worst case 272 bytes of memory >> consumption. Worth it? Is it possible that an ultra-simple node would >> only have to understand the default context? >> >> The default context identifier '0000' could be clarified more in the >> draft. When CTX is '10' then the default context identifier '0000' is >> used. It should be made clear that this is the prefix advertised in RAs >> as useable for SAA. >> >> Regarding the ND for 6lowpan draft, HC-01 means we need to add a 4-bit >> context identifier flag to the 6LoWPAN Prefix Information Option. To >> make things clear that should always be '0000' if the A flag is '1'? >> >> - Zach >> >> >> Jonathan Hui wrote: >>> http://tools.ietf.org/html/draft-ietf-6lowpan-hc >>> >>> This new version reflects the recent discussions on the list. The >>> changes are: >>> - HC back to 1 byte by default by stealing a few bits from the >>> dispatch field. >>> - Added better support for multicast address compression. >>> - Fixed alignment for UDP port compression. >>> - Better support for Traffic Class and Flow Label compression. >>> - Pascal joined as an author. >>> >>> Happy reading! >>> >>> -- >>> Jonathan Hui >>> >>> >>> >>> Begin forwarded message: >>> >>>> From: IETF I-D Submission Tool >>>> Date: October 8, 2008 7:15:35 PM PDT >>>> To: jhui@archrock.com >>>> Cc: pthubert@cisco.com >>>> Subject: New Version Notification for draft-ietf-6lowpan-hc-01 >>>> >>>> >>>> A new version of I-D, draft-ietf-6lowpan-hc-01.txt has been >>>> successfuly submitted by Jonathan Hui and posted to the IETF >> repository. >>>> Filename: draft-ietf-6lowpan-hc >>>> Revision: 01 >>>> Title: Compression Format for IPv6 Datagrams in 6LoWPAN >> Networks >>>> Creation_date: 2008-10-09 >>>> WG ID: 6lowpan >>>> Number_of_pages: 15 >>>> >>>> Abstract: >>>> This document specifies an IPv6 header compression format for IPv6 >>>> packet delivery in 6LoWPAN networks. The compression format relies >>>> on shared context to allow compression of arbitrary prefixes. This >>>> document specifies compression of multicast addresses and a framework >> >>>> for compressing next headers. This framework specifies UDP >>>> compression and is prepared for additional transports. >>>> >>>> >>>> >>>> The IETF Secretariat. >>>> >>>> >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >> > >-- > >Zach Shelby >Head of Research >Sensinode Ltd. >Kidekuja 2 >88610 Vuokatti >FINLAND > >mobile: +358 40 7796297 > >This e-mail and all attached material are confidential and may contain >legally privileged information. If you are not the intended recipient, >please contact the sender and delete the e-mail from your system without >producing, distributing or retaining copies thereof. >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 13 03:15:43 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14EAD28C0EF; Mon, 13 Oct 2008 03:15:43 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D39E13A6B5C for <6lowpan@core3.amsl.com>; Mon, 13 Oct 2008 03:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZmLVm2QLxtB for <6lowpan@core3.amsl.com>; Mon, 13 Oct 2008 03:15:39 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C30793A69C1 for <6lowpan@ietf.org>; Mon, 13 Oct 2008 03:15:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,402,1220227200"; d="scan'208";a="22420596" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 13 Oct 2008 10:15:57 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m9DAFv7u024713; Mon, 13 Oct 2008 12:15:57 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9DAFved008023; Mon, 13 Oct 2008 10:15:57 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Oct 2008 12:15:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 13 Oct 2008 12:15:47 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC065C31F9@xmb-ams-337.emea.cisco.com> In-Reply-To: <38F26F36EAA981478A49D1F37F474A8602115D1F@xmb-ams-33d.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] rfc4944, hc and dispatchs Thread-Index: Ackq+ugV/DiDB1qsSoKk/BI6in6LxQCDoBogAAREFOA= References: <38F26F36EAA981478A49D1F37F474A86020D06DA@xmb-ams-33d.emea.cisco.com><105175C7-A788-4225-9E5A-845A07AA3621@tzi.org><7892795E1A87F04CADFCCF41FADD00FC065C29B2@xmb-ams-337.emea.cisco.com><641900E3-3665-4BED-9FA5-F8FB1667092F@archrock.com><7892795E1A87F04CADFCCF41FADD00FC065C2E40@xmb-ams-337.emea.cisco.com><7892795E1A87F04CADFCCF41FADD00FC065C2E70@xmb-ams-337.emea.cisco.com> <38F26F36EAA981478A49D1F37F474A8602115D1F@xmb-ams-33d.emea.cisco.com> From: "Pascal Thubert (pthubert)" To: "Julien Abeille (jabeille)" , "Jonathan Hui" , "Carsten Bormann" , <6lowpan@ietf.org>, "Geoff Mulligan" X-OriginalArrivalTime: 13 Oct 2008 10:15:57.0568 (UTC) FILETIME=[AF089800:01C92D1C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9674; t=1223892957; x=1224756957; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20rfc4944,=20hc=20and=20dispa tchs |Sender:=20; bh=Qv/ikKNibDJGRRo/viMkLhlsqvBLUP/s8SrvV1tL6Ds=; b=r//du3OieQoB1H1v26+/FGxu96zd6ZPV/R7uwqSpgZW6i2lqZWwzKqxo2i h+QljWPyAPn4nayNJu1JPgZoirb1YMBkPc3z0L6d+v6SgiHQVGZub8oXo7MH IvvXeLJdAl; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [6lowpan] rfc4944, hc and dispatchs X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Julien: Pseudo code is good. Please remember that the reference is the current spec, so we need to compare pseudo code of a proposed change with pseudo code of that reference. In the reference, the compression of the pair of addresses is specifiied using 6 bits. Consuming more and more of the dispatch space: - multiplies by 2 the number of consumed dispatches each time - reduces the space allocated for future extensions - will require a revamp of 4944 right away with no backward compatibility It's very hard to reach a solution than will please all for all the various standpoints and priorities (smaller HC, lmarger coverage, smaller code, smaller memory...). And we could keep changing these formats forever. So we need rules and limits, in particular we need to keep in mind that: - Making implementation simpler or smaller is good - Making the base HC bigger is bad, every bit costs dearly - Compressing cases for which we have no known usage has very marginal value. Would you agree with that? Pascal >-----Original Message----- >From: Julien Abeille (jabeille) >Sent: lundi 13 octobre 2008 10:14 >To: Jonathan Hui; Pascal Thubert (pthubert); Carsten Bormann; 6lowpan@ietf.org; Geoff Mulligan >Subject: RE: [6lowpan] rfc4944, hc and dispatchs > >Hi Jonathan , all, > >I do not have particular use cases in mind for specific address types. > >My approach is the following: >- how many bits can we afford? >- with this amount of bits, let's try to support as many IP scenarios as possible, keeping a low >level of complexity and a high level of clarity. > >For the first question: >- there are currently around 150/255 dispatch values used. >- A priori I would be in favor of deprecating some (mesh, not a lowpan frame), or at least do you >agree they are less important than HC. This would drag the number of values to 25/255 >- I do foresee some new 6lowpan specs will take some of them, but not that many. Do you see anything >else appart from fragment recovery? >Hence I am convinced taking 32 values is very acceptable (this is 8 bits for address compression) >Do you agree with this? > >For the second question: >- with 8 bits for address compression, we can do something very clean and easy to implement, handling >all IP addressing scenarios. > >I will send today an example on 8bits and pseudo code to be able to compare 7-bit/8-bit complexity > >Regards, >Julien > > > >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Jonathan Hui >Sent: vendredi 10 octobre 2008 19:09 >To: Pascal Thubert (pthubert) >Cc: Carsten Bormann; 6lowpan@ietf.org; Geoff Mulligan >Subject: Re: [6lowpan] rfc4944, hc and dispatchs > > >Hi Pascal, > >Yes, you are right - hc-01 supports all header values (just carry everything in-line). > >Regarding Julien's comments, I think hc-01 and the format proposed to support Julien's cases are >straight-forward to implement. I think the more important issue is whether Julien's cases will be >common in 6LoWPAN applications. We (Arch Rock) do not commonly use the cases that Julien wishes to >add compression for. But if Julien/others can demonstrate a strong need for them (i.e. cases that >will be used fairly often in relevant 6LoWPAN applications), then I do think we should consider them. >Julien, can you explain important commonly used cases that would not be supported by hc-01? > >-- >Jonathan Hui > > > >On Oct 10, 2008, at 9:41 AM, Pascal Thubert (pthubert) wrote: > >> Hi Jonathan >> >> Maybe a good reason to stick to the current format and change the >> misleading wording around it, what do you think? In any case, I'm all >> for starting 4944bis and recoverable frags today, though. >> >> Pascal >> >>> -----Original Message----- >>> From: Jonathan Hui [mailto:jhui@archrock.com] >>> Sent: vendredi 10 octobre 2008 18:02 >>> To: Pascal Thubert (pthubert) >>> Cc: Carsten Bormann; Geoff Mulligan; 6lowpan@ietf.org >>> Subject: Re: [6lowpan] rfc4944, hc and dispatchs >>> >>> >>> Hi Pascal: >>> >>> I'm for pushing HC through as quickly as possible. We are already >>> behind according to the charter text. >>> >>> The one dependency I see is the structure of the dispatch byte. If we >>> choose a dispatch value(s) that is compatible with RFC 4944, then we >>> are fine, I think. But if we want extra bits by changing the layout >>> of the dispatch values/identifiers for Frag/Mesh headers (as both I >>> and Julien have proposed) then this creates a dependency on defining >>> that new dispatch assignment scheme. >>> >>> -- >>> Jonathan Hui >>> >>> >>> On Oct 10, 2008, at 8:51 AM, Pascal Thubert (pthubert) wrote: >>> >>>> I'm all with you, Jonathan, as long as that does not delay HC. >>>> >>>> This is why I proposed a structured set of document that leaves HC >>>> with its current scope as opposed to making it a full revision of >>>> 4944. >>>> Makes >>>> sense? >>>> >>>> Pascal >>>> >>>>> -----Original Message----- >>>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>>> Sent: jeudi 9 octobre 2008 21:17 >>>>> To: Pascal Thubert (pthubert) >>>>> Cc: Carsten Bormann; Geoff Mulligan; 6lowpan@ietf.org >>>>> Subject: Re: [6lowpan] rfc4944, hc and dispatchs >>>>> >>>>> >>>>> In general, I'm in support of Pascal's proposal. Cleaning up the >>>>> format to use a stacked-header format was just one of the items and >>>>> there were many other things we wanted to fix before pushing out >>>>> RFC 4944. But we were far too late to the game in doing a complete >>>>> overhaul of the doc. I think *now* is the time to make improvements >>>>> to RFC 4944. >>>>> >>>>> -- >>>>> Jonathan Hui >>>>> >>>>> >>>>> >>>>> On Oct 9, 2008, at 10:41 AM, Pascal Thubert (pthubert) wrote: >>>>> >>>>>> Hi Carsten: >>>>>> >>>>>> Some implementations and dependant standards would require a >>>>>> timeline for this. Leaving it up in the air does not help our >>>>>> users do their product planning? >>>>>> >>>>>> Considering the attention and the work on the new LOWPAN_IPHC, I >>>>>> expect that we'll be ready for WGLC after 2/3 more respins. That >>>>>> could be achieved by Minneapolis time if we can rally all >>>>>> interested parties >>>> to >>>>>> comment on the existing published spec. So could you chairs >>>>>> please: >>>>>> >>>>>>>>>>>>>>>> propose a time line to the WG along those lines >>>> <<<<<<<<<<<< >>>>>>>>>>>>>>>> raise WG attention on this work? >>>> <<<<<<<<<<<< >>>>>> >>>>>> Also by or at Minneapolis, my sensation is that we should not only >>>>>> discuss the terms of deprecating RFC 4944 HC but also consider the >>>>>> spec as a whole: >>>>>> >>>>>> - Mesh Header is a layer violation. I talked to implementers and >>>> their >>>>>> message is that they do not use it because it's never exactely >>>>>> what that specific radio needs; so they end up with their own mesh >>>>>> header >>>> anyway >>>>>> and will not duplicate things for the sake of comliance. Instead >>>>>> we might need a Routing header, pretty useful for source routing >>>>>> in >>>> route >>>>>> over. >>>>>> >>>>>> - Fragments are not recovered individually. We have enough >>>>>> experience to know where that leads should a 6LoWPAN network >>>>>> experience either high load or high BER. We have a draft on the >>>>>> works to deprecate that with recoverable fragments. >>>>>> >>>>>> - The Current HC WG doc covers all the compression cases in RFC >>>>>> 4944, bigger and badder. >>>>>> >>>>>> So what's left? >>>>>> >>>>>> My proposal is to start a 4944bis that would focus on the >> addressing >>>>>> architecture, would be the placeholder to control the dispatch >>>>>> type but would defer to the drafts/RFCs that actually detail the >>>>>> operation >> of >>>>>> each dispatch type. >>>>>> >>>>>> What do you think? >>>>>> >>>>>> Pascal >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] >> On >>>>>> Behalf Of Carsten Bormann >>>>>>> Sent: jeudi 9 octobre 2008 16:43 >>>>>>> To: Julien Abeille (jabeille) >>>>>>> Cc: Carsten Bormann; 6lowpan@ietf.org >>>>>>> Subject: Re: [6lowpan] rfc4944, hc and dispatchs >>>>>>> >>>>>>> On Oct 09 2008, at 16:09, Julien Abeille (jabeille) wrote: >>>>>>> >>>>>>>> - does it officialy deprecate the old header compression scheme? >>>>>>> >>>>>>> My impression of the mailing list consensus is that this is what >>>>>>> the WG wants to achieve. >>>>>>> At the time this was discussed, I cautioned that it is premature >> to >>>>>>> decide on replacing something existing with known flaws with >>>>>>> something not yet quite cooked (and, hence, with unknown flaws). >>>>>>> So I expect we'll ultimately decide this question at the time HC >>>>>>> and the related specs come up for WGLC. >>>>>>> Clearly, the stated intention of many WG members is to make this >>>>>>> happen, as it would be wasteful to support two HC schemes in tiny >>>>>>> implementations. >>>>>>> >>>>>>> Gruesse, Carsten >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 6lowpan mailing list >>>>>>> 6lowpan@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>> _______________________________________________ >>>>>> 6lowpan mailing list >>>>>> 6lowpan@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>> >> > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 13 03:52:13 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CFFC3A69C1; Mon, 13 Oct 2008 03:52:13 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD9803A681B for <6lowpan@core3.amsl.com>; Mon, 13 Oct 2008 03:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.369 X-Spam-Level: X-Spam-Status: No, score=-3.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNnytTDlIUvH for <6lowpan@core3.amsl.com>; Mon, 13 Oct 2008 03:52:11 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 00D533A69C1 for <6lowpan@ietf.org>; Mon, 13 Oct 2008 03:52:10 -0700 (PDT) Received: from h163148.gprs.dnafinland.fi (h163148.gprs.dnafinland.fi [87.93.163.148]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id m9DAqSqR012701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 13:52:29 +0300 Message-ID: <48F3286E.8010404@sensinode.com> Date: Mon, 13 Oct 2008 13:52:30 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <20081009021535.C8E823A6959@core3.amsl.com><48EF5170.7050107@sensinode.com><38F26F36EAA981478A49D1F37F474A8602115D33@xmb-ams-33d.emea.cisco.com> <48F31161.7080600@sensinode.com> <7892795E1A87F04CADFCCF41FADD00FC065C31F8@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC065C31F8@xmb-ams-337.emea.cisco.com> Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fwd: New Version Notificationfordraft-ietf-6lowpan-hc-01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi, True, in general I am with you here. And I agree that the base format should be as compact and simple as possible. I am OK keeping it as is, as long as we can make it optional for hosts as below. Pascal Thubert (pthubert) wrote: > Hi Zach: > > The 2 bits were integrated in HC when we passed the HC to 2 bytes (that > was hc_00). With hc_01, we are back to one byte and not too ready to > bounce again. I mean, there are many things we could do with more bits > in HC but then we're loosing the value of compression in the first > place. I also don't want 2 bytes again. I understood that the dispatch space could be used for that, but I also think we should be careful using too much of that. > Since most times the default context is the right one, we decided to > handle the exception by putting the context information in an optional > byte that should "almost" never by there if the context is used for > renumbering only. > > At that point we have that additional byte, we can shoot for 16 contexts > both directions. This might not be the best use of that byte, and we > should discuss that furthermore. But a context might not be limited to a > prefix. We can use a context to (state)fully compress an address like > the address of an edge router. One byte against 8 or 16 per packet might > be worth an entry in memory. I have no problem with the use of the 2nd byte in the current HC-01. > Now you made it very clear that not all nodes can support 16 many > contexts. Fine. We need to work on how the option is really optional, > and how a node may not have to support all contexts. OTOH, the consensus > on 2 contexts had to do with the cost in bits in every packet. Now we > moved to a cost that is only paid by exceptional packets, 16 MAX might > become a good value after all. We just need to find a way to make it optional as you pointed out. If we can do that, then I am happy. 16 is a fine number, as long as a simple host can get by with just understanding and using the default. It might be as simple as this: "6LoWPAN Hosts may choose to make use of the optional 4-bit context IDs . A Host must support the default context ID. 6LoWPAN Routers must support 4-bit context IDs." As a simple Host will only receive incoming packets to it using the stateless options or global default prefix. A simple host can also choose to use only the default context when sending packets. Therefore it doesn't have to care about the optional 4-bit context IDs at all. > I think that all this requires more thoughts. Once we really understand > what we do with contexts and what the cost is per type of context entry, > then we can figure out what the right value is, and whether all entries > are globally significant or not. > What do you think? > > Pascal > >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Zach Shelby >> Sent: lundi 13 octobre 2008 11:14 >> To: Julien Abeille (jabeille) >> Cc: 6lowpan >> Subject: Re: [6lowpan] Fwd: New Version > Notificationfordraft-ietf-6lowpan-hc-01 >> Hi, >> >> I don't think the consensus changed from that 2 contexts is enough.. it >> was just mentioned that with more someone may figure out what to do > with >> them (renumbering). If renumbering is the only case for having a 4-bit >> context identifier, then I recommend Jonathan tries to integrate a > short >> 1-2 bit context identifier into the base format as he mentioned is >> possible, thus avoiding the 1 byte extension for 4-bit identifiers. 2-4 >> contexts will be plenty, and thus we wouldn't be using memory on all >> nodes, or having to deal with some nodes supporting 16 and some >> supporting 2. Considering that we have only a link-local context in >> RFC4944, having 2-4 global contexts is already a huge improvement! >> >> So I would give like to see 1-2 context ID bits for source/dest in the >> base header, as a priority over supporting a large range of multicast >> address types. >> >> - Zach >> >> Julien Abeille (jabeille) wrote: >>> Hi Zach, >>> >>> I second your concern >>> >>> There was recently a discussion specifically about the number of >>> contexts needed. >>> There seemed to be a consensus that multiple contexts was useful for >>> renumbering only, which is rare, and that 2 contexts was enough. >>> Was there new input since then which justifies the use of 4-bit >>> contexts? >>> >>> Cheers, >>> Julien >>> >>> -----Original Message----- >>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >>> Behalf Of Zach Shelby >>> Sent: vendredi 10 octobre 2008 14:58 >>> To: Jonathan Hui >>> Cc: 6lowpan >>> Subject: Re: [6lowpan] Fwd: New Version Notification >>> fordraft-ietf-6lowpan-hc-01 >>> >>> Hi, >>> >>> Here are my comments on hc-01. Overall I think we are quite close > with >>> the comments from Pascal and Julien. >>> >>> I found the DDF name confusing. Now it has been renamed CTX in the >>> latest formats on the list, great. >>> >>> As Pascal pointed out, nodes need to be able to decode all these >>> options. One thing that worries me in having 16 contexts, is that > nodes >>> are forced to store them all. That is worst case 272 bytes of memory >>> consumption. Worth it? Is it possible that an ultra-simple node would >>> only have to understand the default context? >>> >>> The default context identifier '0000' could be clarified more in the >>> draft. When CTX is '10' then the default context identifier '0000' is >>> used. It should be made clear that this is the prefix advertised in > RAs >>> as useable for SAA. >>> >>> Regarding the ND for 6lowpan draft, HC-01 means we need to add a > 4-bit >>> context identifier flag to the 6LoWPAN Prefix Information Option. To >>> make things clear that should always be '0000' if the A flag is '1'? >>> >>> - Zach >>> >>> >>> Jonathan Hui wrote: >>>> http://tools.ietf.org/html/draft-ietf-6lowpan-hc >>>> >>>> This new version reflects the recent discussions on the list. The >>>> changes are: >>>> - HC back to 1 byte by default by stealing a few bits from the >>>> dispatch field. >>>> - Added better support for multicast address compression. >>>> - Fixed alignment for UDP port compression. >>>> - Better support for Traffic Class and Flow Label compression. >>>> - Pascal joined as an author. >>>> >>>> Happy reading! >>>> >>>> -- >>>> Jonathan Hui >>>> >>>> >>>> >>>> Begin forwarded message: >>>> >>>>> From: IETF I-D Submission Tool >>>>> Date: October 8, 2008 7:15:35 PM PDT >>>>> To: jhui@archrock.com >>>>> Cc: pthubert@cisco.com >>>>> Subject: New Version Notification for draft-ietf-6lowpan-hc-01 >>>>> >>>>> >>>>> A new version of I-D, draft-ietf-6lowpan-hc-01.txt has been >>>>> successfuly submitted by Jonathan Hui and posted to the IETF >>> repository. >>>>> Filename: draft-ietf-6lowpan-hc >>>>> Revision: 01 >>>>> Title: Compression Format for IPv6 Datagrams in 6LoWPAN >>> Networks >>>>> Creation_date: 2008-10-09 >>>>> WG ID: 6lowpan >>>>> Number_of_pages: 15 >>>>> >>>>> Abstract: >>>>> This document specifies an IPv6 header compression format for IPv6 >>>>> packet delivery in 6LoWPAN networks. The compression format relies >>>>> on shared context to allow compression of arbitrary prefixes. This >>>>> document specifies compression of multicast addresses and a > framework >>>>> for compressing next headers. This framework specifies UDP >>>>> compression and is prepared for additional transports. >>>>> >>>>> >>>>> >>>>> The IETF Secretariat. >>>>> >>>>> >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> 6lowpan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowpan >> -- >> >> Zach Shelby >> Head of Research >> Sensinode Ltd. >> Kidekuja 2 >> 88610 Vuokatti >> FINLAND >> >> mobile: +358 40 7796297 >> >> This e-mail and all attached material are confidential and may contain >> legally privileged information. If you are not the intended recipient, >> please contact the sender and delete the e-mail from your system > without >> producing, distributing or retaining copies thereof. >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan -- Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti FINLAND mobile: +358 40 7796297 This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 13 05:07:20 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13D6C3A6B8B; Mon, 13 Oct 2008 05:07:20 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4C4E3A6B8B for <6lowpan@core3.amsl.com>; Mon, 13 Oct 2008 05:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.396 X-Spam-Level: X-Spam-Status: No, score=-6.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZ7BYwJYsZ8X for <6lowpan@core3.amsl.com>; Mon, 13 Oct 2008 05:07:14 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 76CE33A6A38 for <6lowpan@ietf.org>; Mon, 13 Oct 2008 05:07:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,403,1220227200"; d="scan'208";a="22437518" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 13 Oct 2008 12:07:39 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9DC7dqO003434; Mon, 13 Oct 2008 14:07:39 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9DC7dZb020938; Mon, 13 Oct 2008 12:07:39 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Oct 2008 14:07:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 13 Oct 2008 14:07:38 +0200 Message-ID: <38F26F36EAA981478A49D1F37F474A8602115F6A@xmb-ams-33d.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC065C31F9@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] rfc4944, hc and dispatchs Thread-Index: Ackq+ugV/DiDB1qsSoKk/BI6in6LxQCDoBogAAREFOAABBBXkA== References: <38F26F36EAA981478A49D1F37F474A86020D06DA@xmb-ams-33d.emea.cisco.com><105175C7-A788-4225-9E5A-845A07AA3621@tzi.org><7892795E1A87F04CADFCCF41FADD00FC065C29B2@xmb-ams-337.emea.cisco.com><641900E3-3665-4BED-9FA5-F8FB1667092F@archrock.com><7892795E1A87F04CADFCCF41FADD00FC065C2E40@xmb-ams-337.emea.cisco.com><7892795E1A87F04CADFCCF41FADD00FC065C2E70@xmb-ams-337.emea.cisco.com> <38F26F36EAA981478A49D1F37F474A8602115D1F@xmb-ams-33d.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC065C31F9@xmb-ams-337.emea.cisco.com> From: "Julien Abeille (jabeille)" To: "Pascal Thubert (pthubert)" , "Jonathan Hui" , "Carsten Bormann" , <6lowpan@ietf.org>, "Geoff Mulligan" X-OriginalArrivalTime: 13 Oct 2008 12:07:39.0296 (UTC) FILETIME=[49932200:01C92D2C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10903; t=1223899659; x=1224763659; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20RE=3A=20[6lowpan]=20rfc4944,=20hc=20and=20dispa tchs |Sender:=20; bh=tZF9biOLeyKelCdy5bGPqBzdhcODA58J77p6pzTJozY=; b=H95wPKh++bpqud0KO2w/9KwRvODGTTyeeNhpwwzmcBhkQ5D9Q9mlM8ufq9 82vUKbtYKL2TglPSnYVpUduOF0wUbTyyAHeEVY6PjZctTFhFJ02e/JqQXLZ+ iP9LUyofOd; Authentication-Results: ams-dkim-1; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [6lowpan] rfc4944, hc and dispatchs X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Pascal, all, I comment inline -----Original Message----- From: Pascal Thubert (pthubert) Sent: lundi 13 octobre 2008 12:16 To: Julien Abeille (jabeille); 'Jonathan Hui'; 'Carsten Bormann'; '6lowpan@ietf.org'; 'Geoff Mulligan' Subject: RE: [6lowpan] rfc4944, hc and dispatchs Hi Julien: Pseudo code is good. Please remember that the reference is the current spec, so we need to compare pseudo code of a proposed change with pseudo code of that reference. In the reference, the compression of the pair of addresses is specifiied using 6 bits. Consuming more and more of the dispatch space: - multiplies by 2 the number of consumed dispatches each time - reduces the space allocated for future extensions [Julien] As I said in my previous email, with all this in mind, I am convinced we can afford 32 values for HC (this is 13 bits, 5 in the dispatch, plus one byte) Do people agree that 32 values for HC is ok? - will require a revamp of 4944 right away with no backward compatibility [Julien] sure, do the chairs or people think we must take this as design constraint? It's very hard to reach a solution than will please all for all the various standpoints and priorities (smaller HC, lmarger coverage, smaller code, smaller memory...). And we could keep changing these formats forever. So we need rules and limits, in particular we need to keep in mind that: - Making implementation simpler or smaller is good - Making the base HC bigger is bad, every bit costs dearly [Julien] I think that as long as we do not need another BYTE and respect the maximum limit we fix, adding bits is at the contrary a very good point for simplicity and implementation size. - Compressing cases for which we have no known usage has very marginal value. [Julien] As we do not know what the typical usage will be in 12 month, I would avoid taking this as a design constraint. Again, I propose to make the best use possible of the bits we have. If do not have enough space to support some scenarios, then I am ok not to support them. Regards, Julien Would you agree with that? Pascal >-----Original Message----- >From: Julien Abeille (jabeille) >Sent: lundi 13 octobre 2008 10:14 >To: Jonathan Hui; Pascal Thubert (pthubert); Carsten Bormann; >6lowpan@ietf.org; Geoff Mulligan >Subject: RE: [6lowpan] rfc4944, hc and dispatchs > >Hi Jonathan , all, > >I do not have particular use cases in mind for specific address types. > >My approach is the following: >- how many bits can we afford? >- with this amount of bits, let's try to support as many IP scenarios >as possible, keeping a low level of complexity and a high level of clarity. > >For the first question: >- there are currently around 150/255 dispatch values used. >- A priori I would be in favor of deprecating some (mesh, not a lowpan >frame), or at least do you agree they are less important than HC. This >would drag the number of values to 25/255 >- I do foresee some new 6lowpan specs will take some of them, but not >that many. Do you see anything else appart from fragment recovery? >Hence I am convinced taking 32 values is very acceptable (this is 8 >bits for address compression) Do you agree with this? > >For the second question: >- with 8 bits for address compression, we can do something very clean >and easy to implement, handling all IP addressing scenarios. > >I will send today an example on 8bits and pseudo code to be able to >compare 7-bit/8-bit complexity > >Regards, >Julien > > > >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >Behalf Of Jonathan Hui >Sent: vendredi 10 octobre 2008 19:09 >To: Pascal Thubert (pthubert) >Cc: Carsten Bormann; 6lowpan@ietf.org; Geoff Mulligan >Subject: Re: [6lowpan] rfc4944, hc and dispatchs > > >Hi Pascal, > >Yes, you are right - hc-01 supports all header values (just carry everything in-line). > >Regarding Julien's comments, I think hc-01 and the format proposed to >support Julien's cases are straight-forward to implement. I think the >more important issue is whether Julien's cases will be common in >6LoWPAN applications. We (Arch Rock) do not commonly use the cases that >Julien wishes to add compression for. But if Julien/others can demonstrate a strong need for them (i.e. cases that will be used fairly often in relevant 6LoWPAN applications), then I do think we should consider them. >Julien, can you explain important commonly used cases that would not be supported by hc-01? > >-- >Jonathan Hui > > > >On Oct 10, 2008, at 9:41 AM, Pascal Thubert (pthubert) wrote: > >> Hi Jonathan >> >> Maybe a good reason to stick to the current format and change the >> misleading wording around it, what do you think? In any case, I'm all >> for starting 4944bis and recoverable frags today, though. >> >> Pascal >> >>> -----Original Message----- >>> From: Jonathan Hui [mailto:jhui@archrock.com] >>> Sent: vendredi 10 octobre 2008 18:02 >>> To: Pascal Thubert (pthubert) >>> Cc: Carsten Bormann; Geoff Mulligan; 6lowpan@ietf.org >>> Subject: Re: [6lowpan] rfc4944, hc and dispatchs >>> >>> >>> Hi Pascal: >>> >>> I'm for pushing HC through as quickly as possible. We are already >>> behind according to the charter text. >>> >>> The one dependency I see is the structure of the dispatch byte. If >>> we choose a dispatch value(s) that is compatible with RFC 4944, then >>> we are fine, I think. But if we want extra bits by changing the >>> layout of the dispatch values/identifiers for Frag/Mesh headers (as >>> both I and Julien have proposed) then this creates a dependency on >>> defining that new dispatch assignment scheme. >>> >>> -- >>> Jonathan Hui >>> >>> >>> On Oct 10, 2008, at 8:51 AM, Pascal Thubert (pthubert) wrote: >>> >>>> I'm all with you, Jonathan, as long as that does not delay HC. >>>> >>>> This is why I proposed a structured set of document that leaves HC >>>> with its current scope as opposed to making it a full revision of >>>> 4944. >>>> Makes >>>> sense? >>>> >>>> Pascal >>>> >>>>> -----Original Message----- >>>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>>> Sent: jeudi 9 octobre 2008 21:17 >>>>> To: Pascal Thubert (pthubert) >>>>> Cc: Carsten Bormann; Geoff Mulligan; 6lowpan@ietf.org >>>>> Subject: Re: [6lowpan] rfc4944, hc and dispatchs >>>>> >>>>> >>>>> In general, I'm in support of Pascal's proposal. Cleaning up the >>>>> format to use a stacked-header format was just one of the items >>>>> and there were many other things we wanted to fix before pushing >>>>> out RFC 4944. But we were far too late to the game in doing a >>>>> complete overhaul of the doc. I think *now* is the time to make >>>>> improvements to RFC 4944. >>>>> >>>>> -- >>>>> Jonathan Hui >>>>> >>>>> >>>>> >>>>> On Oct 9, 2008, at 10:41 AM, Pascal Thubert (pthubert) wrote: >>>>> >>>>>> Hi Carsten: >>>>>> >>>>>> Some implementations and dependant standards would require a >>>>>> timeline for this. Leaving it up in the air does not help our >>>>>> users do their product planning? >>>>>> >>>>>> Considering the attention and the work on the new LOWPAN_IPHC, I >>>>>> expect that we'll be ready for WGLC after 2/3 more respins. That >>>>>> could be achieved by Minneapolis time if we can rally all >>>>>> interested parties >>>> to >>>>>> comment on the existing published spec. So could you chairs >>>>>> please: >>>>>> >>>>>>>>>>>>>>>> propose a time line to the WG along those lines >>>> <<<<<<<<<<<< >>>>>>>>>>>>>>>> raise WG attention on this work? >>>> <<<<<<<<<<<< >>>>>> >>>>>> Also by or at Minneapolis, my sensation is that we should not >>>>>> only discuss the terms of deprecating RFC 4944 HC but also >>>>>> consider the spec as a whole: >>>>>> >>>>>> - Mesh Header is a layer violation. I talked to implementers and >>>> their >>>>>> message is that they do not use it because it's never exactely >>>>>> what that specific radio needs; so they end up with their own >>>>>> mesh header >>>> anyway >>>>>> and will not duplicate things for the sake of comliance. Instead >>>>>> we might need a Routing header, pretty useful for source routing >>>>>> in >>>> route >>>>>> over. >>>>>> >>>>>> - Fragments are not recovered individually. We have enough >>>>>> experience to know where that leads should a 6LoWPAN network >>>>>> experience either high load or high BER. We have a draft on the >>>>>> works to deprecate that with recoverable fragments. >>>>>> >>>>>> - The Current HC WG doc covers all the compression cases in RFC >>>>>> 4944, bigger and badder. >>>>>> >>>>>> So what's left? >>>>>> >>>>>> My proposal is to start a 4944bis that would focus on the >> addressing >>>>>> architecture, would be the placeholder to control the dispatch >>>>>> type but would defer to the drafts/RFCs that actually detail the >>>>>> operation >> of >>>>>> each dispatch type. >>>>>> >>>>>> What do you think? >>>>>> >>>>>> Pascal >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] >> On >>>>>> Behalf Of Carsten Bormann >>>>>>> Sent: jeudi 9 octobre 2008 16:43 >>>>>>> To: Julien Abeille (jabeille) >>>>>>> Cc: Carsten Bormann; 6lowpan@ietf.org >>>>>>> Subject: Re: [6lowpan] rfc4944, hc and dispatchs >>>>>>> >>>>>>> On Oct 09 2008, at 16:09, Julien Abeille (jabeille) wrote: >>>>>>> >>>>>>>> - does it officialy deprecate the old header compression scheme? >>>>>>> >>>>>>> My impression of the mailing list consensus is that this is what >>>>>>> the WG wants to achieve. >>>>>>> At the time this was discussed, I cautioned that it is premature >> to >>>>>>> decide on replacing something existing with known flaws with >>>>>>> something not yet quite cooked (and, hence, with unknown flaws). >>>>>>> So I expect we'll ultimately decide this question at the time HC >>>>>>> and the related specs come up for WGLC. >>>>>>> Clearly, the stated intention of many WG members is to make this >>>>>>> happen, as it would be wasteful to support two HC schemes in >>>>>>> tiny implementations. >>>>>>> >>>>>>> Gruesse, Carsten >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 6lowpan mailing list >>>>>>> 6lowpan@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>> _______________________________________________ >>>>>> 6lowpan mailing list >>>>>> 6lowpan@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>> >> > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 13 05:10:14 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 939AF28C0F8; Mon, 13 Oct 2008 05:10:14 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31AF828C0F8 for <6lowpan@core3.amsl.com>; Mon, 13 Oct 2008 05:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.414 X-Spam-Level: X-Spam-Status: No, score=-6.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLx0PAf1G+vo for <6lowpan@core3.amsl.com>; Mon, 13 Oct 2008 05:10:11 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3FD1E28C0E5 for <6lowpan@ietf.org>; Mon, 13 Oct 2008 05:10:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,403,1220227200"; d="scan'208";a="22437983" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 13 Oct 2008 12:10:50 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9DCAoxf004618; Mon, 13 Oct 2008 14:10:50 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9DCAoEU022172; Mon, 13 Oct 2008 12:10:50 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Oct 2008 14:10:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 13 Oct 2008 14:10:49 +0200 Message-ID: <38F26F36EAA981478A49D1F37F474A8602115F6F@xmb-ams-33d.emea.cisco.com> In-Reply-To: <38F26F36EAA981478A49D1F37F474A8602115F6A@xmb-ams-33d.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] rfc4944, hc and dispatchs Thread-Index: Ackq+ugV/DiDB1qsSoKk/BI6in6LxQCDoBogAAREFOAABBBXkAAAc8pQ References: <38F26F36EAA981478A49D1F37F474A86020D06DA@xmb-ams-33d.emea.cisco.com><105175C7-A788-4225-9E5A-845A07AA3621@tzi.org><7892795E1A87F04CADFCCF41FADD00FC065C29B2@xmb-ams-337.emea.cisco.com><641900E3-3665-4BED-9FA5-F8FB1667092F@archrock.com><7892795E1A87F04CADFCCF41FADD00FC065C2E40@xmb-ams-337.emea.cisco.com><7892795E1A87F04CADFCCF41FADD00FC065C2E70@xmb-ams-337.emea.cisco.com><38F26F36EAA981478A49D1F37F474A8602115D1F@xmb-ams-33d.emea.cisco.com><7892795E1A87F04CADFCCF41FADD00FC065C31F9@xmb-ams-337.emea.cisco.com> <38F26F36EAA981478A49D1F37F474A8602115F6A@xmb-ams-33d.emea.cisco.com> From: "Julien Abeille (jabeille)" To: "Julien Abeille (jabeille)" , "Pascal Thubert (pthubert)" , "Jonathan Hui" , "Carsten Bormann" , <6lowpan@ietf.org>, "Geoff Mulligan" X-OriginalArrivalTime: 13 Oct 2008 12:10:50.0676 (UTC) FILETIME=[BBA56740:01C92D2C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=13185; t=1223899850; x=1224763850; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20RE=3A=20[6lowpan]=20rfc4944,=20hc=20and=20dispa tchs |Sender:=20; bh=1V/QeBp9JabCKHiHU88ZhAAhDgurlKLIe6AVAzLpazM=; b=uSSdwXOIQgsoZbf21lpGouzkbK56AzZU2/3kcYIrVxh8pBVwOvONeSHXfh 8l9EQWwiLJQUBzE/NBslqOSMk1krZbVJT0Kv7VAEigRWnMtVKDL9FjBmyyWD xvOP+rjCsv; Authentication-Results: ams-dkim-1; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [6lowpan] rfc4944, hc and dispatchs X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Formatting problem, I resend: ----Original Message----- From: Pascal Thubert (pthubert) Sent: lundi 13 octobre 2008 12:16 To: Julien Abeille (jabeille); 'Jonathan Hui'; 'Carsten Bormann'; '6lowpan@ietf.org'; 'Geoff Mulligan' Subject: RE: [6lowpan] rfc4944, hc and dispatchs Consuming more and more of the dispatch space: - multiplies by 2 the number of consumed dispatches each time - reduces the space allocated for future extensions [Julien] As I said in my previous email, with all this in mind, I am convinced we can afford 32 values for HC (this is 13 bits, 5 in the dispatch, plus one byte) Do people agree that 32 values for HC is ok? - will require a revamp of 4944 right away with no backward compatibility [Julien] sure, do the chairs or people think we must take this as design constraint? It's very hard to reach a solution than will please all for all the various standpoints and priorities (smaller HC, lmarger coverage, smaller code, smaller memory...). And we could keep changing these formats forever. So we need rules and limits, in particular we need to keep in mind that: - Making implementation simpler or smaller is good - Making the base HC bigger is bad, every bit costs dearly [Julien] I think that as long as we do not need another BYTE and respect the maximum limit we fix, adding bits is at the contrary a very good point for simplicity and implementation size. - Compressing cases for which we have no known usage has very marginal value. [Julien] As we do not know what the typical usage will be in 12 month, I would avoid taking this as a design constraint. Again, I propose to make the best use possible of the bits we have. If do not have enough space to support some scenarios, then I am ok not to support them. Regards, Julien -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Julien Abeille (jabeille) Sent: lundi 13 octobre 2008 14:08 To: Pascal Thubert (pthubert); Jonathan Hui; Carsten Bormann; 6lowpan@ietf.org; Geoff Mulligan Subject: Re: [6lowpan] rfc4944, hc and dispatchs Hi Pascal, all, I comment inline -----Original Message----- From: Pascal Thubert (pthubert) Sent: lundi 13 octobre 2008 12:16 To: Julien Abeille (jabeille); 'Jonathan Hui'; 'Carsten Bormann'; '6lowpan@ietf.org'; 'Geoff Mulligan' Subject: RE: [6lowpan] rfc4944, hc and dispatchs Hi Julien: Pseudo code is good. Please remember that the reference is the current spec, so we need to compare pseudo code of a proposed change with pseudo code of that reference. In the reference, the compression of the pair of addresses is specifiied using 6 bits. Consuming more and more of the dispatch space: - multiplies by 2 the number of consumed dispatches each time - reduces the space allocated for future extensions [Julien] As I said in my previous email, with all this in mind, I am convinced we can afford 32 values for HC (this is 13 bits, 5 in the dispatch, plus one byte) Do people agree that 32 values for HC is ok? - will require a revamp of 4944 right away with no backward compatibility [Julien] sure, do the chairs or people think we must take this as design constraint? It's very hard to reach a solution than will please all for all the various standpoints and priorities (smaller HC, lmarger coverage, smaller code, smaller memory...). And we could keep changing these formats forever. So we need rules and limits, in particular we need to keep in mind that: - Making implementation simpler or smaller is good - Making the base HC bigger is bad, every bit costs dearly [Julien] I think that as long as we do not need another BYTE and respect the maximum limit we fix, adding bits is at the contrary a very good point for simplicity and implementation size. - Compressing cases for which we have no known usage has very marginal value. [Julien] As we do not know what the typical usage will be in 12 month, I would avoid taking this as a design constraint. Again, I propose to make the best use possible of the bits we have. If do not have enough space to support some scenarios, then I am ok not to support them. Regards, Julien Would you agree with that? Pascal >-----Original Message----- >From: Julien Abeille (jabeille) >Sent: lundi 13 octobre 2008 10:14 >To: Jonathan Hui; Pascal Thubert (pthubert); Carsten Bormann; >6lowpan@ietf.org; Geoff Mulligan >Subject: RE: [6lowpan] rfc4944, hc and dispatchs > >Hi Jonathan , all, > >I do not have particular use cases in mind for specific address types. > >My approach is the following: >- how many bits can we afford? >- with this amount of bits, let's try to support as many IP scenarios >as possible, keeping a low level of complexity and a high level of clarity. > >For the first question: >- there are currently around 150/255 dispatch values used. >- A priori I would be in favor of deprecating some (mesh, not a lowpan >frame), or at least do you agree they are less important than HC. This >would drag the number of values to 25/255 >- I do foresee some new 6lowpan specs will take some of them, but not >that many. Do you see anything else appart from fragment recovery? >Hence I am convinced taking 32 values is very acceptable (this is 8 >bits for address compression) Do you agree with this? > >For the second question: >- with 8 bits for address compression, we can do something very clean >and easy to implement, handling all IP addressing scenarios. > >I will send today an example on 8bits and pseudo code to be able to >compare 7-bit/8-bit complexity > >Regards, >Julien > > > >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >Behalf Of Jonathan Hui >Sent: vendredi 10 octobre 2008 19:09 >To: Pascal Thubert (pthubert) >Cc: Carsten Bormann; 6lowpan@ietf.org; Geoff Mulligan >Subject: Re: [6lowpan] rfc4944, hc and dispatchs > > >Hi Pascal, > >Yes, you are right - hc-01 supports all header values (just carry everything in-line). > >Regarding Julien's comments, I think hc-01 and the format proposed to >support Julien's cases are straight-forward to implement. I think the >more important issue is whether Julien's cases will be common in >6LoWPAN applications. We (Arch Rock) do not commonly use the cases that >Julien wishes to add compression for. But if Julien/others can demonstrate a strong need for them (i.e. cases that will be used fairly often in relevant 6LoWPAN applications), then I do think we should consider them. >Julien, can you explain important commonly used cases that would not be supported by hc-01? > >-- >Jonathan Hui > > > >On Oct 10, 2008, at 9:41 AM, Pascal Thubert (pthubert) wrote: > >> Hi Jonathan >> >> Maybe a good reason to stick to the current format and change the >> misleading wording around it, what do you think? In any case, I'm all >> for starting 4944bis and recoverable frags today, though. >> >> Pascal >> >>> -----Original Message----- >>> From: Jonathan Hui [mailto:jhui@archrock.com] >>> Sent: vendredi 10 octobre 2008 18:02 >>> To: Pascal Thubert (pthubert) >>> Cc: Carsten Bormann; Geoff Mulligan; 6lowpan@ietf.org >>> Subject: Re: [6lowpan] rfc4944, hc and dispatchs >>> >>> >>> Hi Pascal: >>> >>> I'm for pushing HC through as quickly as possible. We are already >>> behind according to the charter text. >>> >>> The one dependency I see is the structure of the dispatch byte. If >>> we choose a dispatch value(s) that is compatible with RFC 4944, then >>> we are fine, I think. But if we want extra bits by changing the >>> layout of the dispatch values/identifiers for Frag/Mesh headers (as >>> both I and Julien have proposed) then this creates a dependency on >>> defining that new dispatch assignment scheme. >>> >>> -- >>> Jonathan Hui >>> >>> >>> On Oct 10, 2008, at 8:51 AM, Pascal Thubert (pthubert) wrote: >>> >>>> I'm all with you, Jonathan, as long as that does not delay HC. >>>> >>>> This is why I proposed a structured set of document that leaves HC >>>> with its current scope as opposed to making it a full revision of >>>> 4944. >>>> Makes >>>> sense? >>>> >>>> Pascal >>>> >>>>> -----Original Message----- >>>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>>> Sent: jeudi 9 octobre 2008 21:17 >>>>> To: Pascal Thubert (pthubert) >>>>> Cc: Carsten Bormann; Geoff Mulligan; 6lowpan@ietf.org >>>>> Subject: Re: [6lowpan] rfc4944, hc and dispatchs >>>>> >>>>> >>>>> In general, I'm in support of Pascal's proposal. Cleaning up the >>>>> format to use a stacked-header format was just one of the items >>>>> and there were many other things we wanted to fix before pushing >>>>> out RFC 4944. But we were far too late to the game in doing a >>>>> complete overhaul of the doc. I think *now* is the time to make >>>>> improvements to RFC 4944. >>>>> >>>>> -- >>>>> Jonathan Hui >>>>> >>>>> >>>>> >>>>> On Oct 9, 2008, at 10:41 AM, Pascal Thubert (pthubert) wrote: >>>>> >>>>>> Hi Carsten: >>>>>> >>>>>> Some implementations and dependant standards would require a >>>>>> timeline for this. Leaving it up in the air does not help our >>>>>> users do their product planning? >>>>>> >>>>>> Considering the attention and the work on the new LOWPAN_IPHC, I >>>>>> expect that we'll be ready for WGLC after 2/3 more respins. That >>>>>> could be achieved by Minneapolis time if we can rally all >>>>>> interested parties >>>> to >>>>>> comment on the existing published spec. So could you chairs >>>>>> please: >>>>>> >>>>>>>>>>>>>>>> propose a time line to the WG along those lines >>>> <<<<<<<<<<<< >>>>>>>>>>>>>>>> raise WG attention on this work? >>>> <<<<<<<<<<<< >>>>>> >>>>>> Also by or at Minneapolis, my sensation is that we should not >>>>>> only discuss the terms of deprecating RFC 4944 HC but also >>>>>> consider the spec as a whole: >>>>>> >>>>>> - Mesh Header is a layer violation. I talked to implementers and >>>> their >>>>>> message is that they do not use it because it's never exactely >>>>>> what that specific radio needs; so they end up with their own >>>>>> mesh header >>>> anyway >>>>>> and will not duplicate things for the sake of comliance. Instead >>>>>> we might need a Routing header, pretty useful for source routing >>>>>> in >>>> route >>>>>> over. >>>>>> >>>>>> - Fragments are not recovered individually. We have enough >>>>>> experience to know where that leads should a 6LoWPAN network >>>>>> experience either high load or high BER. We have a draft on the >>>>>> works to deprecate that with recoverable fragments. >>>>>> >>>>>> - The Current HC WG doc covers all the compression cases in RFC >>>>>> 4944, bigger and badder. >>>>>> >>>>>> So what's left? >>>>>> >>>>>> My proposal is to start a 4944bis that would focus on the >> addressing >>>>>> architecture, would be the placeholder to control the dispatch >>>>>> type but would defer to the drafts/RFCs that actually detail the >>>>>> operation >> of >>>>>> each dispatch type. >>>>>> >>>>>> What do you think? >>>>>> >>>>>> Pascal >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] >> On >>>>>> Behalf Of Carsten Bormann >>>>>>> Sent: jeudi 9 octobre 2008 16:43 >>>>>>> To: Julien Abeille (jabeille) >>>>>>> Cc: Carsten Bormann; 6lowpan@ietf.org >>>>>>> Subject: Re: [6lowpan] rfc4944, hc and dispatchs >>>>>>> >>>>>>> On Oct 09 2008, at 16:09, Julien Abeille (jabeille) wrote: >>>>>>> >>>>>>>> - does it officialy deprecate the old header compression scheme? >>>>>>> >>>>>>> My impression of the mailing list consensus is that this is what >>>>>>> the WG wants to achieve. >>>>>>> At the time this was discussed, I cautioned that it is premature >> to >>>>>>> decide on replacing something existing with known flaws with >>>>>>> something not yet quite cooked (and, hence, with unknown flaws). >>>>>>> So I expect we'll ultimately decide this question at the time HC >>>>>>> and the related specs come up for WGLC. >>>>>>> Clearly, the stated intention of many WG members is to make this >>>>>>> happen, as it would be wasteful to support two HC schemes in >>>>>>> tiny implementations. >>>>>>> >>>>>>> Gruesse, Carsten >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 6lowpan mailing list >>>>>>> 6lowpan@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>> _______________________________________________ >>>>>> 6lowpan mailing list >>>>>> 6lowpan@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>> >> > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 13 08:29:29 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 537F93A6A3C; Mon, 13 Oct 2008 08:29:29 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB7503A6A3C for <6lowpan@core3.amsl.com>; Mon, 13 Oct 2008 08:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VULxfLTz3c5i for <6lowpan@core3.amsl.com>; Mon, 13 Oct 2008 08:29:26 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 303493A6988 for <6lowpan@ietf.org>; Mon, 13 Oct 2008 08:29:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,403,1220227200"; d="scan'208";a="22469590" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 13 Oct 2008 15:29:43 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9DFThWS016045; Mon, 13 Oct 2008 17:29:43 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9DFTg8Z011713; Mon, 13 Oct 2008 15:29:43 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Oct 2008 17:29:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 13 Oct 2008 17:29:38 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC065C3409@xmb-ams-337.emea.cisco.com> In-Reply-To: <38F26F36EAA981478A49D1F37F474A8602115F6F@xmb-ams-33d.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] rfc4944, hc and dispatchs Thread-Index: Ackq+ugV/DiDB1qsSoKk/BI6in6LxQCDoBogAAREFOAABBBXkAAAc8pQAARRthA= References: <38F26F36EAA981478A49D1F37F474A86020D06DA@xmb-ams-33d.emea.cisco.com><105175C7-A788-4225-9E5A-845A07AA3621@tzi.org><7892795E1A87F04CADFCCF41FADD00FC065C29B2@xmb-ams-337.emea.cisco.com><641900E3-3665-4BED-9FA5-F8FB1667092F@archrock.com><7892795E1A87F04CADFCCF41FADD00FC065C2E40@xmb-ams-337.emea.cisco.com><7892795E1A87F04CADFCCF41FADD00FC065C2E70@xmb-ams-337.emea.cisco.com><38F26F36EAA981478A49D1F37F474A8602115D1F@xmb-ams-33d.emea.cisco.com><7892795E1A87F04CADFCCF41FADD00FC065C31F9@xmb-ams-337.emea.cisco.com> <38F26F36EAA981478A49D1F37F474A8602115F6A@xmb-ams-33d.emea.cisco.com> <38F26F36EAA981478A49D1F37F474A8602115F6F@xmb-ams-33d.emea.cisco.com> From: "Pascal Thubert (pthubert)" To: "Julien Abeille (jabeille)" , "Jonathan Hui" , "Carsten Bormann" , <6lowpan@ietf.org>, "Geoff Mulligan" X-OriginalArrivalTime: 13 Oct 2008 15:29:43.0721 (UTC) FILETIME=[844B9190:01C92D48] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14593; t=1223911783; x=1224775783; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20rfc4944,=20hc=20and=20dispa tchs |Sender:=20; bh=WDZ4sehct6DIVeF62tpWcNDWaVu/guckI0T8o1977ec=; b=se5Orwqtzf8kyVh2+Qk5OWcZRrCxIUnBPxN1npZSZoRlbMetWlEp7F7Lnw cxpgbjvw+qY4dmBC3wXrPCQY0UzI+TzFapqEB+IGUJMJh9amwfFvE6HjfO5Z sohS/ezxfD; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [6lowpan] rfc4944, hc and dispatchs X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Julien: I suspect that the typical usage of IPv6 addresses in LoWPAN next year will not be that different from the typical usages of IPv6 addresses today; in particular the matching between source and destination scopes that the draft supports is very classical to what SAS does though some applications like ping will enable otherwise. What is a lot less clear to me is the usage of other fields, RH, options headers, etc... Additional dispatch bits might become handy when we figure that out and I'd not lock too many of them if we can avoid that. Like I said we have a reference. If you show clear improvement for acceptable cost, then I'm sure the group will be interested. Let's see what the clear improvement comes first, and then we'll see if the cost is acceptable for that improvement. In particular, I'd wish to understand the benefits on the resulting implementation. Pascal >-----Original Message----- >From: Julien Abeille (jabeille) >Sent: lundi 13 octobre 2008 14:11 >To: Julien Abeille (jabeille); Pascal Thubert (pthubert); Jonathan Hui; Carsten Bormann; >6lowpan@ietf.org; Geoff Mulligan >Subject: RE: [6lowpan] rfc4944, hc and dispatchs > >Formatting problem, I resend: > >----Original Message----- >From: Pascal Thubert (pthubert) >Sent: lundi 13 octobre 2008 12:16 >To: Julien Abeille (jabeille); 'Jonathan Hui'; 'Carsten Bormann'; '6lowpan@ietf.org'; 'Geoff >Mulligan' >Subject: RE: [6lowpan] rfc4944, hc and dispatchs > > >Consuming more and more of the dispatch space: >- multiplies by 2 the number of consumed dispatches each time >- reduces the space allocated for future extensions > >[Julien] As I said in my previous email, with all this in mind, I am convinced we can afford 32 >values for HC (this is 13 bits, 5 in the dispatch, plus one byte) Do people agree that 32 values for >HC is ok? > >- will require a revamp of 4944 right away with no backward compatibility > >[Julien] sure, do the chairs or people think we must take this as design constraint? > >It's very hard to reach a solution than will please all for all the various standpoints and >priorities (smaller HC, lmarger coverage, smaller code, smaller memory...). And we could keep >changing these formats forever. So we need rules and limits, in particular we need to keep in mind >that: >- Making implementation simpler or smaller is good >- Making the base HC bigger is bad, every bit costs dearly > >[Julien] I think that as long as we do not need another BYTE and respect the maximum limit we fix, >adding bits is at the contrary a very good point for simplicity and implementation size. > >- Compressing cases for which we have no known usage has very marginal value. > >[Julien] As we do not know what the typical usage will be in 12 month, I would avoid taking this as a >design constraint. Again, I propose to make the best use possible of the bits we have. If do not have >enough space to support some scenarios, then I am ok not to support them. > >Regards, >Julien > >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Julien Abeille >(jabeille) >Sent: lundi 13 octobre 2008 14:08 >To: Pascal Thubert (pthubert); Jonathan Hui; Carsten Bormann; 6lowpan@ietf.org; Geoff Mulligan >Subject: Re: [6lowpan] rfc4944, hc and dispatchs > >Hi Pascal, all, > >I comment inline > >-----Original Message----- >From: Pascal Thubert (pthubert) >Sent: lundi 13 octobre 2008 12:16 >To: Julien Abeille (jabeille); 'Jonathan Hui'; 'Carsten Bormann'; '6lowpan@ietf.org'; 'Geoff >Mulligan' >Subject: RE: [6lowpan] rfc4944, hc and dispatchs > >Hi Julien: > >Pseudo code is good. Please remember that the reference is the current spec, so we need to compare >pseudo code of a proposed change with pseudo code of that reference. In the reference, the >compression of the pair of addresses is specifiied using 6 bits. > > >Consuming more and more of the dispatch space: >- multiplies by 2 the number of consumed dispatches each time >- reduces the space allocated for future extensions [Julien] As I said in my previous email, with all >this in mind, I am convinced we can afford 32 values for HC (this is 13 bits, 5 in the dispatch, plus >one byte) Do people agree that 32 values for HC is ok? >- will require a revamp of 4944 right away with no backward compatibility [Julien] sure, do the >chairs or people think we must take this as design constraint? > >It's very hard to reach a solution than will please all for all the various standpoints and >priorities (smaller HC, lmarger coverage, smaller code, smaller memory...). And we could keep >changing these formats forever. So we need rules and limits, in particular we need to keep in mind >that: >- Making implementation simpler or smaller is good >- Making the base HC bigger is bad, every bit costs dearly [Julien] I think that as long as we do not >need another BYTE and respect the maximum limit we fix, adding bits is at the contrary a very good >point for simplicity and implementation size. >- Compressing cases for which we have no known usage has very marginal value. >[Julien] As we do not know what the typical usage will be in 12 month, I would avoid taking this as a >design constraint. Again, I propose to make the best use possible of the bits we have. If do not have >enough space to support some scenarios, then I am ok not to support them. > >Regards, >Julien > > >Would you agree with that? > >Pascal > >>-----Original Message----- >>From: Julien Abeille (jabeille) >>Sent: lundi 13 octobre 2008 10:14 >>To: Jonathan Hui; Pascal Thubert (pthubert); Carsten Bormann; >>6lowpan@ietf.org; Geoff Mulligan >>Subject: RE: [6lowpan] rfc4944, hc and dispatchs >> >>Hi Jonathan , all, >> >>I do not have particular use cases in mind for specific address types. >> >>My approach is the following: >>- how many bits can we afford? >>- with this amount of bits, let's try to support as many IP scenarios >>as possible, keeping a low level of complexity and a high level of >clarity. >> >>For the first question: >>- there are currently around 150/255 dispatch values used. >>- A priori I would be in favor of deprecating some (mesh, not a lowpan >>frame), or at least do you agree they are less important than HC. This >>would drag the number of values to 25/255 >>- I do foresee some new 6lowpan specs will take some of them, but not >>that many. Do you see anything else appart from fragment recovery? >>Hence I am convinced taking 32 values is very acceptable (this is 8 >>bits for address compression) Do you agree with this? >> >>For the second question: >>- with 8 bits for address compression, we can do something very clean >>and easy to implement, handling all IP addressing scenarios. >> >>I will send today an example on 8bits and pseudo code to be able to >>compare 7-bit/8-bit complexity >> >>Regards, >>Julien >> >> >> >>-----Original Message----- >>From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >>Behalf Of Jonathan Hui >>Sent: vendredi 10 octobre 2008 19:09 >>To: Pascal Thubert (pthubert) >>Cc: Carsten Bormann; 6lowpan@ietf.org; Geoff Mulligan >>Subject: Re: [6lowpan] rfc4944, hc and dispatchs >> >> >>Hi Pascal, >> >>Yes, you are right - hc-01 supports all header values (just carry >everything in-line). >> >>Regarding Julien's comments, I think hc-01 and the format proposed to >>support Julien's cases are straight-forward to implement. I think the >>more important issue is whether Julien's cases will be common in >>6LoWPAN applications. We (Arch Rock) do not commonly use the cases that > >>Julien wishes to add compression for. But if Julien/others can >demonstrate a strong need for them (i.e. cases that will be used fairly often in relevant 6LoWPAN >applications), then I do think we should consider them. >>Julien, can you explain important commonly used cases that would not be >supported by hc-01? >> >>-- >>Jonathan Hui >> >> >> >>On Oct 10, 2008, at 9:41 AM, Pascal Thubert (pthubert) wrote: >> >>> Hi Jonathan >>> >>> Maybe a good reason to stick to the current format and change the >>> misleading wording around it, what do you think? In any case, I'm all > >>> for starting 4944bis and recoverable frags today, though. >>> >>> Pascal >>> >>>> -----Original Message----- >>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>> Sent: vendredi 10 octobre 2008 18:02 >>>> To: Pascal Thubert (pthubert) >>>> Cc: Carsten Bormann; Geoff Mulligan; 6lowpan@ietf.org >>>> Subject: Re: [6lowpan] rfc4944, hc and dispatchs >>>> >>>> >>>> Hi Pascal: >>>> >>>> I'm for pushing HC through as quickly as possible. We are already >>>> behind according to the charter text. >>>> >>>> The one dependency I see is the structure of the dispatch byte. If >>>> we choose a dispatch value(s) that is compatible with RFC 4944, then > >>>> we are fine, I think. But if we want extra bits by changing the >>>> layout of the dispatch values/identifiers for Frag/Mesh headers (as >>>> both I and Julien have proposed) then this creates a dependency on >>>> defining that new dispatch assignment scheme. >>>> >>>> -- >>>> Jonathan Hui >>>> >>>> >>>> On Oct 10, 2008, at 8:51 AM, Pascal Thubert (pthubert) wrote: >>>> >>>>> I'm all with you, Jonathan, as long as that does not delay HC. >>>>> >>>>> This is why I proposed a structured set of document that leaves HC >>>>> with its current scope as opposed to making it a full revision of >>>>> 4944. >>>>> Makes >>>>> sense? >>>>> >>>>> Pascal >>>>> >>>>>> -----Original Message----- >>>>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>>>> Sent: jeudi 9 octobre 2008 21:17 >>>>>> To: Pascal Thubert (pthubert) >>>>>> Cc: Carsten Bormann; Geoff Mulligan; 6lowpan@ietf.org >>>>>> Subject: Re: [6lowpan] rfc4944, hc and dispatchs >>>>>> >>>>>> >>>>>> In general, I'm in support of Pascal's proposal. Cleaning up the >>>>>> format to use a stacked-header format was just one of the items >>>>>> and there were many other things we wanted to fix before pushing >>>>>> out RFC 4944. But we were far too late to the game in doing a >>>>>> complete overhaul of the doc. I think *now* is the time to make >>>>>> improvements to RFC 4944. >>>>>> >>>>>> -- >>>>>> Jonathan Hui >>>>>> >>>>>> >>>>>> >>>>>> On Oct 9, 2008, at 10:41 AM, Pascal Thubert (pthubert) wrote: >>>>>> >>>>>>> Hi Carsten: >>>>>>> >>>>>>> Some implementations and dependant standards would require a >>>>>>> timeline for this. Leaving it up in the air does not help our >>>>>>> users do their product planning? >>>>>>> >>>>>>> Considering the attention and the work on the new LOWPAN_IPHC, I >>>>>>> expect that we'll be ready for WGLC after 2/3 more respins. That >>>>>>> could be achieved by Minneapolis time if we can rally all >>>>>>> interested parties >>>>> to >>>>>>> comment on the existing published spec. So could you chairs >>>>>>> please: >>>>>>> >>>>>>>>>>>>>>>>> propose a time line to the WG along those lines >>>>> <<<<<<<<<<<< >>>>>>>>>>>>>>>>> raise WG attention on this work? >>>>> <<<<<<<<<<<< >>>>>>> >>>>>>> Also by or at Minneapolis, my sensation is that we should not >>>>>>> only discuss the terms of deprecating RFC 4944 HC but also >>>>>>> consider the spec as a whole: >>>>>>> >>>>>>> - Mesh Header is a layer violation. I talked to implementers and >>>>> their >>>>>>> message is that they do not use it because it's never exactely >>>>>>> what that specific radio needs; so they end up with their own >>>>>>> mesh header >>>>> anyway >>>>>>> and will not duplicate things for the sake of comliance. Instead >>>>>>> we might need a Routing header, pretty useful for source routing >>>>>>> in >>>>> route >>>>>>> over. >>>>>>> >>>>>>> - Fragments are not recovered individually. We have enough >>>>>>> experience to know where that leads should a 6LoWPAN network >>>>>>> experience either high load or high BER. We have a draft on the >>>>>>> works to deprecate that with recoverable fragments. >>>>>>> >>>>>>> - The Current HC WG doc covers all the compression cases in RFC >>>>>>> 4944, bigger and badder. >>>>>>> >>>>>>> So what's left? >>>>>>> >>>>>>> My proposal is to start a 4944bis that would focus on the >>> addressing >>>>>>> architecture, would be the placeholder to control the dispatch >>>>>>> type but would defer to the drafts/RFCs that actually detail the >>>>>>> operation >>> of >>>>>>> each dispatch type. >>>>>>> >>>>>>> What do you think? >>>>>>> >>>>>>> Pascal >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] >>> On >>>>>>> Behalf Of Carsten Bormann >>>>>>>> Sent: jeudi 9 octobre 2008 16:43 >>>>>>>> To: Julien Abeille (jabeille) >>>>>>>> Cc: Carsten Bormann; 6lowpan@ietf.org >>>>>>>> Subject: Re: [6lowpan] rfc4944, hc and dispatchs >>>>>>>> >>>>>>>> On Oct 09 2008, at 16:09, Julien Abeille (jabeille) wrote: >>>>>>>> >>>>>>>>> - does it officialy deprecate the old header compression >scheme? >>>>>>>> >>>>>>>> My impression of the mailing list consensus is that this is what > >>>>>>>> the WG wants to achieve. >>>>>>>> At the time this was discussed, I cautioned that it is premature >>> to >>>>>>>> decide on replacing something existing with known flaws with >>>>>>>> something not yet quite cooked (and, hence, with unknown flaws). >>>>>>>> So I expect we'll ultimately decide this question at the time HC > >>>>>>>> and the related specs come up for WGLC. >>>>>>>> Clearly, the stated intention of many WG members is to make this > >>>>>>>> happen, as it would be wasteful to support two HC schemes in >>>>>>>> tiny implementations. >>>>>>>> >>>>>>>> Gruesse, Carsten >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 6lowpan mailing list >>>>>>>> 6lowpan@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>>> _______________________________________________ >>>>>>> 6lowpan mailing list >>>>>>> 6lowpan@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>> >>> >> >>_______________________________________________ >>6lowpan mailing list >>6lowpan@ietf.org >>https://www.ietf.org/mailman/listinfo/6lowpan >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 13 08:35:48 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2D223A6AB9; Mon, 13 Oct 2008 08:35:48 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 618F63A69FE for <6lowpan@core3.amsl.com>; Mon, 13 Oct 2008 08:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJ9QBhvur0xK for <6lowpan@core3.amsl.com>; Mon, 13 Oct 2008 08:35:46 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 358CE3A6A99 for <6lowpan@ietf.org>; Mon, 13 Oct 2008 08:35:46 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 1F664AF86C; Mon, 13 Oct 2008 08:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSTwP5pANTV6; Mon, 13 Oct 2008 08:36:09 -0700 (PDT) Received: from [192.168.7.78] (69-12-164-140.sfo.archrock.com [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id 44A8EAF861; Mon, 13 Oct 2008 08:36:09 -0700 (PDT) Message-Id: <82EFF32E-3D4F-4A08-B851-A1DFDBF0C39C@archrock.com> From: Jonathan Hui To: Julien Abeille (jabeille) In-Reply-To: <38F26F36EAA981478A49D1F37F474A8602115D33@xmb-ams-33d.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 13 Oct 2008 08:36:08 -0700 References: <20081009021535.C8E823A6959@core3.amsl.com> <48EF5170.7050107@sensinode.com> <38F26F36EAA981478A49D1F37F474A8602115D33@xmb-ams-33d.emea.cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fwd: New Version Notification fordraft-ietf-6lowpan-hc-01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Julien, So here's the tension that we have now: From what I saw on the list, most people were happy with just two contexts. Adding support to the *base* encoding (i.e. without need of using a context identifier extension) would require adding yet another bit to the base encoding. This is in addition to whatever bits we may add depending on whether you convince us of those additional cases :-) Regarding 8 bits to encode address compression, I agree with Pascal in that you should compare against what is in ietf-6lowpan-hc-01 (6 bits). If we find need in supporting your cases, then we should compare to what I sent out to the mailing list (7 bits). I think the 7- bit version covers all the cases you were asking for, but maybe I missed some? Anyways, looking forward to see your 8-bit proposal. Thanks. -- Jonathan Hui On Oct 13, 2008, at 1:24 AM, Julien Abeille (jabeille) wrote: > Hi Zach, > > I second your concern > > There was recently a discussion specifically about the number of > contexts needed. > There seemed to be a consensus that multiple contexts was useful for > renumbering only, which is rare, and that 2 contexts was enough. > Was there new input since then which justifies the use of 4-bit > contexts? > > Cheers, > Julien > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Zach Shelby > Sent: vendredi 10 octobre 2008 14:58 > To: Jonathan Hui > Cc: 6lowpan > Subject: Re: [6lowpan] Fwd: New Version Notification > fordraft-ietf-6lowpan-hc-01 > > Hi, > > Here are my comments on hc-01. Overall I think we are quite close with > the comments from Pascal and Julien. > > I found the DDF name confusing. Now it has been renamed CTX in the > latest formats on the list, great. > > As Pascal pointed out, nodes need to be able to decode all these > options. One thing that worries me in having 16 contexts, is that > nodes > are forced to store them all. That is worst case 272 bytes of memory > consumption. Worth it? Is it possible that an ultra-simple node would > only have to understand the default context? > > The default context identifier '0000' could be clarified more in the > draft. When CTX is '10' then the default context identifier '0000' is > used. It should be made clear that this is the prefix advertised in > RAs > as useable for SAA. > > Regarding the ND for 6lowpan draft, HC-01 means we need to add a 4-bit > context identifier flag to the 6LoWPAN Prefix Information Option. To > make things clear that should always be '0000' if the A flag is '1'? > > - Zach > > > Jonathan Hui wrote: >> >> http://tools.ietf.org/html/draft-ietf-6lowpan-hc >> >> This new version reflects the recent discussions on the list. The >> changes are: >> - HC back to 1 byte by default by stealing a few bits from the >> dispatch field. >> - Added better support for multicast address compression. >> - Fixed alignment for UDP port compression. >> - Better support for Traffic Class and Flow Label compression. >> - Pascal joined as an author. >> >> Happy reading! >> >> -- >> Jonathan Hui >> >> >> >> Begin forwarded message: >> >>> From: IETF I-D Submission Tool >>> Date: October 8, 2008 7:15:35 PM PDT >>> To: jhui@archrock.com >>> Cc: pthubert@cisco.com >>> Subject: New Version Notification for draft-ietf-6lowpan-hc-01 >>> >>> >>> A new version of I-D, draft-ietf-6lowpan-hc-01.txt has been >>> successfuly submitted by Jonathan Hui and posted to the IETF > repository. >>> >>> Filename: draft-ietf-6lowpan-hc >>> Revision: 01 >>> Title: Compression Format for IPv6 Datagrams in 6LoWPAN > Networks >>> Creation_date: 2008-10-09 >>> WG ID: 6lowpan >>> Number_of_pages: 15 >>> >>> Abstract: >>> This document specifies an IPv6 header compression format for IPv6 >>> packet delivery in 6LoWPAN networks. The compression format relies >>> on shared context to allow compression of arbitrary prefixes. This >>> document specifies compression of multicast addresses and a >>> framework > >>> for compressing next headers. This framework specifies UDP >>> compression and is prepared for additional transports. >>> >>> >>> >>> The IETF Secretariat. >>> >>> >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > > -- > > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti > FINLAND > > mobile: +358 40 7796297 > > This e-mail and all attached material are confidential and may contain > legally privileged information. If you are not the intended recipient, > please contact the sender and delete the e-mail from your system > without > producing, distributing or retaining copies thereof. > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 13 11:17:47 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF9843A6849; Mon, 13 Oct 2008 11:17:46 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D0863A6849 for <6lowpan@core3.amsl.com>; Mon, 13 Oct 2008 11:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+0DGS5vknvR for <6lowpan@core3.amsl.com>; Mon, 13 Oct 2008 11:17:45 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 7B4E03A6820 for <6lowpan@ietf.org>; Mon, 13 Oct 2008 11:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m9DIIPtV011249; Mon, 13 Oct 2008 20:18:28 +0200 (CEST) Message-Id: <2B4A9FEA-B304-48C7-B399-13C6A48BF17B@tzi.org> From: Carsten Bormann To: Jonathan Hui In-Reply-To: <82EFF32E-3D4F-4A08-B851-A1DFDBF0C39C@archrock.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 13 Oct 2008 20:18:24 +0200 References: <20081009021535.C8E823A6959@core3.amsl.com> <48EF5170.7050107@sensinode.com> <38F26F36EAA981478A49D1F37F474A8602115D33@xmb-ams-33d.emea.cisco.com> <82EFF32E-3D4F-4A08-B851-A1DFDBF0C39C@archrock.com> X-Mailer: Apple Mail (2.929.2) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fwd: New Version Notification fordraft-ietf-6lowpan-hc-01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org On Oct 13 2008, at 17:36, Jonathan Hui wrote: > most people were happy with just two contexts Let me just point out that in the example I sent to the list on Jul 31, I used contexts for both the prefix of the 6lowpan and for prefixes of the main correspondent network. If you add the need for state transitions (renumbering, other reconfigurations), two seems low. I wouldn't mind an update of this example for HC-01. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 13 11:41:13 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 923CF28C17F; Mon, 13 Oct 2008 11:41:13 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4A1D28C17F for <6lowpan@core3.amsl.com>; Mon, 13 Oct 2008 11:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.43 X-Spam-Level: X-Spam-Status: No, score=-6.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HA49EclN2vVf for <6lowpan@core3.amsl.com>; Mon, 13 Oct 2008 11:41:11 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id BD7D928C128 for <6lowpan@ietf.org>; Mon, 13 Oct 2008 11:41:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,404,1220227200"; d="csv'?scan'208";a="22484705" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 13 Oct 2008 18:41:19 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9DIfIec028282; Mon, 13 Oct 2008 20:41:18 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9DIfIE5023566; Mon, 13 Oct 2008 18:41:18 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Oct 2008 20:41:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C92D63.46C6FCC8" Date: Mon, 13 Oct 2008 20:41:15 +0200 Message-ID: <38F26F36EAA981478A49D1F37F474A8602116249@xmb-ams-33d.emea.cisco.com> In-Reply-To: <82EFF32E-3D4F-4A08-B851-A1DFDBF0C39C@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fwd: New Version Notification fordraft-ietf-6lowpan-hc-01 Thread-Index: AcktSXDcgEhh/l/ISh+FTRykiqzBTwADhnog References: <20081009021535.C8E823A6959@core3.amsl.com> <48EF5170.7050107@sensinode.com> <38F26F36EAA981478A49D1F37F474A8602115D33@xmb-ams-33d.emea.cisco.com> <82EFF32E-3D4F-4A08-B851-A1DFDBF0C39C@archrock.com> From: "Julien Abeille (jabeille)" To: "Jonathan Hui" X-OriginalArrivalTime: 13 Oct 2008 18:41:18.0077 (UTC) FILETIME=[47771AD0:01C92D63] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10834; t=1223923278; x=1224787278; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20RE=3A=20[6lowpan]=20Fwd=3A=20New=20Version=20No tification=20fordraft-ietf-6lowpan-hc-01 |Sender:=20; bh=htjSkxYYp1EpRIx5XLL1mAROKl6HsStkluhu2bTT4/o=; b=hZ5ePkzgo4ByaS22sUttBs6WNSrp5PKhwTuvO2JF0gFRrjxzhD4+0A6juR R9pHiL68uqYxFbiSxLCMfhQNvZ1lqBY2j+a4CSkZiBRpQH7K+D29N4050TjU za/rW4pTVE; Authentication-Results: ams-dkim-1; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fwd: New Version Notification fordraft-ietf-6lowpan-hc-01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C92D63.46C6FCC8 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Jonathan, all, Sorry for the long email, tell me if not clear: ******************************************************* I agree with the status and the three possibilities: - 6 bits, most important cases compressed - 7 bits, all cases I mentionned compressed - 8 bits, all cases I mentionned compressed, simpler?=20 Time I propose something for 8-bits as you say :-) :=20 ***************************************************** 8 bit proposal: ***************************************************** - about contexts: 3 contexts stored, LL context (00), global prefix context 1 (01), global prefix context 2 (10, used for renumbering) - encoding: | SAC | SAM | DAC | DAM |, 2 bits each, as in initial draft. - meaning SAC: 00 context 00 01 context 01 10 context 10 11 no context SAM: If SAC =3D 00, 01, 10 prefix fetched from context number "SAC" 00 64 bits compressed 01 16 bits compressed 10 0 bits compressed If SAC =3D 11 00: unspecified 01: 128 bits inline DAC: 00 context 00 01 context 01 10 context 10 11 no context DAM: If DAC =3D 00, 01, 10 prefix fetched from context number "DAC" 00 unicast 64 bits compressed 01 unicast 16 bits compressed 10 unicast 0 bits compressed 11 multicast unicast prefix based FFxx::xxxx:plen:prefix:xxxx:xxxx If DAC =3D 11 00: 128 bits 01: FF02::xx 10: FF0x::00xx:xxxx 11: FF0x::00xx:xxxx:xxxx ****************************************** Comparison of 7 -bit and 8- bit is attached as csv, should open ok in Excel ****************************************** instead of pseudo code, I do the following:=20 - list all cases supported for src and dest formats (A to E for src, 1 to 9 for dest) - tell which combination of both are possible (e.g. A1, A2 ... Because not all combinations are accepted by IP) - for each combination, tell values of CTX and M bit for 7-bit, SAC, SAM, DAC DAM for 8-bit. I group the 64/16/0 IID cases to be more concise.=20 i.e. for src link local unicast and dest link local unicast CTX 00, M 0 - based on this, for each src and dest case splitted again, I give values of CTX, M i.e. if dest is FF0X::00XX:XXXX, CTX is ... What you can see: - with 8 bit, each individual case (A, B,... For src and 1,2... For dest ) corresponds to a unique value of SAC, SAM... - with 7 bits, some src cases corresponds to multiple values because they depend on the dest case, and vice versa For me, merging src and dest context add a lot of complexity. ****************************************** Comparison of 6-bit and 8- bit=20 ****************************************** I does not make a lot of sense on the complexity side, as they do not provide the same features. However, the binding between src and dest context in the 6 bit case creates the same problem as with 7 bit Cheers, Julien -----Original Message----- From: Jonathan Hui [mailto:jhui@archrock.com]=20 Sent: lundi 13 octobre 2008 17:36 To: Julien Abeille (jabeille) Cc: Zach Shelby; 6lowpan Subject: Re: [6lowpan] Fwd: New Version Notification fordraft-ietf-6lowpan-hc-01 Hi Julien, So here's the tension that we have now: From what I saw on the list, most people were happy with just two contexts. Adding support to the *base* encoding (i.e. without need of using a context identifier extension) would require adding yet another bit to the base encoding. =20 This is in addition to whatever bits we may add depending on whether you convince us of those additional cases :-) Regarding 8 bits to encode address compression, I agree with Pascal in that you should compare against what is in ietf-6lowpan-hc-01 (6 bits). If we find need in supporting your cases, then we should compare to what I sent out to the mailing list (7 bits). I think the 7- bit version covers all the cases you were asking for, but maybe I missed some? Anyways, looking forward to see your 8-bit proposal. Thanks. -- Jonathan Hui On Oct 13, 2008, at 1:24 AM, Julien Abeille (jabeille) wrote: > Hi Zach, > > I second your concern > > There was recently a discussion specifically about the number of=20 > contexts needed. > There seemed to be a consensus that multiple contexts was useful for=20 > renumbering only, which is rare, and that 2 contexts was enough. > Was there new input since then which justifies the use of 4-bit=20 > contexts? > > Cheers, > Julien > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On=20 > Behalf Of Zach Shelby > Sent: vendredi 10 octobre 2008 14:58 > To: Jonathan Hui > Cc: 6lowpan > Subject: Re: [6lowpan] Fwd: New Version Notification > fordraft-ietf-6lowpan-hc-01 > > Hi, > > Here are my comments on hc-01. Overall I think we are quite close with > the comments from Pascal and Julien. > > I found the DDF name confusing. Now it has been renamed CTX in the=20 > latest formats on the list, great. > > As Pascal pointed out, nodes need to be able to decode all these=20 > options. One thing that worries me in having 16 contexts, is that=20 > nodes are forced to store them all. That is worst case 272 bytes of=20 > memory consumption. Worth it? Is it possible that an ultra-simple node > would only have to understand the default context? > > The default context identifier '0000' could be clarified more in the=20 > draft. When CTX is '10' then the default context identifier '0000' is=20 > used. It should be made clear that this is the prefix advertised in=20 > RAs as useable for SAA. > > Regarding the ND for 6lowpan draft, HC-01 means we need to add a 4-bit > context identifier flag to the 6LoWPAN Prefix Information Option. To=20 > make things clear that should always be '0000' if the A flag is '1'? > > - Zach > > > Jonathan Hui wrote: >> >> http://tools.ietf.org/html/draft-ietf-6lowpan-hc >> >> This new version reflects the recent discussions on the list. The=20 >> changes are: >> - HC back to 1 byte by default by stealing a few bits from the=20 >> dispatch field. >> - Added better support for multicast address compression. >> - Fixed alignment for UDP port compression. >> - Better support for Traffic Class and Flow Label compression. >> - Pascal joined as an author. >> >> Happy reading! >> >> -- >> Jonathan Hui >> >> >> >> Begin forwarded message: >> >>> From: IETF I-D Submission Tool >>> Date: October 8, 2008 7:15:35 PM PDT >>> To: jhui@archrock.com >>> Cc: pthubert@cisco.com >>> Subject: New Version Notification for draft-ietf-6lowpan-hc-01 >>> >>> >>> A new version of I-D, draft-ietf-6lowpan-hc-01.txt has been=20 >>> successfuly submitted by Jonathan Hui and posted to the IETF > repository. >>> >>> Filename: draft-ietf-6lowpan-hc >>> Revision: 01 >>> Title: Compression Format for IPv6 Datagrams in 6LoWPAN > Networks >>> Creation_date: 2008-10-09 >>> WG ID: 6lowpan >>> Number_of_pages: 15 >>> >>> Abstract: >>> This document specifies an IPv6 header compression format for IPv6=20 >>> packet delivery in 6LoWPAN networks. The compression format relies=20 >>> on shared context to allow compression of arbitrary prefixes. This=20 >>> document specifies compression of multicast addresses and a=20 >>> framework > >>> for compressing next headers. This framework specifies UDP=20 >>> compression and is prepared for additional transports. >>> >>> >>> >>> The IETF Secretariat. >>> >>> >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > > -- > > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti > FINLAND > > mobile: +358 40 7796297 > > This e-mail and all attached material are confidential and may contain > legally privileged information. If you are not the intended recipient, > please contact the sender and delete the e-mail from your system=20 > without producing, distributing or retaining copies thereof. > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan ------_=_NextPart_001_01C92D63.46C6FCC8 Content-Type: application/octet-stream; name="hc.csv" Content-Transfer-Encoding: base64 Content-Description: hc.csv Content-Disposition: attachment; filename="hc.csv" U1JDIGNhc2VzOztERVNUIENBU0VTOw0KQTt1bmljYXN0IGxpbmsgbG9jYWw7MTt1bmljYXN0IGxp bmsgbG9jYWwNCkI7dW5pY2FzdCBnbG9iYWwgd2l0aCBjb250ZXh0IDE7Mjt1bmljYXN0IGdsb2Jh bCBjb250ZXh0IDENCkM7dW5pY2FzdCBnbG9iYWwgd2l0aCBjb250ZXh0IDI7Mzt1bmljYXN0IGds b2JhbCBjb250ZXh0IDINCkQ7dW5zcGVjaWZpZWQ7NDtGRjAyOjp4DQpFO25vdCBjb21wcmVzc2Vk OzU7RkYweDo6MDB4eDp4eHh4DQo7OzY7RkYweDo6MDB4eDp4eHh4Onh4eHgNCjs7Nzt1bmljYXN0 IHByZWZpeCBiYXNlZCBtdWx0aWNhc3Qgd2l0aCBjb250ZXh0IDENCjs7ODt1bmljYXN0IHByZWZp eCBiYXNlZCBtdWx0aWNhc3Qgd2l0aCBjb250ZXh0IDINCjs7OTtub3QgY29tcHJlc3NlZA0KOzs7 DQo7OzsNClBPU1NJQkxFIENPTUJJTkFUSU9OUztBMSw0LDUsNiw5OzsNCjtCMiwzLDUsNiw3LDgs OTs7DQo7QzIsMyw1LDYsNyw4LDk7Ow0KO0Q0LDUsNiw5OzsNCjtFMiwzLDUsNiw3LDgsOTs7DQoN ClZBTFVFUyBPRiBDVFgvTSBiaXQgZm9yIDcgYml0IGNvbXByZXNzaW9uIHBlciBjb21iaW5hdGlv bjs7Ow0KU1JDO0RFU1Q7NyBiaXQgQ1RYOzcgYml0IE0gYml0DQpBOzE7MHgwMDswDQo7NDsweDAw OzENCjs1OzB4MDA7MQ0KOzY7MHgwMDsxDQo7OTsweDAwOzANCkI7MjsweDEwOzANCjszOzB4MTE7 MA0KOzU7MHgxMDsxDQo7NjsweDEwOzENCjs3OzB4MTA7MQ0KOzg7MHgxMTsxDQo7OTsweDExOzAN CkM7MjsweDExOzANCjszOzB4MTE7MA0KOzU7MHgxMSBkZXN0IGhhcyBtZWFuaW5nbGVzcyBjb250 ZXh0OzENCjs2OzB4MTEgZGVzdCBoYXMgbWVhbmluZ2xlc3MgY29udGV4dDsxDQo7NzsweDExOzEN Cjs4OzB4MTE7MQ0KOzk7MHgxMSBkZXN0IGhhcyBtZWFuaW5nbGVzcyBjb250ZXh0OzANCkQ7NDsw eDAxOzENCjs1OzB4MDE7MQ0KOzY7MHgwMTsxDQo7OTsweDAxOzANCkU7MjsweDEwOzANCjszOzB4 MTE7MA0KOzU7MHgwMD87MQ0KOzY7MHgwMD87MQ0KOzc7MHgxMDsxDQo7ODsweDExIHNyYyBoYXMg bWVhbm5pbmdsZXNzIGNvbnRleHQ7MQ0KOzk7MHgwMDswDQoNClZBTFVFUyBPRiBDVFggZm9yIDct Yml0IGNvbXByZXNzaW9uLCBwZXIgc3JjIGFuZCBkZXN0IGluZGl2aWR1YWxseTs7Ow0KYTsweDAw OzsNCkI7MHgxMCwgMHgxMTs7DQpDOzB4MTE7Ow0KRDsweDAxOzsNCkU7MHgwMCwgMHgxMCwgMHgx MTs7DQoNCjE7MHgwMDs7DQoyOzB4MTAsIDB4MTE7Ow0KMzsweDExOzsNCjQ7MHgwMCwgMHgwMTs7 DQo1OzB4MDAsIDB4MTAsIDB4MTE7Ow0KNjsweDAwLCAweDEwLCAweDExOzsNCjc7MHgxMCwgMHgx MTsNCjg7MHgxMTsNCjk7MHgwMCwgMHgxMTsNCg0KVkFMVUVTIE9GIFNBQywgU0FNLCBEQUMsIERB TSBmb3IgOCBiaXQgY29tcHJlc3Npb247Ow0KU1JDO1NBQztTQU0NCmE7MHgwMDt4DQpiOzB4MDE7 eA0KYzsweDEwO3gNCmQ7MHgxMTswDQplOzB4MTE7MQ0KREVTVDtEQUM7REFNDQoxOzB4MDA7eA0K MjsweDAxO3gNCjM7MHgxMDt4DQo0OzB4MTE7MHgwMQ0KNTsweDExOzB4MTANCjY7MHgxMTsweDEx DQo3OzB4MDE7MHgxMQ0KODsweDEwOzB4MTENCjk7MHgxMTsweDAwDQo= ------_=_NextPart_001_01C92D63.46C6FCC8 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan ------_=_NextPart_001_01C92D63.46C6FCC8-- From 6lowpan-bounces@ietf.org Mon Oct 13 11:55:53 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12B1128C0E9; Mon, 13 Oct 2008 11:55:53 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED75B3A67F3 for <6lowpan@core3.amsl.com>; Mon, 13 Oct 2008 11:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxSu+xZ3mg5F for <6lowpan@core3.amsl.com>; Mon, 13 Oct 2008 11:55:50 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id AF13F3A63D2 for <6lowpan@ietf.org>; Mon, 13 Oct 2008 11:55:50 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id AE134AF89A; Mon, 13 Oct 2008 11:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lvERY0viWLB; Mon, 13 Oct 2008 11:56:04 -0700 (PDT) Received: from [192.168.7.78] (69-12-164-140.sfo.archrock.com [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id 9B075AF859; Mon, 13 Oct 2008 11:56:04 -0700 (PDT) Message-Id: <1D670358-DB62-48C0-86D4-03E6337E3C0F@archrock.com> From: Jonathan Hui To: Julien Abeille (jabeille) In-Reply-To: <38F26F36EAA981478A49D1F37F474A8602116249@xmb-ams-33d.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 13 Oct 2008 11:56:03 -0700 References: <20081009021535.C8E823A6959@core3.amsl.com> <48EF5170.7050107@sensinode.com> <38F26F36EAA981478A49D1F37F474A8602115D33@xmb-ams-33d.emea.cisco.com> <82EFF32E-3D4F-4A08-B851-A1DFDBF0C39C@archrock.com> <38F26F36EAA981478A49D1F37F474A8602116249@xmb-ams-33d.emea.cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fwd: New Version Notification fordraft-ietf-6lowpan-hc-01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Julien, everyone: Thanks for spelling this out in detail. This is exactly what I had in mind when I said we could support 2 contexts in the base encoding by adding another bit (going from 7 to 8). So you've saved me a bunch of work in showing how that could be done. I agree with you in all the points. So the real questions have been raised on the list. Unfortunately, they are less technical so there is more room to make subjective comments. Let me try to outline them here for discussion: 1) How many contexts to support? Many mentioned that two was enough. Carsten raised an issue when you use one of those contexts for the correspondent network. With only one context that can be used for the LoWPAN's prefix, nodes have to communicate uncompressed during the renumbering process. Is this acceptable? What do people think? 2) How much of the dispatch space do we give to HC? The latest proposal outlined by Julien requires 5 bits from the dispatch field, consuming 32 values. I have to agree that HC will be the most common dispatch value used, so it does make sense to give it priority. What do others think? -- Jonathan Hui On Oct 13, 2008, at 11:41 AM, Julien Abeille (jabeille) wrote: > Hi Jonathan, all, > > Sorry for the long email, tell me if not clear: > > ******************************************************* > I agree with the status and the three possibilities: > - 6 bits, most important cases compressed > - 7 bits, all cases I mentionned compressed > - 8 bits, all cases I mentionned compressed, simpler? > > > Time I propose something for 8-bits as you say :-) : > ***************************************************** > 8 bit proposal: > ***************************************************** > - about contexts: 3 contexts stored, LL context (00), global prefix > context 1 (01), global prefix context 2 (10, used for renumbering) > - encoding: > | SAC | SAM | DAC | DAM |, 2 bits each, as in initial draft. > > - meaning > SAC: > 00 context 00 > 01 context 01 > 10 context 10 > 11 no context > > SAM: > If SAC = 00, 01, 10 prefix fetched from context number "SAC" > 00 64 bits compressed > 01 16 bits compressed > 10 0 bits compressed > If SAC = 11 > 00: unspecified > 01: 128 bits inline > > DAC: > 00 context 00 > 01 context 01 > 10 context 10 > 11 no context > > DAM: > If DAC = 00, 01, 10 prefix fetched from context number "DAC" > 00 unicast 64 bits compressed > 01 unicast 16 bits compressed > 10 unicast 0 bits compressed > 11 multicast unicast prefix based FFxx::xxxx:plen:prefix:xxxx:xxxx > If DAC = 11 > 00: 128 bits > 01: FF02::xx > 10: FF0x::00xx:xxxx > 11: FF0x::00xx:xxxx:xxxx > > > ****************************************** > Comparison of 7 -bit and 8- bit is attached as csv, should open ok in > Excel > ****************************************** > instead of pseudo code, I do the following: > - list all cases supported for src and dest formats (A to E for src, 1 > to 9 for dest) > - tell which combination of both are possible (e.g. A1, A2 ... Because > not all combinations are accepted by IP) > - for each combination, tell values of CTX and M bit for 7-bit, SAC, > SAM, DAC DAM for 8-bit. I group the 64/16/0 IID cases to be more > concise. > i.e. for src link local unicast and dest link local unicast CTX 00, > M 0 > - based on this, for each src and dest case splitted again, I give > values of CTX, M > i.e. if dest is FF0X::00XX:XXXX, CTX is ... > > What you can see: > - with 8 bit, each individual case (A, B,... For src and 1,2... For > dest > ) corresponds to a unique value of SAC, SAM... > - with 7 bits, some src cases corresponds to multiple values because > they depend on the dest case, and vice versa > For me, merging src and dest context add a lot of complexity. > > ****************************************** > Comparison of 6-bit and 8- bit > ****************************************** > I does not make a lot of sense on the complexity side, as they do not > provide the same features. > However, the binding between src and dest context in the 6 bit case > creates the same problem as with 7 bit > > > Cheers, > Julien > > > > > > > > -----Original Message----- > From: Jonathan Hui [mailto:jhui@archrock.com] > Sent: lundi 13 octobre 2008 17:36 > To: Julien Abeille (jabeille) > Cc: Zach Shelby; 6lowpan > Subject: Re: [6lowpan] Fwd: New Version Notification > fordraft-ietf-6lowpan-hc-01 > > > Hi Julien, > > So here's the tension that we have now: From what I saw on the list, > most people were happy with just two contexts. Adding support to the > *base* encoding (i.e. without need of using a context identifier > extension) would require adding yet another bit to the base encoding. > This is in addition to whatever bits we may add depending on whether > you > convince us of those additional cases :-) > > Regarding 8 bits to encode address compression, I agree with Pascal in > that you should compare against what is in ietf-6lowpan-hc-01 (6 > bits). > If we find need in supporting your cases, then we should compare to > what > I sent out to the mailing list (7 bits). I think the 7- bit version > covers all the cases you were asking for, but maybe I missed some? > Anyways, looking forward to see your 8-bit proposal. > > Thanks. > > -- > Jonathan Hui > > > > On Oct 13, 2008, at 1:24 AM, Julien Abeille (jabeille) wrote: > >> Hi Zach, >> >> I second your concern >> >> There was recently a discussion specifically about the number of >> contexts needed. >> There seemed to be a consensus that multiple contexts was useful for >> renumbering only, which is rare, and that 2 contexts was enough. >> Was there new input since then which justifies the use of 4-bit >> contexts? >> >> Cheers, >> Julien >> >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >> Behalf Of Zach Shelby >> Sent: vendredi 10 octobre 2008 14:58 >> To: Jonathan Hui >> Cc: 6lowpan >> Subject: Re: [6lowpan] Fwd: New Version Notification >> fordraft-ietf-6lowpan-hc-01 >> >> Hi, >> >> Here are my comments on hc-01. Overall I think we are quite close >> with > >> the comments from Pascal and Julien. >> >> I found the DDF name confusing. Now it has been renamed CTX in the >> latest formats on the list, great. >> >> As Pascal pointed out, nodes need to be able to decode all these >> options. One thing that worries me in having 16 contexts, is that >> nodes are forced to store them all. That is worst case 272 bytes of >> memory consumption. Worth it? Is it possible that an ultra-simple >> node > >> would only have to understand the default context? >> >> The default context identifier '0000' could be clarified more in the >> draft. When CTX is '10' then the default context identifier '0000' is >> used. It should be made clear that this is the prefix advertised in >> RAs as useable for SAA. >> >> Regarding the ND for 6lowpan draft, HC-01 means we need to add a 4- >> bit > >> context identifier flag to the 6LoWPAN Prefix Information Option. To >> make things clear that should always be '0000' if the A flag is '1'? >> >> - Zach >> >> >> Jonathan Hui wrote: >>> >>> http://tools.ietf.org/html/draft-ietf-6lowpan-hc >>> >>> This new version reflects the recent discussions on the list. The >>> changes are: >>> - HC back to 1 byte by default by stealing a few bits from the >>> dispatch field. >>> - Added better support for multicast address compression. >>> - Fixed alignment for UDP port compression. >>> - Better support for Traffic Class and Flow Label compression. >>> - Pascal joined as an author. >>> >>> Happy reading! >>> >>> -- >>> Jonathan Hui >>> >>> >>> >>> Begin forwarded message: >>> >>>> From: IETF I-D Submission Tool >>>> Date: October 8, 2008 7:15:35 PM PDT >>>> To: jhui@archrock.com >>>> Cc: pthubert@cisco.com >>>> Subject: New Version Notification for draft-ietf-6lowpan-hc-01 >>>> >>>> >>>> A new version of I-D, draft-ietf-6lowpan-hc-01.txt has been >>>> successfuly submitted by Jonathan Hui and posted to the IETF >> repository. >>>> >>>> Filename: draft-ietf-6lowpan-hc >>>> Revision: 01 >>>> Title: Compression Format for IPv6 Datagrams in 6LoWPAN >> Networks >>>> Creation_date: 2008-10-09 >>>> WG ID: 6lowpan >>>> Number_of_pages: 15 >>>> >>>> Abstract: >>>> This document specifies an IPv6 header compression format for IPv6 >>>> packet delivery in 6LoWPAN networks. The compression format relies >>>> on shared context to allow compression of arbitrary prefixes. This >>>> document specifies compression of multicast addresses and a >>>> framework >> >>>> for compressing next headers. This framework specifies UDP >>>> compression and is prepared for additional transports. >>>> >>>> >>>> >>>> The IETF Secretariat. >>>> >>>> >>> >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >> >> -- >> >> Zach Shelby >> Head of Research >> Sensinode Ltd. >> Kidekuja 2 >> 88610 Vuokatti >> FINLAND >> >> mobile: +358 40 7796297 >> >> This e-mail and all attached material are confidential and may >> contain > >> legally privileged information. If you are not the intended >> recipient, > >> please contact the sender and delete the e-mail from your system >> without producing, distributing or retaining copies thereof. >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Oct 16 00:26:28 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 949F23A69AC; Thu, 16 Oct 2008 00:26:28 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EE9D3A6833 for <6lowpan@core3.amsl.com>; Thu, 16 Oct 2008 00:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQPuo6UDUICP for <6lowpan@core3.amsl.com>; Thu, 16 Oct 2008 00:26:27 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id BC5413A69AC for <6lowpan@ietf.org>; Thu, 16 Oct 2008 00:26:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,422,1220227200"; d="scan'208";a="22775897" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Oct 2008 07:27:26 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m9G7RQ3h032435; Thu, 16 Oct 2008 09:27:26 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9G7RQdA017279; Thu, 16 Oct 2008 07:27:26 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Oct 2008 09:27:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 16 Oct 2008 09:27:21 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0661E142@xmb-ams-337.emea.cisco.com> In-Reply-To: <2B4A9FEA-B304-48C7-B399-13C6A48BF17B@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Use of context / how many contexts Thread-Index: AcktYCC3CCaijaNhTneitry0Du0WrgCABdow References: <20081009021535.C8E823A6959@core3.amsl.com><48EF5170.7050107@sensinode.com><38F26F36EAA981478A49D1F37F474A8602115D33@xmb-ams-33d.emea.cisco.com><82EFF32E-3D4F-4A08-B851-A1DFDBF0C39C@archrock.com> <2B4A9FEA-B304-48C7-B399-13C6A48BF17B@tzi.org> From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" , "Jonathan Hui" X-OriginalArrivalTime: 16 Oct 2008 07:27:26.0534 (UTC) FILETIME=[A3A07E60:01C92F60] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3154; t=1224142046; x=1225006046; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20Use=20of=20context=20/=20how=20many=20contexts |Sender:=20; bh=H8UIoEX7EkQVHeDlqUV+F/3I0kYziTjekVKF/qgU4KQ=; b=lFiE7/D6UIB8K81zNzHCn3btuDh8W50GfCOXR5O812uTZ3gM/gc+snrpOK fneMGN8MR3eNVkybDnuSbVEGSZ3m11otO7f5HLkhG1FrNG0MUYkMKUhGMsRZ P3rCOEwGBl; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: [6lowpan] Use of context / how many contexts X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Carsten and all: I think we need to define context and usage in the architecture document, not in HC. Now, there's this recurrent question about how many contexts and what they are for: - It is very hard to know how many we need if we do not know what they are for in the first place. - Another question that is not answered if the scope of a context. What we have today: - The Current version of the HC WG doc uses contexts for anything stateful - The Current version of the HC WG doc enables up to 16 contexts. Following the current HC assumptions, a context can be used to compress anything down to /128. As Carsten mentions down here that includes remote prefixes; and it also enables to fully compress a number of much used addressed such as the application gateways and servers that the nodes publish to. There could be a number of those babies, thus the number 16. My proposal is the following: - It is the edge router responsibility to maintain the contexts in all nodes. The contexts are distributed by the edge routers through a new ND option that the ND draft introduces, valid in RAs and Router Registration Confirmation. - the scope of a context is the set of devices attached to an interface of that edge router. That is, it is guaranteed that entry 7 will means the same for all nodes attached to a same interface on a same edge router. - An edge router might use the same table on multiple interfaces. - For transparent mobility, it is allowed to have a common context table across the subnet - a context entry contains a prefix and a prefix length. Length can be 128. - entry 0 is the edge router global address - which context and how many there are (up to 16) is under the responsibility of the edge router (config, radius, ...) - if a node can not support as many contexts as the edge router requires, we can hope that it does not need them. - nodes should advertise how many contexts they can support max as they attach to a router (ND) - the router should store that in it ND cache and expand any address that the node can not understand - an new ICMP can be introduced to reject an unknown entry. What do you think? Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann >Sent: lundi 13 octobre 2008 20:18 >To: Jonathan Hui >Cc: Carsten Bormann; 6lowpan >Subject: Re: [6lowpan] Fwd: New Version Notificationfordraft-ietf-6lowpan-hc-01 > >On Oct 13 2008, at 17:36, Jonathan Hui wrote: > >> most people were happy with just two contexts > >Let me just point out that in the example I sent to the list on Jul >31, I used contexts for both the prefix of the 6lowpan and for >prefixes of the main correspondent network. If you add the need for >state transitions (renumbering, other reconfigurations), two seems low. > >I wouldn't mind an update of this example for HC-01. > >Gruesse, Carsten > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Oct 16 00:45:34 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50F663A6A60; Thu, 16 Oct 2008 00:45:34 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1894F3A692C for <6lowpan@core3.amsl.com>; Thu, 16 Oct 2008 00:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veR9-JbW5VpU for <6lowpan@core3.amsl.com>; Thu, 16 Oct 2008 00:45:28 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 3E3933A677D for <6lowpan@ietf.org>; Thu, 16 Oct 2008 00:45:28 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 9so1263344eyd.31 for <6lowpan@ietf.org>; Thu, 16 Oct 2008 00:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=vuVXDWVSjPMVo7cfnMipjAalSmTh+vPM/mI/aygaGGg=; b=ImQ2vK8CtDHVv+a24SHQw86xiWA++XYeTl7pOx9CQJDkFXMqfPBnpPwm0IW2Lq+ar0 vvFIPaJq0xv5nqwJN53DpPeBMOR0DsgyltpimthIJMvu2V0yOSW+xYtkgx5eh90XoBEz Eho3X3NGP2B35jlbYBhuJ2/HsjI7ja3s+LDHw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=iFG+lBmymdk/J7Kk8A2XxYnMEzm5NdOeCs1opvmbieSr4cZWBdtxWxzJteM8KVGdPa Nzl3Y/wbW7UJ20cc//uCBrbS7PAv7vwBpsG6011w3hZ/UEwWGa0eIZ4+jkFIu1nUybl4 G5SmfGRJ+pe2arUAv/gUx/x7CqU6VLJwqr7io= Received: by 10.103.176.20 with SMTP id d20mr1178501mup.136.1224143187068; Thu, 16 Oct 2008 00:46:27 -0700 (PDT) Received: by 10.102.244.7 with HTTP; Thu, 16 Oct 2008 00:46:26 -0700 (PDT) Message-ID: <147a29c80810160046w7fb7f1f0w8957f0999440aeb2@mail.gmail.com> Date: Thu, 16 Oct 2008 09:46:26 +0200 From: "Laurent Toutain" To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0661E142@xmb-ams-337.emea.cisco.com> MIME-Version: 1.0 References: <20081009021535.C8E823A6959@core3.amsl.com> <48EF5170.7050107@sensinode.com> <38F26F36EAA981478A49D1F37F474A8602115D33@xmb-ams-33d.emea.cisco.com> <82EFF32E-3D4F-4A08-B851-A1DFDBF0C39C@archrock.com> <2B4A9FEA-B304-48C7-B399-13C6A48BF17B@tzi.org> <7892795E1A87F04CADFCCF41FADD00FC0661E142@xmb-ams-337.emea.cisco.com> X-Google-Sender-Auth: 0d5db615b5639503 Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Use of context / how many contexts X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1599135052==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --===============1599135052== Content-Type: multipart/alternative; boundary="----=_Part_41710_15243977.1224143187064" ------=_Part_41710_15243977.1224143187064 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, On Thu, Oct 16, 2008 at 09:27, Pascal Thubert (pthubert) wrote: > Hi Carsten and all: > > I think we need to define context and usage in the architecture > document, not in HC. > > Now, there's this recurrent question about how many contexts and what > they are for: > - It is very hard to know how many we need if we do not know what they > are for in the first place. > - Another question that is not answered if the scope of a context. > > What we have today: > - The Current version of the HC WG doc uses contexts for anything > stateful > - The Current version of the HC WG doc enables up to 16 contexts. > A stupid question, DDF 10 context 0 is the same as the context DDF 01, in another way can you have up to 17 contexts ? > > Following the current HC assumptions, a context can be used to compress > anything down to /128. As Carsten mentions down here that includes > remote prefixes; and it also enables to fully compress a number of much > used addressed such as the application gateways and servers that the > nodes publish to. > > There could be a number of those babies, thus the number 16. > > My proposal is the following: > > - It is the edge router responsibility to maintain the contexts in all > nodes. The contexts are distributed by the edge routers through a new ND > option that the ND draft introduces, valid in RAs and Router > Registration Confirmation. It is something I don't understand. RA is for source prefix not destination prefix how sensors will know destination context. > > - the scope of a context is the set of devices attached to an interface > of that edge router. That is, it is guaranteed that entry 7 will means > the same for all nodes attached to a same interface on a same edge > router. > > - An edge router might use the same table on multiple interfaces. > > - For transparent mobility, it is allowed to have a common context table > across the subnet > > - a context entry contains a prefix and a prefix length. Length can be > 128. > > - entry 0 is the edge router global address > > - which context and how many there are (up to 16) is under the > responsibility of the edge router (config, radius, ...) > > - if a node can not support as many contexts as the edge router > requires, we can hope that it does not need them. > > - nodes should advertise how many contexts they can support max as they > attach to a router (ND) > > - the router should store that in it ND cache and expand any address > that the node can not understand > - an new ICMP can be introduced to reject an unknown entry. > > What do you think? I think this compression is good for sensors that stays in the same WSN, if a sensor is moving from one network to another (for instance parcel tracking) it may be very difficult to use that compression. Laurent > > > Pascal > > >-----Original Message----- > >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Carsten Bormann > >Sent: lundi 13 octobre 2008 20:18 > >To: Jonathan Hui > >Cc: Carsten Bormann; 6lowpan > >Subject: Re: [6lowpan] Fwd: New Version > Notificationfordraft-ietf-6lowpan-hc-01 > > > >On Oct 13 2008, at 17:36, Jonathan Hui wrote: > > > >> most people were happy with just two contexts > > > >Let me just point out that in the example I sent to the list on Jul > >31, I used contexts for both the prefix of the 6lowpan and for > >prefixes of the main correspondent network. If you add the need for > >state transitions (renumbering, other reconfigurations), two seems low. > > > >I wouldn't mind an update of this example for HC-01. > > > >Gruesse, Carsten > > > >_______________________________________________ > >6lowpan mailing list > >6lowpan@ietf.org > >https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > ------=_Part_41710_15243977.1224143187064 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,

On Thu, Oct 16, 2008 at 09:27, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
Hi Carsten and all:

I think we need to define context and usage in the architecture
document, not in HC.

Now, there's this recurrent question about how many contexts and what
they are for:
- It is very hard to know how many we need if we do not know what they
are for in the first place.
- Another question that is not answered if the scope of a context.

What we have today:
- The Current version of the HC WG doc uses contexts for anything
stateful
- The Current version of the HC WG doc enables up to 16 contexts.

A stupid question, DDF 10 context 0 is the same as the context DDF 01, in another way can you have up to 17 contexts ?
 

Following the current HC assumptions, a context can be used to compress
anything down to /128. As Carsten mentions down here that includes
remote prefixes; and it also enables to fully compress a number of much
used addressed such as the application gateways and servers that the
nodes publish to.

There could be a number of those babies, thus the number 16.

My proposal is the following:

- It is the edge router responsibility to maintain the contexts in all
nodes. The contexts are distributed by the edge routers through a new ND
option that the ND draft introduces, valid in RAs and Router
Registration Confirmation.

It is something I don't understand. RA is for source prefix not destination prefix how sensors will know destination context.



- the scope of a context is the set of devices attached to an interface
of that edge router. That is, it is guaranteed that entry 7 will means
the same for all nodes attached to a same interface on a same edge
router.

- An edge router might use the same table on multiple interfaces.

- For transparent mobility, it is allowed to have a common context table
across the subnet

- a context entry contains a prefix and a prefix length. Length can be
128.

- entry 0 is the edge router global address

- which context and how many there are (up to 16) is under the
responsibility of the edge router (config, radius, ...)

- if a node can not support as many contexts as the edge router
requires, we can hope that it does not need them.

- nodes should advertise how many contexts they can support max as they
attach to a router (ND)

- the router should store that in it ND cache and expand any address
that the node can not understand
- an new ICMP can be introduced to reject an unknown entry.

What do you think?
 
I think this compression is good  for sensors that stays in the same WSN, if a sensor is moving from one network to another (for instance parcel tracking) it may be very difficult to use that compression.
 

Laurent


Pascal

>-----Original Message-----
>From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On
Behalf Of Carsten Bormann
>Sent: lundi 13 octobre 2008 20:18
>To: Jonathan Hui
>Cc: Carsten Bormann; 6lowpan
>Subject: Re: [6lowpan] Fwd: New Version
Notificationfordraft-ietf-6lowpan-hc-01
>
>On Oct 13 2008, at 17:36, Jonathan Hui wrote:
>
>> most people were happy with just two contexts
>
>Let me just point out that in the example I sent to the list on Jul
>31, I used contexts for both the prefix of the 6lowpan and for
>prefixes of the main correspondent network.  If you add the need for
>state transitions (renumbering, other reconfigurations), two seems low.
>
>I wouldn't mind an update of this example for HC-01.
>
>Gruesse, Carsten
>
>_______________________________________________
>6lowpan mailing list
>6lowpan@ietf.org
>https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan


------=_Part_41710_15243977.1224143187064-- --===============1599135052== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan --===============1599135052==-- From 6lowpan-bounces@ietf.org Thu Oct 16 05:03:18 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 737163A6805; Thu, 16 Oct 2008 05:03:18 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21D4A3A6AA2 for <6lowpan@core3.amsl.com>; Thu, 16 Oct 2008 05:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reHzsbV8lGNt for <6lowpan@core3.amsl.com>; Thu, 16 Oct 2008 05:03:15 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 878873A6A75 for <6lowpan@ietf.org>; Thu, 16 Oct 2008 05:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m9GC42gW006968; Thu, 16 Oct 2008 14:04:05 +0200 (CEST) Message-Id: <361167B4-6DFE-4E85-AC8A-69983F7E3350@tzi.org> From: Carsten Bormann To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0661E142@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 16 Oct 2008 14:03:40 +0200 References: <20081009021535.C8E823A6959@core3.amsl.com><48EF5170.7050107@sensinode.com><38F26F36EAA981478A49D1F37F474A8602115D33@xmb-ams-33d.emea.cisco.com><82EFF32E-3D4F-4A08-B851-A1DFDBF0C39C@archrock.com> <2B4A9FEA-B304-48C7-B399-13C6A48BF17B@tzi.org> <7892795E1A87F04CADFCCF41FADD00FC0661E142@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Use of context / how many contexts X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Pascal, this is a great list of items. I'll try to explain my current thinking. > I think we need to define context and usage in the architecture > document, not in HC. Right. HC just needs to assume that there *is* a way the contexts are established between sender and receiver of an L2 packet. HC doesn't really care what the protocol is that establishes them (except, if it's not there, contexts can't be used). Right now, my working assumption is that the optimized ND will fill that gap. We cannot, however, ignore the likely properties of that context establishment protocol (let's call it CEP for now to avoid the question whether this is done in ND or elsewhere); I'll say some more about this below. > Now, there's this recurrent question about how many contexts and what > they are for: > - It is very hard to know how many we need if we do not know what they > are for in the first place. Right. In broken record mode: To go from gut feeling ("640K should be enough for everyone") to a better (and common) understanding, we need to agree on an example/a benchmark. See my message from Jul 31. (Continuing out of order:) > There could be a number of those babies, thus the number 16. The specific number should be decided when we know the trade-offs. In the original CBHC draft, I proposed 16 because I conflated the prefix length with the context number. I haven't heard any support for that idea. So maybe we need fewer than 16. See below. So: > - a context entry contains a prefix and a prefix length. Length can be > 128. Yes. It might also contain information about what is going to provide the remaining bits: Are they going to be in the header or are they inferred (e.g., from L2 addresses)? Of course, that information can also be in the header itself as separate bits, but this may be less efficient. Note that the same prefix can be used beneficially in both these modes. (We also need to decide how padding works if the bits in the header can be non-multiples of 8 in length.) Now, what is the cost of having too many contexts? -- Assuming that the prefix length is part of the context state, the cost of a context is: up to 16 bytes for the actual value, one byte (7 bits) for the prefix length, and one or two bytes for state management. Providing space for 16 contexts thus would mean that each node would need to reserve up to ~300 bytes of context state, a value high enough to merit some further discussion. -- The context ID needs to be encoded in the context-referencing header, once for each address. Since we probably also want to minimize complexity from variable-length and/or arithmetic encoding, supporting 16 contexts needs expending 2x4 = 8 bits. -- Of course, there is also a cost in state management. 300 bytes don't fit into one L2 MTU, for instance, possibly increasing the number of L2 packets needed for CEP. What is the cost of having too little contexts? Lost opportunities for compression (or, possibly the need to go for less compression where more would have been possible). > - if a node can not support as many contexts as the edge router > requires, we can hope that it does not need them. > > - nodes should advertise how many contexts they can support max as they > attach to a router (ND) Hope is not a strategy, and not a protocol either :-) If we allow heterogeneous context state within an area, we'll need to establish state between sender and receiver, whether with an explicit bilateral CEP or by storing per-peer state from error messages. I don't think we want to do this, so I would propose to go for homogeneous context state. > - It is the edge router responsibility to maintain the contexts in all > nodes. The contexts are distributed by the edge routers through a new ND > option that the ND draft introduces, valid in RAs and Router > Registration Confirmation. As I said, I'll call that "CEP" for now (but I do expect this to be part of optimized ND and to be controlled by a designated node such as an edge router). So: > - which context and how many there are (up to 16) is under the > responsibility of the edge router (config, radius, ...) Yes ("designated node" for this message). > - Another question that is not answered if the scope of a context. > [...] > - the scope of a context is the set of devices attached to an interface > of that edge router. That is, it is guaranteed that entry 7 will means > the same for all nodes attached to a same interface on a same edge > router. I'll skip the issue of what "attached to a same interface on a same edge router" means and just call these scopes "areas" for now. So, again, I'd agree and try to get homogeneous context state for an area. The assumption is that a node knows when it enters an area and can then use a CEP (i.e., ND) to establish the context state for this area. I also assume there will be other state associated with an area, so running a CEP is not going to dominate the cost of e.g. mobility. It also makes sense to assume some relationship between the area and address configuration information (such as prefixes used for stateless address configuration). > What we have today: > - The Current version of the HC WG doc uses contexts for anything > stateful > - The Current version of the HC WG doc enables up to 16 contexts. > > Following the current HC assumptions, a context can be used to compress > anything down to /128. As Carsten mentions down here that includes > remote prefixes; and it also enables to fully compress a number of much > used addressed such as the application gateways and servers that the > nodes publish to. Yep, but see above for the remaining bits. Finally, I don't really know what these of your points mean: > - An edge router might use the same table on multiple interfaces. > > - For transparent mobility, it is allowed to have a common context table > across the subnet Let me comment that "mobility" can be intra-area mobility (which is nothing but a routing change, so can be ignored here) or inter-area mobility (which requires reconfiguration anyway). Which one do you mean? > - entry 0 is the edge router global address We can always decide specific meanings for specific contexts, but I don't know what "the edge router global address" is and how a node would know it. > - the router should store that in it ND cache and expand any address > that the node can not understand In route-over, all nodes are routers, so I don't understand. > - an new ICMP can be introduced to reject an unknown entry. I explained above why I don't like relying on this for normal operation, but it's certainly a good idea to provide some diagnostic capability. So, thanks again, Pascal, for creating a good outline for discussion! Now, back to that number 16: I'm assuming that CEP will be extremely lightweight (not two-phase commit or some such :-). So whenever the context state for an area changes (and my assumption is that there is a need to allow it to change), there will be contexts for which some nodes in the area have new state and some are still on the old state. The CEP, of course, is designed to converge, so the assumption is there is a point in time when the new state actually can be used. But way before that point, nodes need to find out the new state while knowing they can't use it yet, and they need to stop using the old state. So, I think each context can have one of the following states: 00 unused (do not use, do not accept) 01 in introduction (do not actively use, but remember the state) 11 in use (i.e., nodes assume all other nodes know the state) 10 in deprecation (do not actively use, but remember the state) (01 and 10 are very similar in the way a node should handle them, so it may be possible to combine them in CEP's encoding). 00 does not have a value associated; the other three need a value and each node needs to allow receiving headers referencing the context: 01 in case another node switches to 11 earlier and starts using the context, 10 in case another node hasn't got the memo and still thinks the context is in 11 state. This is also the reason a context can't be in 01 and 10 at the same time (i.e., cannot simply get descructively updated with a new value): a receiving node would not know whether to apply the old or the new value to a compressed header. (This can be solved with any number of methods like generation numbers etc., but this creates complexity and needs even more bits.) So if we assume a transition time Tt within which a designated node can update an area to new values with a level of probability deemed acceptable, each specific context can be useless for 2*Tt, requiring the use of another context number if continued context-based compression during a transition is desired. This is the reason why we may need more potential context values than any static context state configuration might suggest. How many, of course, depends on our model of the dynamicity of the context state, which is (broken-record mode) the reason we need benchmarks to finish this discussion. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Oct 16 07:24:40 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD1EB3A68D1; Thu, 16 Oct 2008 07:24:40 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4142A3A63D3 for <6lowpan@core3.amsl.com>; Thu, 16 Oct 2008 07:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id feLn6d67O-is for <6lowpan@core3.amsl.com>; Thu, 16 Oct 2008 07:24:27 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 798723A67E6 for <6lowpan@ietf.org>; Thu, 16 Oct 2008 07:24:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,423,1220227200"; d="scan'208,217";a="22838962" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Oct 2008 14:25:18 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m9GEPIor023569; Thu, 16 Oct 2008 16:25:18 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9GEPIpg026017; Thu, 16 Oct 2008 14:25:18 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Oct 2008 16:25:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 16 Oct 2008 16:25:17 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0661E453@xmb-ams-337.emea.cisco.com> In-Reply-To: <147a29c80810160046w7fb7f1f0w8957f0999440aeb2@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Use of context / how many contexts Thread-Index: AckvY2MC4yUGgKhFQduMjh8Pv08WGQAK+Mow References: <20081009021535.C8E823A6959@core3.amsl.com> <48EF5170.7050107@sensinode.com> <38F26F36EAA981478A49D1F37F474A8602115D33@xmb-ams-33d.emea.cisco.com> <82EFF32E-3D4F-4A08-B851-A1DFDBF0C39C@archrock.com> <2B4A9FEA-B304-48C7-B399-13C6A48BF17B@tzi.org> <7892795E1A87F04CADFCCF41FADD00FC0661E142@xmb-ams-337.emea.cisco.com> <147a29c80810160046w7fb7f1f0w8957f0999440aeb2@mail.gmail.com> From: "Pascal Thubert (pthubert)" To: "Laurent Toutain" X-OriginalArrivalTime: 16 Oct 2008 14:25:17.0861 (UTC) FILETIME=[034D6550:01C92F9B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=24631; t=1224167118; x=1225031118; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20Use=20of=20context=20/=20ho w=20many=20contexts |Sender:=20; bh=F/fb5trQaPsgwcsn/dIeJX/o3m/zjyTkCUVbbbLZ7c4=; b=I0NLkf4w3MnwgY6fiHAQxD0IJxE1gvwGaGL4zl+PLCxHyhp+D2AVVlxYej 8TwMWj/QHZwzi113sxUnxK8YuODTPRmik6MTGjzm5fnFC8w1zUaZIgXKxkO9 jJtM1Ieb3f; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Use of context / how many contexts X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1069406881==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============1069406881== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C92F9B.02FE81FF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C92F9B.02FE81FF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Salut Laurent :-) What we have today: - The Current version of the HC WG doc uses contexts for anything stateful - The Current version of the HC WG doc enables up to 16 contexts. A stupid question, DDF 10 context 0 is the same as the context DDF 01, in another way can you have up to 17 contexts ? [Pascal] You're behind by one version; see http://tools.ietf.org/id/draft-ietf-6lowpan-hc-01.txt=20 =20 =09 Following the current HC assumptions, a context can be used to compress anything down to /128. As Carsten mentions down here that includes remote prefixes; and it also enables to fully compress a number of much used addressed such as the application gateways and servers that the nodes publish to. =09 There could be a number of those babies, thus the number 16. =09 My proposal is the following: =09 - It is the edge router responsibility to maintain the contexts in all nodes. The contexts are distributed by the edge routers through a new ND option that the ND draft introduces, valid in RAs and Router Registration Confirmation. It is something I don't understand. RA is for source prefix not destination prefix how sensors will know destination context.=20 [Pascal] we need something like Carsten's CEP to sync all the nodes in the contxet scope/ Now a context entry (say an address) can be used source or destination. For instance, if many sensors are publishing their data to server 2001::1 then we could use a context entry for 2001::1. Context 3 would be the destinarion context for publishing and the source for subscribing. Say that the sensor network is 2002::/64 and we have sensor with IP address is based on EUI-48 following RFC4944 addressing. I assume here that context 0 is the default context, (and BTW that is contains the full address of the edge router) and a prefix length of 64. We'll end up with a 3 bytes dispatch + HC. For publishin we'll get: =20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 =20 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+--- +---+---+---+---+---+---+ | 0 | 1 | 0 | 0 | 1 | TF |NH | HLIM | DDF | SAM | DAM | src context | dest context | =20 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+--- +---+---+---+---+---+---+ =20 =20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 =20 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+--- +---+---+---+---+---+---+ | 0 | 1 | 0 | 0 | 1 | TF |NH | HLIM | 0 1 | 0 1 | 1 | 1 | 0 | 3 | =20 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+--- +---+---+---+---+---+---+ =20 DDF: Destination Dependant Field: 01: Destination and Source are Global or Unique Local Addresses and one additional context octet extends the LOWPAN_IPHC field to disambiguate an elided prefix or address described by the SAM or DAM fields. =20 SAM: Source Address Mode: When the Destination is a Global or Unique Local Addresses: 01: 64 bits: the prefix of Source Address is elided. =20 DAM: Destination Address Mode: When the Destination is a Global or Unique Local Addresses: 11: 0 bit: The Destination Address is fully elided. =20 =20 =20 =09 =09 - the scope of a context is the set of devices attached to an interface of that edge router. That is, it is guaranteed that entry 7 will means the same for all nodes attached to a same interface on a same edge router. =09 - An edge router might use the same table on multiple interfaces. =09 - For transparent mobility, it is allowed to have a common context table across the subnet =09 - a context entry contains a prefix and a prefix length. Length can be 128. =09 - entry 0 is the edge router global address =09 - which context and how many there are (up to 16) is under the responsibility of the edge router (config, radius, ...) =09 - if a node can not support as many contexts as the edge router requires, we can hope that it does not need them. =09 - nodes should advertise how many contexts they can support max as they attach to a router (ND) =09 - the router should store that in it ND cache and expand any address that the node can not understand - an new ICMP can be introduced to reject an unknown entry. =09 What do you think? =20 I think this compression is good for sensors that stays in the same WSN, if a sensor is moving from one network to another (for instance parcel tracking) it may be very difficult to use that compression.=20 =20 Well, the sensor as it moves away from its subnet will have to form a new address. Part of thart process will be to learn contexts. Hopefully this can be done within existing flows.=20 The context is not supposed to change too often or the node to move very rapidly between subnets. There are limits where another technology with more power becomes necessary. Laurent =09 =09 Pascal =09 >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann >Sent: lundi 13 octobre 2008 20:18 >To: Jonathan Hui >Cc: Carsten Bormann; 6lowpan >Subject: Re: [6lowpan] Fwd: New Version Notificationfordraft-ietf-6lowpan-hc-01 > >On Oct 13 2008, at 17:36, Jonathan Hui wrote: > >> most people were happy with just two contexts > >Let me just point out that in the example I sent to the list on Jul >31, I used contexts for both the prefix of the 6lowpan and for >prefixes of the main correspondent network. If you add the need for >state transitions (renumbering, other reconfigurations), two seems low. > >I wouldn't mind an update of this example for HC-01. > >Gruesse, Carsten > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan =20 ------_=_NextPart_001_01C92F9B.02FE81FF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Salut Laurent J


What we have today:
- The Current version of the HC WG doc uses contexts for anything
stateful
- The Current version of the HC WG doc enables up to 16 = contexts.


A stupid question, DDF 10 context 0 is the same as the context DDF 01, = in another way can you have up to 17 contexts ?

[Pascal] You’re behind by one version; see http://too= ls.ietf.org/id/draft-ietf-6lowpan-hc-01.txt

 


Following the current HC assumptions, a context can be used to = compress
anything down to /128. As Carsten mentions down here that includes
remote prefixes; and it also enables to fully compress a number of = much
used addressed such as the application gateways and servers that the
nodes publish to.

There could be a number of those babies, thus the number 16.

My proposal is the following:

- It is the edge router responsibility to maintain the contexts in = all
nodes. The contexts are distributed by the edge routers through a new = ND
option that the ND draft introduces, valid in RAs and Router
Registration Confirmation.


It is something I don't understand. RA is for source prefix not = destination prefix how sensors will know destination context. =

[Pascal] we need something like = Carsten’s CEP to sync all the nodes in the contxet scope/ Now a context entry (say = an address) can be used source or = destination.

For instance, if many sensors are publishing their data to server 2001::1 then we could use a context = entry for 2001::1. Context 3 would be the destinarion context for publishing and = the source for subscribing.

Say that the sensor network is = 2002::/64 and we have sensor with IP address is based on EUI-48 following RFC4944 addressing.

I assume here that context 0 is the = default context, (and BTW that is contains the full address of the edge router) =  and a prefix length of 64.

We’ll end up with a 3 bytes = dispatch + HC. For publishin we’ll = get:

 
       =
0   1   2   3   4   =
5   6   7   8   9   =
0   1   2   3   4   =
5   6   7   8   9   0 =
  1   2 =
  3
     =
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+=
---+---+---+---+---+---+
     | 0 | 1 | 0 | 0 | 1 =
|  TF   |NH | HLIM  |  DDF  |  =
SAM  |  DAM  |  src context  | dest =
context  |
     =
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+=
---+---+---+---+---+---+
 
 
       =
0   1   2   3   4   =
5   6   7   8   9   =
0   1   2   3   4   5 =
  6   7   8   9   0 =
  1   2 =
  3
     =
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+=
---+---+---+---+---+---+
     | 0 | 1 | 0 | 0 | 1 =
|  TF   |NH | HLIM  | 0   1 | 0 =
  1 | 1 | 1 |      =
0        =
|       3      =
 |
     =
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+=
---+---+---+---+---+---+

 

DDF: Destination Dependant =
Field:
  =
01:  Destination and Source are Global or Unique Local =
Addresses
       &nbs=
p; and one additional context octet extends the LOWPAN_IPHC =
field
       &nbs=
p; to disambiguate an elided prefix or address described by =
the
       &nbs=
p; SAM or DAM fields.

 

SAM: Source Address =
Mode:
      When the =
Destination is a Global or Unique Local =
Addresses:
       =
01:  64 bits: the prefix of Source Address is =
elided.

 

DAM: Destination Address =
Mode:
      When the =
Destination is a Global or Unique Local =
Addresses:
       =
11:  0 bit: The Destination Address is fully =
elided.

 

 

 



- the scope of a context is the set of devices attached to an = interface
of that edge router. That is, it is guaranteed that entry 7 will = means
the same for all nodes attached to a same interface on a same edge
router.

- An edge router might use the same table on multiple interfaces.

- For transparent mobility, it is allowed to have a common context = table
across the subnet

- a context entry contains a prefix and a prefix length. Length can = be
128.

- entry 0 is the edge router global address

- which context and how many there are (up to 16) is under the
responsibility of the edge router (config, radius, ...)

- if a node can not support as many contexts as the edge router
requires, we can hope that it does not need them.

- nodes should advertise how many contexts they can support max as = they
attach to a router (ND)

- the router should store that in it ND cache and expand any address
that the node can not understand
- an new ICMP can be introduced to reject an unknown entry.

What do you think?

 

I think this compression is good  for sensors that stays in = the same WSN, if a sensor is moving from one network to another (for = instance parcel tracking) it may be very difficult to use that compression.
 

Well, the sensor as it moves away from its subnet = will have to form a new address. Part of thart process will be to learn contexts. Hopefully this can be done within existing flows. =

The context is not supposed to change too often or = the node to move very rapidly between subnets.  There are limits where another = technology with more power becomes necessary.


Laurent



Pascal

>-----Original Message-----
>From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On
Behalf Of Carsten Bormann
>Sent: lundi 13 octobre 2008 20:18
>To: Jonathan Hui
>Cc: Carsten Bormann; 6lowpan
>Subject: Re: [6lowpan] Fwd: New Version
Notificationfordraft-ietf-6lowpan-hc-01
>
>On Oct 13 2008, at 17:36, Jonathan Hui wrote:
>
>> most people were happy with just two contexts
>
>Let me just point out that in the example I sent to the list on = Jul
>31, I used contexts for both the prefix of the 6lowpan and for
>prefixes of the main correspondent network.  If you add the = need for
>state transitions (renumbering, other reconfigurations), two seems = low.
>
>I wouldn't mind an update of this example for HC-01.
>
>Gruesse, Carsten
>
>_______________________________________________
>6lowpan mailing list
>6lowpan@ietf.org
>https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan<= /o:p>

 

------_=_NextPart_001_01C92F9B.02FE81FF-- --===============1069406881== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan --===============1069406881==-- From 6lowpan-bounces@ietf.org Fri Oct 17 06:05:38 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 164DC3A69EB; Fri, 17 Oct 2008 06:05:38 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21FAD3A69EB for <6lowpan@core3.amsl.com>; Fri, 17 Oct 2008 06:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJAOTy1NC6A0 for <6lowpan@core3.amsl.com>; Fri, 17 Oct 2008 06:05:35 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A56E03A6814 for <6lowpan@ietf.org>; Fri, 17 Oct 2008 06:05:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,431,1220227200"; d="scan'208";a="22949092" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Oct 2008 13:05:56 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9HD5u75023036; Fri, 17 Oct 2008 15:05:56 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9HD5uMQ006120; Fri, 17 Oct 2008 13:05:56 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Oct 2008 15:05:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 17 Oct 2008 15:05:48 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC066729BE@xmb-ams-337.emea.cisco.com> In-Reply-To: <361167B4-6DFE-4E85-AC8A-69983F7E3350@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Use of context / how many contexts Thread-Index: Ackvh1IJStE0OZ0bSp23oHYu67roMwA0brAw References: <20081009021535.C8E823A6959@core3.amsl.com><48EF5170.7050107@sensinode.com><38F26F36EAA981478A49D1F37F474A8602115D33@xmb-ams-33d.emea.cisco.com><82EFF32E-3D4F-4A08-B851-A1DFDBF0C39C@archrock.com> <2B4A9FEA-B304-48C7-B399-13C6A48BF17B@tzi.org> <7892795E1A87F04CADFCCF41FADD00FC0661E142@xmb-ams-337.emea.cisco.com> <361167B4-6DFE-4E85-AC8A-69983F7E3350@tzi.org> From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" X-OriginalArrivalTime: 17 Oct 2008 13:05:56.0549 (UTC) FILETIME=[17C09750:01C93059] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10990; t=1224248756; x=1225112756; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20Use=20of=20context=20/=20ho w=20many=20contexts |Sender:=20; bh=hVaYcV6A5v8W3yWIKJAO98T7PeFFzj/auXMBiDSlNtg=; b=ARW8k7MDJ2WNQLq5uMf0tPLx9HfYP4w8UYQaNQiYraO1HwviiLHH+tcaO4 vaRUgOnK7IFm97fX0dTbMdx4l0rHvdG1UPdP7q40+XuRDI+Vm+4S/TXF5/Re ocjCuJPGJ8; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Use of context / how many contexts X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Carsten I'm not sure what you mean by Establishment? I had in mind that the context is there by untold magic and ND had to Distribute it. If the "Context Distribution Protocol" is part of ND then we have to specify it there but I'd not expect ND to tell how the context is built in the first place. I can agree that traditional RA might not be the right way, be it only for reasons of size. OTOH, a node might reactively read the white board to get the value of a context entry whenever it needs it so it would not need a table but a cache. RAs could carry a checksum of the entries; also, failure to compute the right checksum for a packet could indicate that the cache is obsolete. What you called an area and I called a scope could be simple if we agree it's the subnet. The subnet is the set on which we already do DAD and ND lookup. A node is free to move within its subnet without renumbering. Maybe mapping the area to a subnet limits number of contexts but for sure it keeps things simple and cleanly at L3, as opposed to using concepts like PAN ID . Anyway we seem to agree that 16 contexts is a good number. Pascal >-----Original Message----- >From: Carsten Bormann [mailto:cabo@tzi.org] >Sent: jeudi 16 octobre 2008 14:04 >To: Pascal Thubert (pthubert) >Cc: Carsten Bormann; Jonathan Hui; 6lowpan >Subject: Re: [6lowpan] Use of context / how many contexts > >Hi Pascal, > >this is a great list of items. >I'll try to explain my current thinking. > > > I think we need to define context and usage in the architecture > > document, not in HC. > >Right. HC just needs to assume that there *is* a way the contexts are >established between sender and receiver of an L2 packet. HC doesn't >really care what the protocol is that establishes them (except, if >it's not there, contexts can't be used). Right now, my working >assumption is that the optimized ND will fill that gap. > >We cannot, however, ignore the likely properties of that context >establishment protocol (let's call it CEP for now to avoid the >question whether this is done in ND or elsewhere); I'll say some more >about this below. > > > Now, there's this recurrent question about how many contexts and what > > they are for: > > - It is very hard to know how many we need if we do not know what >they > > are for in the first place. > >Right. In broken record mode: To go from gut feeling ("640K should be >enough for everyone") to a better (and common) understanding, we need >to agree on an example/a benchmark. See my message from Jul 31. > >(Continuing out of order:) > > There could be a number of those babies, thus the number 16. > >The specific number should be decided when we know the trade-offs. >In the original CBHC draft, I proposed 16 because I conflated the >prefix length with the context number. I haven't heard any support >for that idea. So maybe we need fewer than 16. See below. > >So: > > - a context entry contains a prefix and a prefix length. Length can >be > > 128. > >Yes. >It might also contain information about what is going to provide the >remaining bits: Are they going to be in the header or are they inferred >(e.g., from L2 addresses)? Of course, that information can also be in >the header itself as separate bits, but this may be less efficient. >Note that the same prefix can be used beneficially in both these modes. >(We also need to decide how padding works if the bits in the header >can be non-multiples of 8 in length.) > >Now, what is the cost of having too many contexts? > >-- Assuming that the prefix length is part of the context state, the >cost of a context is: up to 16 bytes for the actual value, one byte (7 >bits) for the prefix length, and one or two bytes for state >management. Providing space for 16 contexts thus would mean that each >node would need to reserve up to ~300 bytes of context state, a value >high enough to merit some further discussion. > >-- The context ID needs to be encoded in the context-referencing >header, once for each address. Since we probably also want to >minimize complexity from variable-length and/or arithmetic encoding, >supporting 16 contexts needs expending 2x4 = 8 bits. > >-- Of course, there is also a cost in state management. 300 bytes >don't fit into one L2 MTU, for instance, possibly increasing the >number of L2 packets needed for CEP. > >What is the cost of having too little contexts? Lost opportunities >for compression (or, possibly the need to go for less compression >where more would have been possible). > > > - if a node can not support as many contexts as the edge router > > requires, we can hope that it does not need them. > > > > - nodes should advertise how many contexts they can support max as >they > > attach to a router (ND) > >Hope is not a strategy, and not a protocol either :-) >If we allow heterogeneous context state within an area, we'll need to >establish state between sender and receiver, whether with an explicit >bilateral CEP or by storing per-peer state from error messages. >I don't think we want to do this, so I would propose to go for >homogeneous context state. > > > - It is the edge router responsibility to maintain the contexts in >all > > nodes. The contexts are distributed by the edge routers through a >new ND > > option that the ND draft introduces, valid in RAs and Router > > Registration Confirmation. > >As I said, I'll call that "CEP" for now (but I do expect this to be >part of optimized ND and to be controlled by a designated node such as >an edge router). > >So: > > - which context and how many there are (up to 16) is under the > > responsibility of the edge router (config, radius, ...) > >Yes ("designated node" for this message). > > > - Another question that is not answered if the scope of a context. > > [...] > > - the scope of a context is the set of devices attached to an >interface > > of that edge router. That is, it is guaranteed that entry 7 will >means > > the same for all nodes attached to a same interface on a same edge > > router. > >I'll skip the issue of what "attached to a same interface on a same >edge router" means and just call these scopes "areas" for now. > >So, again, I'd agree and try to get homogeneous context state for an >area. The assumption is that a node knows when it enters an area and >can then use a CEP (i.e., ND) to establish the context state for this >area. I also assume there will be other state associated with an >area, so running a CEP is not going to dominate the cost of >e.g. mobility. > >It also makes sense to assume some relationship between the area and >address configuration information (such as prefixes used for stateless >address configuration). > > > What we have today: > > - The Current version of the HC WG doc uses contexts for anything > > stateful > > - The Current version of the HC WG doc enables up to 16 contexts. > > > > Following the current HC assumptions, a context can be used to >compress > > anything down to /128. As Carsten mentions down here that includes > > remote prefixes; and it also enables to fully compress a number of >much > > used addressed such as the application gateways and servers that the > > nodes publish to. > >Yep, but see above for the remaining bits. > >Finally, I don't really know what these of your points mean: > > > - An edge router might use the same table on multiple interfaces. > > > > - For transparent mobility, it is allowed to have a common context >table > > across the subnet > >Let me comment that "mobility" can be intra-area mobility (which is >nothing but a routing change, so can be ignored here) or inter-area >mobility (which requires reconfiguration anyway). Which one do you >mean? > > > - entry 0 is the edge router global address > >We can always decide specific meanings for specific contexts, but I >don't know what "the edge router global address" is and how a node >would know it. > > > - the router should store that in it ND cache and expand any address > > that the node can not understand > >In route-over, all nodes are routers, so I don't understand. > > > - an new ICMP can be introduced to reject an unknown entry. > >I explained above why I don't like relying on this for normal >operation, but it's certainly a good idea to provide some diagnostic >capability. > >So, thanks again, Pascal, for creating a good outline for discussion! > >Now, back to that number 16: >I'm assuming that CEP will be extremely lightweight (not two-phase >commit or some such :-). So whenever the context state for an area >changes (and my assumption is that there is a need to allow it to >change), there will be contexts for which some nodes in the area have >new state and some are still on the old state. The CEP, of course, is >designed to converge, so the assumption is there is a point in time >when the new state actually can be used. But way before that point, >nodes need to find out the new state while knowing they can't use it >yet, and they need to stop using the old state. > >So, I think each context can have one of the following states: > >00 unused (do not use, do not accept) >01 in introduction (do not actively use, but remember the state) >11 in use (i.e., nodes assume all other nodes know the state) >10 in deprecation (do not actively use, but remember the state) > >(01 and 10 are very similar in the way a node should handle them, so >it may be possible to combine them in CEP's encoding). 00 does not >have a value associated; the other three need a value and each node >needs to allow receiving headers referencing the context: 01 in case >another node switches to 11 earlier and starts using the context, 10 >in case another node hasn't got the memo and still thinks the context >is in 11 state. This is also the reason a context can't be in 01 and >10 at the same time (i.e., cannot simply get descructively updated >with a new value): a receiving node would not know whether to apply >the old or the new value to a compressed header. (This can be solved >with any number of methods like generation numbers etc., but this >creates complexity and needs even more bits.) > >So if we assume a transition time Tt within which a designated node >can update an area to new values with a level of probability deemed >acceptable, each specific context can be useless for 2*Tt, requiring >the use of another context number if continued context-based >compression during a transition is desired. This is the reason why we >may need more potential context values than any static context state >configuration might suggest. How many, of course, depends on our >model of the dynamicity of the context state, which is (broken-record >mode) the reason we need benchmarks to finish this discussion. > >Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Oct 17 07:10:00 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 164673A6A65; Fri, 17 Oct 2008 07:10:00 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3D9B3A6897 for <6lowpan@core3.amsl.com>; Fri, 17 Oct 2008 07:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmogfFL1j1hz for <6lowpan@core3.amsl.com>; Fri, 17 Oct 2008 07:09:57 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 8BF523A683C for <6lowpan@ietf.org>; Fri, 17 Oct 2008 07:09:57 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-153.messagelabs.com!1224252661!11223076!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [136.182.1.14] Received: (qmail 30443 invoked from network); 17 Oct 2008 14:11:01 -0000 Received: from unknown (HELO motgate4.mot.com) (136.182.1.14) by server-10.tower-153.messagelabs.com with SMTP; 17 Oct 2008 14:11:01 -0000 Received: from il27exr02.cig.mot.com (il27exr02.mot.com [10.17.196.71]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id m9HEB0aN010720 for <6lowpan@ietf.org>; Fri, 17 Oct 2008 07:11:00 -0700 (MST) Received: from az10vts04.mot.com (il27vts04.cig.mot.com [10.17.196.88]) by il27exr02.cig.mot.com (8.13.1/Vontu) with SMTP id m9HEB054001148 for <6lowpan@ietf.org>; Fri, 17 Oct 2008 09:11:00 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by il27exr02.cig.mot.com (8.13.1/8.13.0) with ESMTP id m9HEAxJX001126 for <6lowpan@ietf.org>; Fri, 17 Oct 2008 09:11:00 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Oct 2008 15:10:59 +0100 Message-ID: <48F89CF2.8070603@gmail.com> Date: Fri, 17 Oct 2008 16:10:58 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Jonathan Hui References: <38F26F36EAA981478A49D1F37F474A86020CFF03@xmb-ams-33d.emea.cisco.com> <59F5D5A7-956C-434D-ABFB-AFA945A51E67@archrock.com> In-Reply-To: <59F5D5A7-956C-434D-ABFB-AFA945A51E67@archrock.com> X-Antivirus: avast! (VPS 081015-0, 15/10/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 17 Oct 2008 14:10:59.0782 (UTC) FILETIME=[2E42AE60:01C93062] X-CFilter-Loop: Reflected Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Multicast address compression in hc01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Jonathan Hui wrote: > > Hi Julien, > > This mcast compression issue was brought up in the last WG meeting, > but hasn't been addressed on the ML yet. So thanks for brining it up > again. Hi, about address compression. As people may be aware, MANET WG also designed a address (set) compression scheme. See for example PacketBB (Packet Building Block) draft-ietf-manet-packetbb-16.txt section C.1. Is there any relationship between the two methods? Alex > > Adhering to the 16-bit format was my attempt to keep the format as > simple as possible. I've been trying very hard to limit the number of > encoding variations. I've also been trying to address concerns of > keeping the base format compact. As you will see in my post to the "T > and F" thread, I've reduced the encoding to dispatch + 1-byte > encoding (1 byte less than the HC-01 draft). > > So adding 1 bit will require either adding a full byte to the > encoding or stealing yet another bit from the dispatch. In all > honesty, we might want to consider giving HC a very short header type > (similar to mesh addressing and frag). I think there are unused bits > with the frag header, and stealing one to indicate frag vs. mesh > would give us 13 bits to play with vs. 11 bits that I had in my last > post. However, this would require making a minor update to the frag > header. > > A separate question is whether or not increasing the group ID beyond > 8/9 bits is useful. As you noted, most of the significant group ids > are trivially supported. The solicited node address is not used with > the ND/DAD proposal that we are currently working on (multicast over > a LoWPAN is not the most efficient). > > What do people think? > > -- Jonathan Hui > > > > On Oct 8, 2008, at 2:41 AM, Julien Abeille (jabeille) wrote: > >> Hi Jonathan, all, >> >> a few comments/questions about multicast address compression in >> hc-01: - is there a need to respect the 16 bit address formats >> defined in RFC4944 when compressing addresses. I though these >> formats were defined for layer 2 16 bits addresses, while the >> compressed addresses in the ip header are rather independant. - >> with 9 bits group-id, we do not support sollicited node and a few >> "well known" addresses (though most significant are supoprted), >> should we work on a format with different length possible? Also the >> current group-id mapping is stateful. A stateless model would avoid >> the need to store many mappings, and seems feasible as most >> group-ids start with a large number of 0 bytes. >> >> we could use one more bit for destination address mode: something >> like 000 128 001 unicast 64 010 unicast 16 011 unicast 0 100 >> multicast 32 (for e.g. sollicited node), one byte flags + scope, >> 3bytes = last 3 bytes 101 multicast 24 flags + scope + last 2 bytes >> 110 multicast 16 bits : flags + scope + last byte ... >> >> this way we also incorporate flags. >> >> the issue is that we need one more bit for this... >> >> does it make sense? Best, Julien > > _______________________________________________ 6lowpan mailing list > 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Oct 17 09:40:31 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBEF73A6A76; Fri, 17 Oct 2008 09:40:31 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49D4C3A6A2B for <6lowpan@core3.amsl.com>; Fri, 17 Oct 2008 09:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfIhwwhKQQPQ for <6lowpan@core3.amsl.com>; Fri, 17 Oct 2008 09:40:29 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 25D613A6A76 for <6lowpan@ietf.org>; Fri, 17 Oct 2008 09:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m9HGes9n026887; Fri, 17 Oct 2008 18:40:57 +0200 (CEST) Message-Id: <9C8B87AA-2553-4FF1-BC52-3E78D9B3DA30@tzi.org> From: Carsten Bormann To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC066729BE@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 17 Oct 2008 18:40:53 +0200 References: <20081009021535.C8E823A6959@core3.amsl.com><48EF5170.7050107@sensinode.com><38F26F36EAA981478A49D1F37F474A8602115D33@xmb-ams-33d.emea.cisco.com><82EFF32E-3D4F-4A08-B851-A1DFDBF0C39C@archrock.com> <2B4A9FEA-B304-48C7-B399-13C6A48BF17B@tzi.org> <7892795E1A87F04CADFCCF41FADD00FC0661E142@xmb-ams-337.emea.cisco.com> <361167B4-6DFE-4E85-AC8A-69983F7E3350@tzi.org> <7892795E1A87F04CADFCCF41FADD00FC066729BE@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Use of context / how many contexts X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org > I'm not sure what you mean by Establishment? The way the context gets to the node. I.e., distribution for all likely kinds of CEP. > I had in mind that the > context is there by untold magic and ND had to Distribute it. If the > "Context Distribution Protocol" is part of ND then we have to > specify it > there but I'd not expect ND to tell how the context is built in the > first place. I think the way the context state gets built in the first place (i.e., before it is distributed in the area) is a local matter. It seems to me we agree here. > I can agree that traditional RA might not be the right way, be it only > for reasons of size. OTOH, a node might reactively read the white > board > to get the value of a context entry whenever it needs it so it would > not > need a table but a cache. Strikes me as a bad strategy; how do you manage your buffer space in this case? But it's not ruled out by what I have in mind. > RAs could carry a checksum of the entries; > also, failure to compute the right checksum for a packet could > indicate > that the cache is obsolete. Internet checksums are rather weak, so this should only be an unlikely last resort, or we will have regular cases of bad context not being detected. > What you called an area and I called a scope could be simple if we > agree > it's the subnet. I just didn't want to make that decision in my message, which was trying to separate HC and the CEP and focus on HC. I agree this is the obvious thing to do. > The subnet is the set on which we already do DAD and ND > lookup. A node is free to move within its subnet without renumbering. > Maybe mapping the area to a subnet limits number of contexts but for > sure it keeps things simple and cleanly at L3, as opposed to using > concepts like PAN ID . > > Anyway we seem to agree that 16 contexts is a good number. Two other numbers could be considered: 8 (needs 2x3 bits) 11 (needs 7 bits and a division, maybe not so great; leaves 7 patterns for special cases). Also, the number could be 16-n if we reserve n bit patterns for specific purposes (e.g., indicating link-local, no context; useful if we want to get rid of DDF). Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Oct 20 02:51:46 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFB353A68F3; Mon, 20 Oct 2008 02:51:46 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 834813A6A14 for <6lowpan@core3.amsl.com>; Mon, 20 Oct 2008 02:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WalU1xFoAOe for <6lowpan@core3.amsl.com>; Mon, 20 Oct 2008 02:51:44 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.189]) by core3.amsl.com (Postfix) with ESMTP id 883523A68F3 for <6lowpan@ietf.org>; Mon, 20 Oct 2008 02:51:44 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so747480tib.25 for <6lowpan@ietf.org>; Mon, 20 Oct 2008 02:52:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=hfybvyzeWhM3Cpv7Zb2lo9N8HrrLWA7Z26PCI4Alg3o=; b=ID7o298hz09r+7T5kePPZRAr9mjGXKfzhNgxv04UwiZ9GBa+2iw6CPa/e+eAx8xNCI Eo90w4jsN+4PSY+03QHSgWSSs83ZV47WNIA84DcAAHo6RkOKTOSYIJ1n8U1CCJodTjvw pjGnz6ZmAqemvfI3FjEhoa6G/xc7e4m0fN0e8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=vQIDMVjNKGhhChymU06HsVH0V1TDBxmjgKr50iZxyqIp0LQcO2UI6VrfPDSmEQzDd1 9DtmFtF6z0Wbk2UQKUQ2pZJm2gYkBnu7pn6D0TrOJyYtrEs4Cms/7Bcdg9qUzd+3rAsI 2rTh71f9K1nf3e61irGQu6IQmZ8CzsfBhVecQ= Received: by 10.110.92.8 with SMTP id p8mr4808303tib.11.1224496374606; Mon, 20 Oct 2008 02:52:54 -0700 (PDT) Received: by 10.110.60.20 with HTTP; Mon, 20 Oct 2008 02:52:54 -0700 (PDT) Message-ID: <77f1dba80810200252h329a8bc5l2927604d74d1404@mail.gmail.com> Date: Mon, 20 Oct 2008 18:52:54 +0900 From: "Eunsook \"Eunah\" Kim" To: 6lowpan <6lowpan@ietf.org> In-Reply-To: <20081017121549.ABA0C3A6AC5@core3.amsl.com> MIME-Version: 1.0 Content-Disposition: inline References: <20081017121549.ABA0C3A6AC5@core3.amsl.com> Subject: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-usecases-00 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org FYI. :) ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Fri, Oct 17, 2008 at 9:15 PM Subject: New Version Notification for draft-ietf-6lowpan-usecases-00 To: eunah.ietf@gmail.com Cc: nicolas.chevrollier@tno.nl, dokaspar.ietf@gmail.com, jpv@cisco.com A new version of I-D, draft-ietf-6lowpan-usecases-00.txt has been successfuly submitted by Eunsook Kim and posted to the IETF repository. Filename: draft-ietf-6lowpan-usecases Revision: 00 Title: Design and Application Spaces for 6LoWPANs Creation_date: 2008-10-15 WG ID: 6lowpan Number_of_pages: 26 Abstract: This document investigates potential application scenarios and use cases for low-power wireless personal area networks (LoWPANs). The IETF Secretariat. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Oct 21 07:10:41 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6FBD3A6950; Tue, 21 Oct 2008 07:10:41 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7E023A683F; Tue, 21 Oct 2008 07:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.453 X-Spam-Level: X-Spam-Status: No, score=-6.453 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0bUEv8Ux02K; Tue, 21 Oct 2008 07:10:36 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3BBFA3A67C0; Tue, 21 Oct 2008 07:10:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,457,1220227200"; d="scan'208,217";a="23276223" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 21 Oct 2008 14:10:56 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9LEAuDA018631; Tue, 21 Oct 2008 16:10:56 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9LEAui2006662; Tue, 21 Oct 2008 14:10:56 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 16:10:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Oct 2008 16:10:55 +0200 Message-ID: <38F26F36EAA981478A49D1F37F474A86021A516A@xmb-ams-33d.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: open source light ipv6 stack released Thread-Index: AckzQlzCOWlfXbVgT7mBLIaXpo3kMwARBmnw From: "Julien Abeille (jabeille)" To: <6lowpan@ietf.org>, X-OriginalArrivalTime: 21 Oct 2008 14:10:56.0335 (UTC) FILETIME=[D5DBB5F0:01C93386] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3344; t=1224598256; x=1225462256; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20open=20source=20light=20ipv6=20stack=20released |Sender:=20; bh=IlMDvZZDXMOizr+d647p0rglJ/iLHSFt8GypZweyj0k=; b=KG3bj3lMBkHKKdDqe40zLrRzaTNpUsDIh+OUho5d5pB/ABYZmkqEjy1EZP MNEQyNDunEhJtUiNGDVGhl8gQo8Xv3yWFJyDrIGiGiQYrpu2OmQ0EBkhb8L6 dzNiPPU/9W; Authentication-Results: ams-dkim-1; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [6lowpan] open source light ipv6 stack released X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1912535431==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============1912535431== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C93386.D5A7EFC9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C93386.D5A7EFC9 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi all, =20 for your information, Cisco, Atmel and SICS released last week uIPv6, an open source (BSD-like licence) IPv6 host implementation for the Contiki operating system, which obtained IPv6 ready phase1 logo. =20 Code size is around 11K, RAM usage minimum 1.8K, more if you enable support for IP layer fragmentation and per neighbor packet buffering. =20 Contiki/uIPv6 was tested on Atmel RAVEN boards and comes with an implementation of RFC4944 (fragmentation and header compression scenarios defined in draft-hui-6lowpan-interop) as well as draft-hui-6lowpan-hc-01. =20 Detailed documentattion can be found at=20 http://www.sics.se/contiki =20 Regards, Julien ------_=_NextPart_001_01C93386.D5A7EFC9 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi all,
 
for = your=20 information, Cisco, Atmel and SICS=20 released last week uIPv6, an open source (BSD-like licence) IPv6 host=20 implementation for the Contiki operating system, which obtained IPv6 = ready=20 phase1 logo.
 
Code = size is around=20 11K, RAM usage minimum 1.8K, more if you enable support for IP layer=20 fragmentation and per neighbor packet buffering.
 
Contiki/uIPv6 was=20 tested on Atmel RAVEN boards and comes with an implementation of RFC4944 = (fragmentation and header compression scenarios defined in=20 draft-hui-6lowpan-interop) as well as = draft-hui-6lowpan-hc-01.
 
Detailed=20 documentattion can be found at
http://www.sics.se/contiki=
 
Regards,
Julien
------_=_NextPart_001_01C93386.D5A7EFC9-- --===============1912535431== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan --===============1912535431==-- From 6lowpan-bounces@ietf.org Fri Oct 24 01:01:55 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 821323A69F4; Fri, 24 Oct 2008 01:01:55 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7587D3A69CF; Fri, 24 Oct 2008 01:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.463 X-Spam-Level: X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHuaZqNvJ57c; Fri, 24 Oct 2008 01:01:53 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A5F713A67CC; Fri, 24 Oct 2008 01:01:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,476,1220227200"; d="scan'208";a="23596699" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 24 Oct 2008 08:02:49 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m9O82mPr031959; Fri, 24 Oct 2008 10:02:48 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9O82mjV020558; Fri, 24 Oct 2008 08:02:48 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Oct 2008 10:02:48 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 24 Oct 2008 10:02:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <38F26F36EAA981478A49D1F37F474A86021ED3D9@xmb-ams-33d.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: per neighbor packet buffering "issue" Thread-Index: AckzmBEN4tpxWo8WQBy6D8lR4BGCQwCFZFuw From: "Julien Abeille (jabeille)" To: <6lowpan@ietf.org>, X-OriginalArrivalTime: 24 Oct 2008 08:02:48.0880 (UTC) FILETIME=[E7F2CB00:01C935AE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=890; t=1224835368; x=1225699368; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20FW=3A=20per=20neighbor=20packet=20buffering=20= 22issue=22 |Sender:=20; bh=cK2DllRrMNPBsQuDSBSYz3PeznnU9FtfoWayo1cMVyE=; b=EMcgkC2sbALzTDsDjKRmjNXT2p//kJQ1iFMr7zSvqVroYwn9KHwWTlzU6u vkfT9iMMX7KF4f8WekFCrX1XMjJ7bge4g/t9Xa9xktIFOBlQoFUFw4Zkb94W InNf9/YWco; Authentication-Results: ams-dkim-2; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [6lowpan] FW: per neighbor packet buffering "issue" X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Dear all, I started a thread on 6man about one issue in Neighbor Discovery which is extremely costly for embedded device: While performing address resolution for a neighbor, a node must be able to buffer at least one packet for the neighbor. It means if your neighbor cache can support 4 neighbors, you must allocate 5K RAM for this buffering, 10K for 8 neighbors. This is very costly and will prevent most constrained platforms to be IPv6 compliant. I feel that without this, a node with 4K of RAM can be compliant. If the standard is not revised, you will probably need to upgrade to a chip with 16K RAM. This is true on any L2, not specific to 802.15.4, and also true with the neighbor discovery extensions 6lowpan is working on. I think this is critical we manage to have neighbor discovery revised on this point. What do you think? Regards, Julien _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Oct 24 01:50:29 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7F333A68D1; Fri, 24 Oct 2008 01:50:29 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E44893A6A0E for <6lowpan@core3.amsl.com>; Fri, 24 Oct 2008 01:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.418 X-Spam-Level: X-Spam-Status: No, score=-3.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTx5L1724sIZ for <6lowpan@core3.amsl.com>; Fri, 24 Oct 2008 01:50:27 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 859B33A68D1 for <6lowpan@ietf.org>; Fri, 24 Oct 2008 01:50:27 -0700 (PDT) Received: from h157021.gprs.dnafinland.fi (h157021.gprs.dnafinland.fi [87.93.157.21]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id m9O8pWJK015067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Oct 2008 11:51:34 +0300 Message-ID: <49018C95.8090801@sensinode.com> Date: Fri, 24 Oct 2008 11:51:33 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: "Julien Abeille (jabeille)" References: <38F26F36EAA981478A49D1F37F474A86021ED3D9@xmb-ams-33d.emea.cisco.com> In-Reply-To: <38F26F36EAA981478A49D1F37F474A86021ED3D9@xmb-ams-33d.emea.cisco.com> Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] FW: per neighbor packet buffering "issue" X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Julien, This is a valid concern. The ND for 6lowpan draft (-00 coming today) is meant to exactly fix the problems that standard IPv6 ND (RFC4861) has for 6lowpan. It is not expected that 6lowpan nodes implement RFC4861, but rather just ND for 6lowpan, which borrows only minimal features from RFC4861. So I believe we can fix all problems here. Are you referring to this piece of text from RFC4861? Once the IP address of the next-hop node is known, the sender examines the Neighbor Cache for link-layer information about that neighbor. If no entry exists, the sender creates one, sets its state to INCOMPLETE, initiates Address Resolution, and then queues the data packet pending completion of address resolution. For multicast- capable interfaces Address Resolution consists of sending a Neighbor Solicitation message and waiting for a Neighbor Advertisement. When a Neighbor Advertisement response is received, the link-layer addresses is entered in the Neighbor Cache entry and the queued packet is transmitted. The address resolution mechanism is described in detail in Section 7.2. That doesn't tell me that you need a *separate* buffer for each neighbor, just that you need to buffer the packet while performing address resolution. A minimum IPv6 implementation should work with 2 buffers then? Currently the draft specifies that 6lowpan nodes do not need to subscribe to the all-nodes multicast and are not required to answer multicast NS messages, asnwering unicast NS is also optional. Here is the current text from our draft: A LoWPAN node does not use multicast for its Neighbor Solicitation as prescribed by the ND protocol [RFC4861] and oDAD [RFC4429]. For lookup purposes, all NS messages are sent in unicast to the Edge Router, that answers in unicast as well. The message is a standard Neighbor Solicitation but for the destination that set to the Edge Router address or the well known 6LOWPAN_ER anycast address as opposed to the solicited-node multicast address for the destination address. The Target link-layer address in the response is either that of the destination if a short cut is possible over the LoWPAN, or that of the Edge Router if the destination is reachable over the Transit Link, in which case the Edge Router will terminate 6LoWPAN and relay the packet. A 6LoWPAN node does not need to join the solicited-node multicast address for its own addresses and should not have to answer a multicast Neighbor Solicitation. It may be programmed to answer a unicast NS but that is not required by this specification. - Zach Julien Abeille (jabeille) wrote: > Dear all, > > I started a thread on 6man about one issue in Neighbor Discovery which > is extremely costly for embedded device: > While performing address resolution for a neighbor, a node must be able > to buffer at least one packet for the neighbor. > > It means if your neighbor cache can support 4 neighbors, you must > allocate 5K RAM for this buffering, 10K for 8 neighbors. This is very > costly and will prevent most constrained platforms to be IPv6 compliant. > I feel that without this, a node with 4K of RAM can be compliant. If the > standard is not revised, you will probably need to upgrade to a chip > with 16K RAM. > > This is true on any L2, not specific to 802.15.4, and also true with the > neighbor discovery extensions 6lowpan is working on. > > I think this is critical we manage to have neighbor discovery revised on > this point. > What do you think? > > Regards, > Julien > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll -- Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti FINLAND mobile: +358 40 7796297 This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Oct 24 06:49:58 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 588853A6B4B; Fri, 24 Oct 2008 06:49:58 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B3B03A6B3F; Fri, 24 Oct 2008 06:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3eCGsLqqtp7; Fri, 24 Oct 2008 06:49:53 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9D64B28C19C; Fri, 24 Oct 2008 06:49:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,477,1220227200"; d="scan'208";a="23650196" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 24 Oct 2008 13:51:13 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m9ODpDsf030933; Fri, 24 Oct 2008 15:51:13 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9ODpD0C001464; Fri, 24 Oct 2008 13:51:13 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Oct 2008 15:51:13 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 24 Oct 2008 15:51:11 +0200 Message-ID: <38F26F36EAA981478A49D1F37F474A86021ED639@xmb-ams-33d.emea.cisco.com> In-Reply-To: <49018C95.8090801@sensinode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: per neighbor packet buffering "issue" Thread-Index: Ack1tcDJz2uuWuCORQyb78cfbzvWZgAJ4QbA References: <38F26F36EAA981478A49D1F37F474A86021ED3D9@xmb-ams-33d.emea.cisco.com> <49018C95.8090801@sensinode.com> From: "Julien Abeille (jabeille)" To: "Zach Shelby" X-OriginalArrivalTime: 24 Oct 2008 13:51:13.0320 (UTC) FILETIME=[93F73280:01C935DF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5731; t=1224856273; x=1225720273; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20FW=3A=20per=20neighbor=20packet=20buffering=20= 22issue=22 |Sender:=20; bh=5QyzzpCKAjX+yFLIq8CPWXcBal/cyVEcjvv27frXX+M=; b=g27+yiV/S6HeCNGMAxytDOGaV9mgwiCa2LuUIXcpJpzY6SsV4KLyUfEYfp HK2yASpV9APUYAMfcEFVVi8mZTpbNgJ19bwzGiPHPqwWNTYLc8sHA6akKPbj UKAfZn91LI; Authentication-Results: ams-dkim-2; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll@ietf.org, 6lowpan@ietf.org Subject: [6lowpan] FW: per neighbor packet buffering "issue" X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Zach, all, 1 the ND section refering to per neighbor packet buffering is "While waiting for address resolution to complete, the sender MUST, for each neighbor, retain a small queue of packets waiting for address resolution to complete. The queue MUST hold at least one packet, and MAY contain more. However, the number of queued packets per neighbor SHOULD be limited to some small value. When a queue overflows, the new arrival SHOULD replace the oldest entry. Once address resolution completes, the node transmits any queued packets." >From a pure standard perspective, multiple queues are a MUST (one per neighbor) >From a certification perspective (Ipv6ready logo), there is a specific test for multiple queues (test number v6LC.2.1.2B). >From a deployment perspective, the feature is very useful, especially for routers. What I would like is to make the MUST become a SOULD, and let the implementation choose to buffer as much as it can, depending on the available RAM. As typical packets are small in sensor networks, this is feasible. 2 this is not an issue specific to 802.15.4/6lowpan, but to any very constrained device, over any layer 2. Cheers, Julien -----Original Message----- From: Zach Shelby [mailto:zach@sensinode.com] Sent: vendredi 24 octobre 2008 10:52 To: Julien Abeille (jabeille) Cc: 6lowpan@ietf.org Subject: Re: [Roll] FW: per neighbor packet buffering "issue" Hi Julien, This is a valid concern. The ND for 6lowpan draft (-00 coming today) is meant to exactly fix the problems that standard IPv6 ND (RFC4861) has for 6lowpan. It is not expected that 6lowpan nodes implement RFC4861, but rather just ND for 6lowpan, which borrows only minimal features from RFC4861. So I believe we can fix all problems here. Are you referring to this piece of text from RFC4861? Once the IP address of the next-hop node is known, the sender examines the Neighbor Cache for link-layer information about that neighbor. If no entry exists, the sender creates one, sets its state to INCOMPLETE, initiates Address Resolution, and then queues the data packet pending completion of address resolution. For multicast- capable interfaces Address Resolution consists of sending a Neighbor Solicitation message and waiting for a Neighbor Advertisement. When a Neighbor Advertisement response is received, the link-layer addresses is entered in the Neighbor Cache entry and the queued packet is transmitted. The address resolution mechanism is described in detail in Section 7.2. That doesn't tell me that you need a *separate* buffer for each neighbor, just that you need to buffer the packet while performing address resolution. A minimum IPv6 implementation should work with 2 buffers then? Currently the draft specifies that 6lowpan nodes do not need to subscribe to the all-nodes multicast and are not required to answer multicast NS messages, asnwering unicast NS is also optional. Here is the current text from our draft: A LoWPAN node does not use multicast for its Neighbor Solicitation as prescribed by the ND protocol [RFC4861] and oDAD [RFC4429]. For lookup purposes, all NS messages are sent in unicast to the Edge Router, that answers in unicast as well. The message is a standard Neighbor Solicitation but for the destination that set to the Edge Router address or the well known 6LOWPAN_ER anycast address as opposed to the solicited-node multicast address for the destination address. The Target link-layer address in the response is either that of the destination if a short cut is possible over the LoWPAN, or that of the Edge Router if the destination is reachable over the Transit Link, in which case the Edge Router will terminate 6LoWPAN and relay the packet. A 6LoWPAN node does not need to join the solicited-node multicast address for its own addresses and should not have to answer a multicast Neighbor Solicitation. It may be programmed to answer a unicast NS but that is not required by this specification. - Zach Julien Abeille (jabeille) wrote: > Dear all, > > I started a thread on 6man about one issue in Neighbor Discovery which > is extremely costly for embedded device: > While performing address resolution for a neighbor, a node must be > able to buffer at least one packet for the neighbor. > > It means if your neighbor cache can support 4 neighbors, you must > allocate 5K RAM for this buffering, 10K for 8 neighbors. This is very > costly and will prevent most constrained platforms to be IPv6 compliant. > I feel that without this, a node with 4K of RAM can be compliant. If > the standard is not revised, you will probably need to upgrade to a > chip with 16K RAM. > > This is true on any L2, not specific to 802.15.4, and also true with > the neighbor discovery extensions 6lowpan is working on. > > I think this is critical we manage to have neighbor discovery revised > on this point. > What do you think? > > Regards, > Julien > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll -- Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti FINLAND mobile: +358 40 7796297 This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Oct 24 07:36:16 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5CBB3A6B4D; Fri, 24 Oct 2008 07:36:16 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F2383A6B57; Fri, 24 Oct 2008 07:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.441 X-Spam-Level: X-Spam-Status: No, score=-3.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dx5esn-iMasK; Fri, 24 Oct 2008 07:36:14 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id B16CB3A6A8A; Fri, 24 Oct 2008 07:36:13 -0700 (PDT) Received: from h195249.gprs.dnafinland.fi (h195249.gprs.dnafinland.fi [87.93.195.249]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id m9OEb7p6010150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Oct 2008 17:37:09 +0300 Message-ID: <4901DD95.4000600@sensinode.com> Date: Fri, 24 Oct 2008 17:37:09 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: "Julien Abeille (jabeille)" References: <38F26F36EAA981478A49D1F37F474A86021ED3D9@xmb-ams-33d.emea.cisco.com> <49018C95.8090801@sensinode.com> <38F26F36EAA981478A49D1F37F474A86021ED639@xmb-ams-33d.emea.cisco.com> In-Reply-To: <38F26F36EAA981478A49D1F37F474A86021ED639@xmb-ams-33d.emea.cisco.com> Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] FW: per neighbor packet buffering "issue" X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Julien, Understood. The ND for 6LoWPAN draft now has a sentence included which makes that a SHOULD. Thanks for pointing this out. You will have to keep lobbying elsewhere to get that updated to a SHOULD for general IPv6 ND... - Zach Julien Abeille (jabeille) wrote: > Hi Zach, all, > > 1 the ND section refering to per neighbor packet buffering is > "While waiting for address resolution to complete, the sender MUST, > for each neighbor, retain a small queue of packets waiting for > address resolution to complete. The queue MUST hold at least one > packet, and MAY contain more. However, the number of queued packets > per neighbor SHOULD be limited to some small value. When a queue > overflows, the new arrival SHOULD replace the oldest entry. Once > address resolution completes, the node transmits any queued packets." > > From a pure standard perspective, multiple queues are a MUST (one per > neighbor) > > From a certification perspective (Ipv6ready logo), there is a specific > test for multiple queues (test number v6LC.2.1.2B). > > From a deployment perspective, the feature is very useful, especially > for routers. What I would like is to make the MUST become a SOULD, and > let the implementation choose to buffer as much as it can, depending on > the available RAM. As typical packets are small in sensor networks, this > is feasible. > > 2 this is not an issue specific to 802.15.4/6lowpan, but to any very > constrained device, over any layer 2. > > Cheers, > Julien > > > > -----Original Message----- > From: Zach Shelby [mailto:zach@sensinode.com] > Sent: vendredi 24 octobre 2008 10:52 > To: Julien Abeille (jabeille) > Cc: 6lowpan@ietf.org > Subject: Re: [Roll] FW: per neighbor packet buffering "issue" > > Hi Julien, > > This is a valid concern. The ND for 6lowpan draft (-00 coming today) is > meant to exactly fix the problems that standard IPv6 ND (RFC4861) has > for 6lowpan. It is not expected that 6lowpan nodes implement RFC4861, > but rather just ND for 6lowpan, which borrows only minimal features from > RFC4861. So I believe we can fix all problems here. > > Are you referring to this piece of text from RFC4861? > > Once the IP address of the next-hop node is known, the sender > examines the Neighbor Cache for link-layer information about that > neighbor. If no entry exists, the sender creates one, sets its > state > to INCOMPLETE, initiates Address Resolution, and then queues the > data > packet pending completion of address resolution. For multicast- > capable interfaces Address Resolution consists of sending a Neighbor > Solicitation message and waiting for a Neighbor Advertisement. When > a Neighbor Advertisement response is received, the link-layer > addresses is entered in the Neighbor Cache entry and the queued > packet is transmitted. The address resolution mechanism is > described > in detail in Section 7.2. > > That doesn't tell me that you need a *separate* buffer for each > neighbor, just that you need to buffer the packet while performing > address resolution. A minimum IPv6 implementation should work with 2 > buffers then? > > Currently the draft specifies that 6lowpan nodes do not need to > subscribe to the all-nodes multicast and are not required to answer > multicast NS messages, asnwering unicast NS is also optional. Here is > the current text from our draft: > > A LoWPAN node does not use multicast for its Neighbor Solicitation > as > prescribed by the ND protocol [RFC4861] and oDAD [RFC4429]. For > lookup purposes, all NS messages are sent in unicast to the Edge > Router, that answers in unicast as well. The message is a standard > Neighbor Solicitation but for the destination that set to the Edge > Router address or the well known 6LOWPAN_ER anycast address as > opposed to the solicited-node multicast address for the destination > address. > > The Target link-layer address in the response is either that of the > destination if a short cut is possible over the LoWPAN, or that of > the Edge Router if the destination is reachable over the Transit > Link, in which case the Edge Router will terminate 6LoWPAN and relay > the packet. > > A 6LoWPAN node does not need to join the solicited-node multicast > address for its own addresses and should not have to answer a > multicast Neighbor Solicitation. It may be programmed to answer a > unicast NS but that is not required by this specification. > > - Zach > > Julien Abeille (jabeille) wrote: >> Dear all, >> >> I started a thread on 6man about one issue in Neighbor Discovery which > >> is extremely costly for embedded device: >> While performing address resolution for a neighbor, a node must be >> able to buffer at least one packet for the neighbor. >> >> It means if your neighbor cache can support 4 neighbors, you must >> allocate 5K RAM for this buffering, 10K for 8 neighbors. This is very >> costly and will prevent most constrained platforms to be IPv6 > compliant. >> I feel that without this, a node with 4K of RAM can be compliant. If >> the standard is not revised, you will probably need to upgrade to a >> chip with 16K RAM. >> >> This is true on any L2, not specific to 802.15.4, and also true with >> the neighbor discovery extensions 6lowpan is working on. >> >> I think this is critical we manage to have neighbor discovery revised >> on this point. >> What do you think? >> >> Regards, >> Julien >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > -- Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti FINLAND mobile: +358 40 7796297 This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Oct 24 07:56:42 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D89BB28C0F1; Fri, 24 Oct 2008 07:56:42 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 731963A6B15; Fri, 24 Oct 2008 07:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyEyqMRzuzan; Fri, 24 Oct 2008 07:56:41 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 3DADB3A6881; Fri, 24 Oct 2008 07:56:40 -0700 (PDT) Received: from h195249.gprs.dnafinland.fi (h195249.gprs.dnafinland.fi [87.93.195.249]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id m9OEvuMX010759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Oct 2008 17:57:57 +0300 Message-ID: <4901E274.4010001@sensinode.com> Date: Fri, 24 Oct 2008 17:57:56 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org>, roll@ietf.org Subject: [6lowpan] [Fwd: New Version Notification for draft-shelby-6lowpan-nd-00] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi, The first version of the ND for 6LoWPAN I-D has now been posted and is available for comment. We would appreciate constructive comments and list discussions on this before the IETF, and I would like to request a slot in Minneapolis to present the draft. http://www.ietf.org/internet-drafts/draft-shelby-6lowpan-nd-00.txt There are some known open issues on this draft: o Trickle and its optional use for RA periods in to be in next version. o Fault tolerance to be defined in next version. o Ad-hoc network (no infrastructure) to be discussed in next version. o Context dissemination to be described in more detail. To be determined in how much detail. o Can the 6LoWPAN Address Option be integrated into the Address Option using options in the S field? One less option.. o Consistent for both mesh under and route over may not be 100% consistent yet Regards, Zach -------- Original Message -------- Subject: New Version Notification for draft-shelby-6lowpan-nd-00 Date: Fri, 24 Oct 2008 07:47:19 -0700 (PDT) From: IETF I-D Submission Tool To: zach@sensinode.com CC: pthubert@cisco.com,jhui@archrock.com,samitac@ipinfusion.com,Erik.Nordmark@Sun.COM A new version of I-D, draft-shelby-6lowpan-nd-00.txt has been successfuly submitted by Zach Shelby and posted to the IETF repository. Filename: draft-shelby-6lowpan-nd Revision: 00 Title: Neighbor Discovery for 6LoWPAN Creation_date: 2008-10-24 WG ID: Independent Submission Number_of_pages: 39 Abstract: The 6LoWPAN format allows IPv6 to be used over very low-power, low- bandwidth wireless networks often making use of extended multihop topologies. However, the use of standard IPv6 Neighbor Discovery over 6LoWPAN networks has several problems. Standard ND was not designed for wireless links, the standard IPv6 link concept and heavy use of multicast makes it inefficient. This paper specifies Neighbor Discovery optimized for 6LoWPAN. The IETF Secretariat. -- Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti FINLAND mobile: +358 40 7796297 This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Oct 24 08:06:00 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 817CA3A6B06; Fri, 24 Oct 2008 08:06:00 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A71363A6B57 for <6lowpan@core3.amsl.com>; Fri, 24 Oct 2008 08:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1OQ1XkRa4ob for <6lowpan@core3.amsl.com>; Fri, 24 Oct 2008 08:05:54 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 089BE3A6B06 for <6lowpan@ietf.org>; Fri, 24 Oct 2008 08:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m9OF6cip026946; Fri, 24 Oct 2008 17:06:41 +0200 (CEST) Message-Id: <2EE9B888-C531-41B1-8084-08C9EE4D8068@tzi.org> From: Carsten Bormann To: "Julien Abeille (jabeille)" In-Reply-To: <38F26F36EAA981478A49D1F37F474A86021ED639@xmb-ams-33d.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 24 Oct 2008 17:06:38 +0200 References: <38F26F36EAA981478A49D1F37F474A86021ED3D9@xmb-ams-33d.emea.cisco.com> <49018C95.8090801@sensinode.com> <38F26F36EAA981478A49D1F37F474A86021ED639@xmb-ams-33d.emea.cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] [Roll] FW: per neighbor packet buffering "issue" X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org On Oct 24 2008, at 15:51, Julien Abeille (jabeille) wrote: > "While waiting for address resolution to complete, the sender MUST, > for each neighbor, retain a small queue of packets waiting for > address resolution to complete. Yeah, but nobody forces the node to send a packet in the first place? Maybe I need more information about the specific scenario you have in mind. [ROLL WG taken offline, as this is a 6lowpan issue.] Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Oct 24 08:25:27 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B6473A6BB0; Fri, 24 Oct 2008 08:25:27 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 841BE3A6B06; Fri, 24 Oct 2008 08:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vPmYfxqcfVl; Fri, 24 Oct 2008 08:25:07 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id CD0D13A68DE; Fri, 24 Oct 2008 08:25:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,478,1220227200"; d="scan'208";a="23664968" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 24 Oct 2008 15:26:27 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9OFQRBF005266; Fri, 24 Oct 2008 17:26:27 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9OFQRfH008406; Fri, 24 Oct 2008 15:26:27 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Oct 2008 17:26:27 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 24 Oct 2008 17:26:26 +0200 Message-ID: <38F26F36EAA981478A49D1F37F474A86021ED6D7@xmb-ams-33d.emea.cisco.com> In-Reply-To: <4901DD95.4000600@sensinode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: per neighbor packet buffering "issue" Thread-Index: Ack15g/p6IVX4IFdTvWuqcvvaHGaugABm/uA References: <38F26F36EAA981478A49D1F37F474A86021ED3D9@xmb-ams-33d.emea.cisco.com> <49018C95.8090801@sensinode.com> <38F26F36EAA981478A49D1F37F474A86021ED639@xmb-ams-33d.emea.cisco.com> <4901DD95.4000600@sensinode.com> From: "Julien Abeille (jabeille)" To: "Zach Shelby" X-OriginalArrivalTime: 24 Oct 2008 15:26:27.0611 (UTC) FILETIME=[E1F2CEB0:01C935EC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6432; t=1224861987; x=1225725987; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20RE=3A=20FW=3A=20per=20neighbor=20packet=20buffe ring=20=22issue=22 |Sender:=20; bh=eBME65P6+hksMa8LOwxv2nM9/zcohDQzbVD5OkHyroQ=; b=bGVr9JoQD75IuPqdzIm4/MND2cziMnzZOta57ZBlSML7o+S/yhvY7m8iTU DkaDzu6cFqD4fcqdBRvmMujhQ8c+MiE1hID/56YzW+8HDVRFUIYizezxIIYU qG3ACjgQZf; Authentication-Results: ams-dkim-1; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] FW: per neighbor packet buffering "issue" X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Zach, Understood. The ND for 6LoWPAN draft now has a sentence included which makes that a SHOULD. Thanks for pointing this out. [Julien] ok You will have to keep lobbying elsewhere to get that updated to a SHOULD for general IPv6 ND... [Julien] you are right, I will follow up on 6man and roll Cheers, Julien - Zach Julien Abeille (jabeille) wrote: > Hi Zach, all, > > 1 the ND section refering to per neighbor packet buffering is "While > waiting for address resolution to complete, the sender MUST, > for each neighbor, retain a small queue of packets waiting for > address resolution to complete. The queue MUST hold at least one > packet, and MAY contain more. However, the number of queued packets > per neighbor SHOULD be limited to some small value. When a queue > overflows, the new arrival SHOULD replace the oldest entry. Once > address resolution completes, the node transmits any queued packets." > > From a pure standard perspective, multiple queues are a MUST (one per > neighbor) > > From a certification perspective (Ipv6ready logo), there is a specific > test for multiple queues (test number v6LC.2.1.2B). > > From a deployment perspective, the feature is very useful, especially > for routers. What I would like is to make the MUST become a SOULD, and > let the implementation choose to buffer as much as it can, depending > on the available RAM. As typical packets are small in sensor networks, > this is feasible. > > 2 this is not an issue specific to 802.15.4/6lowpan, but to any very > constrained device, over any layer 2. > > Cheers, > Julien > > > > -----Original Message----- > From: Zach Shelby [mailto:zach@sensinode.com] > Sent: vendredi 24 octobre 2008 10:52 > To: Julien Abeille (jabeille) > Cc: 6lowpan@ietf.org > Subject: Re: [Roll] FW: per neighbor packet buffering "issue" > > Hi Julien, > > This is a valid concern. The ND for 6lowpan draft (-00 coming today) > is meant to exactly fix the problems that standard IPv6 ND (RFC4861) > has for 6lowpan. It is not expected that 6lowpan nodes implement > RFC4861, but rather just ND for 6lowpan, which borrows only minimal > features from RFC4861. So I believe we can fix all problems here. > > Are you referring to this piece of text from RFC4861? > > Once the IP address of the next-hop node is known, the sender > examines the Neighbor Cache for link-layer information about that > neighbor. If no entry exists, the sender creates one, sets its > state > to INCOMPLETE, initiates Address Resolution, and then queues the > data > packet pending completion of address resolution. For multicast- > capable interfaces Address Resolution consists of sending a Neighbor > Solicitation message and waiting for a Neighbor Advertisement. When > a Neighbor Advertisement response is received, the link-layer > addresses is entered in the Neighbor Cache entry and the queued > packet is transmitted. The address resolution mechanism is > described > in detail in Section 7.2. > > That doesn't tell me that you need a *separate* buffer for each > neighbor, just that you need to buffer the packet while performing > address resolution. A minimum IPv6 implementation should work with 2 > buffers then? > > Currently the draft specifies that 6lowpan nodes do not need to > subscribe to the all-nodes multicast and are not required to answer > multicast NS messages, asnwering unicast NS is also optional. Here is > the current text from our draft: > > A LoWPAN node does not use multicast for its Neighbor Solicitation > as > prescribed by the ND protocol [RFC4861] and oDAD [RFC4429]. For > lookup purposes, all NS messages are sent in unicast to the Edge > Router, that answers in unicast as well. The message is a standard > Neighbor Solicitation but for the destination that set to the Edge > Router address or the well known 6LOWPAN_ER anycast address as > opposed to the solicited-node multicast address for the destination > address. > > The Target link-layer address in the response is either that of the > destination if a short cut is possible over the LoWPAN, or that of > the Edge Router if the destination is reachable over the Transit > Link, in which case the Edge Router will terminate 6LoWPAN and relay > the packet. > > A 6LoWPAN node does not need to join the solicited-node multicast > address for its own addresses and should not have to answer a > multicast Neighbor Solicitation. It may be programmed to answer a > unicast NS but that is not required by this specification. > > - Zach > > Julien Abeille (jabeille) wrote: >> Dear all, >> >> I started a thread on 6man about one issue in Neighbor Discovery >> which > >> is extremely costly for embedded device: >> While performing address resolution for a neighbor, a node must be >> able to buffer at least one packet for the neighbor. >> >> It means if your neighbor cache can support 4 neighbors, you must >> allocate 5K RAM for this buffering, 10K for 8 neighbors. This is very >> costly and will prevent most constrained platforms to be IPv6 > compliant. >> I feel that without this, a node with 4K of RAM can be compliant. If >> the standard is not revised, you will probably need to upgrade to a >> chip with 16K RAM. >> >> This is true on any L2, not specific to 802.15.4, and also true with >> the neighbor discovery extensions 6lowpan is working on. >> >> I think this is critical we manage to have neighbor discovery revised >> on this point. >> What do you think? >> >> Regards, >> Julien >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > -- Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti FINLAND mobile: +358 40 7796297 This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sun Oct 26 07:57:44 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46FC03A6942; Sun, 26 Oct 2008 07:57:44 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5392E3A681B for <6lowpan@core3.amsl.com>; Sun, 26 Oct 2008 07:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[AWL=-0.649, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4V6NFYhwZVVv for <6lowpan@core3.amsl.com>; Sun, 26 Oct 2008 07:57:42 -0700 (PDT) Received: from beta.eng.utah.edu (beta.eng.utah.edu [155.98.111.99]) by core3.amsl.com (Postfix) with ESMTP id 2D6153A68C1 for <6lowpan@ietf.org>; Sun, 26 Oct 2008 07:57:42 -0700 (PDT) Received: from 71-213-98-244.slkc.qwest.net ([71.213.98.244] helo=[192.168.1.101]) by beta.eng.utah.edu with esmtpa (Exim 4.63) (envelope-from ) id 1Ku6wr-00064v-5n for 6lowpan@ietf.org; Sun, 26 Oct 2008 08:50:33 -0600 Message-ID: <490485B7.4060405@ece.utah.edu> Date: Sun, 26 Oct 2008 08:59:03 -0600 From: Neal Patwari User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: 6lowpan@ietf.org Subject: [6lowpan] DCOSS 09 Conference X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org *********************************************************************** ******* CALL FOR PAPERS ******* ******* The 5th IEEE/ACM International Conference on ******* ******* DISTRIBUTED COMPUTING IN SENSOR SYSTEMS (DCOSS) ******* ******* June 7 - 10, 2009, ******* ******* Marina Del Rey, USA ******* ******* http://www.dcoss.org ******* *********************************************************************** IMPORTANT DATES Submission Deadline: 11:59PM EST Jan 25, 2009 Notification: March 24, 2009 Camera Ready: March 31, 2009 OVERVIEW Distributed sensor systems have become a highly active research area due to their potential for providing diverse new capabilities. Such systems allow intelligent dense monitoring of physical environments. The focus of this conference is on distributed computing issues in large-scale networked sensor systems (including algorithms, applications, systematic design techniques and tools, and in-network signal and information processing). Authors are invited to submit original unpublished manuscripts that demonstrate current research on computational aspects of distributed sensor systems. Topics of interest include but are not limited to: * Computation and programming models * Energy models, minimization, awareness * Distributed collaborative information processing * Detection and tracking * Theoretical performance analysis: complexity, correctness, scalability * Abstractions for modular design * Fault tolerance and security * Languages, operating systems * Task allocation, reprogramming and reconfiguration * Dynamic resource management * Scalable, heterogeneous architectures (node and system-level) * Middleware interfaces, communication and processing primitives * Design, simulation and optimization tools for deployment and operation * Design automation and application synthesis techniques * closed-loop control for sensing and actuation * Case studies: lessons from real world deployments * Network coding and compression Detailed submission guidelines coming soon on http://www.dcoss.org GENERAL CO-CHAIRS Viktor K. Prasanna, Univ. of Southern California, USA Jie Wu, Florida Atlantic University, USA VICE GENERAL CHAIR Ivan Stojmenovic, Univ. of Ottawa, Canada PROGRAM CHAIR Bhaskar Krishnamachari, Univ. of Southern California, USA PROGRAM VICE-CHAIRS Subhash Suri (Algorithms and Performance Analysis), Univ. of California at Santa Barbara, USA Wendi Heinzelman (Systems and Applications), Univ. of Rochester, USA Urbashi Mitra (Signal Processing and Information Theory), Univ. of Southern California, USA PROGRAM COMMITTEE (ALGORITHMS AND PERFORMANCE ANALYSIS) * Pankaj Agarwal, Duke University, USA * Jim Aspnes, Yale University, USA * Jit Bose, Carleton University, Canada * Chiranjeeb Buragohain, Amazon, USA * Carla Chiasserini, Politecnico di Torino, Italy * Sandor Fekete, Braunschweig, Germany * Jie Gao, Stony Brook, USA * Martin Haenggi, Univ. of Notre Dame, USA * Ravi Kannan, Microsoft, India * Sameer Khuller, Univ. of Maryland, USA * Steve LaValle, UIUC, USA * Mingyan Liu, Univ. of Michigan, USA * Paolo Santi, Univ. of Pisa, Italy * Sanjay Shakkottai, Univ. of Texas at Austin, USA * Peter Widmayer, ETH, Switzerland * Michele Zorzi, Univ. of Padova, Italy * Gil Zussman, Columbia University, USA PROGRAM COMMITTEE (APPLICATIONS AND SYSTEMS) * Tarek Abdelzaher, UIUC, USA * Nael Abu-Ghazaleh, SUNY Binghamton, USA * Stefano Basagni, Northeastern University, USA * Nirupama Bulusu, Portland State University, USA * Tracy Camp, Colorado School of Mines, USA * Andrew Campbell, Dartmouth College, USA * Mihaela Cardei, Florida Atlantic University, USA * Eylem Ekici, Ohio State University, USA * Salil Kanhere, Univ. of New South Wales, Australia * Holger Karl, Univ. of Paderborn, Germany * Dilip Krishnaswamy, Qualcomm, USA * Cecilia Mascolo, Cambridge University, UK * Chiara Petrioli, Univ. of Rome "La Sapienza", Italy * Joe Polastre, Sentilla, USA * Andreas Savvides, Yale University, USA * Curt Schurgers, UCSD, USA * Rajeev Shorey, GM Research, India * Krishna Sivalingam, UMBC, USA * Violet Syrotiuk, Arizona State University, USA * Sameer Tilak, San Diego Supercomputer, UCSD, USA * Cedric Westphal, DoCoMo Labs, USA * Ying Zhang, Xerox PARC, USA PROGRAM COMMITTEE (SIGNAL PROCESSING AND INFORMATION THEORY) * Jean Francois Chamberland, Texas A&M University, USA * Alex Dimakis, California Institute of Technology, USA * Emre Ertin, Ohio State University, USA * John Fisher, Massachusetts Institute of Technology, USA * Massimo Francheschetti, Univ. of California, San Diego, USA * Michael Gastpar, Univ. of California, Berkeley, USA * Dennis Goeckel, Univ. of Massachusetts, Amherst, USA * Prakash Ishwar, Boston University, USA * Tom Luo, Univ. of Minnesota, USA * Ivana Maric, Stanford University, USA * Rob Nowak, Univ. of Wisconsin, Madison, USA * Antonio Ortega, Univ. of Southern California, USA * Ashu Sabharwal, Rice University, USA * Anna Scaglione, Univ. of California, Davis, USA * Aaron Wagner, Cornell University, USA * Qing Zhao, Univ. of California, Davis, USA SPONSORED BY: IEEE Computer Society Technical Committee on Parallel Processing (TCPP) IEEE Computer Society Technical Committee on Distributed Processing (TCDP) Held in co-operation with ACM SIGARCH, ACM SIGBED, European Association for Theoretical Computer Science (EATCS) and IFIP WG 10.3. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Oct 30 07:57:03 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 120553A680C; Thu, 30 Oct 2008 07:57:03 -0700 (PDT) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ED243A67A7 for <6lowpan@core3.amsl.com>; Thu, 30 Oct 2008 07:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuwKszBYx1KO for <6lowpan@core3.amsl.com>; Thu, 30 Oct 2008 07:57:01 -0700 (PDT) Received: from server1.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id 82C353A680C for <6lowpan@ietf.org>; Thu, 30 Oct 2008 07:57:01 -0700 (PDT) Received: from [192.168.0.100] ([210.207.98.2]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id m9UEuwqt014965 for <6lowpan@ietf.org>; Thu, 30 Oct 2008 08:56:58 -0600 (MDT) From: Geoff Mulligan To: 6lowpan <6lowpan@ietf.org> Date: Thu, 30 Oct 2008 08:56:55 -0600 Message-Id: <1225378615.5654.103.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: [6lowpan] Call for Agenda items X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org The 6Lowpan working group will be meeting in Minneapolis. If you have items you would like to see on the agenda, please let the chairs know the topic, speaker and requested time allotment. In talking with Carsten it seems that the main work is surrounding HC, ND and probably some discussion related to the 6lowpan link model. Since we didn't get to talk about the routing requirements document last time, we should schedule some time to talk about how and if we should take this document forward. geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan