Re: [icnrg] ICN routing and locators

Dino Farinacci <farinacci@gmail.com> Mon, 27 June 2016 17:51 UTC

Return-Path: <farinacci@gmail.com>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0025712D664 for <icnrg@ietfa.amsl.com>; Mon, 27 Jun 2016 10:51:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjEKtd-hP8jm for <icnrg@ietfa.amsl.com>; Mon, 27 Jun 2016 10:51:31 -0700 (PDT)
Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FA2812D797 for <icnrg@irtf.org>; Mon, 27 Jun 2016 10:51:30 -0700 (PDT)
Received: by mail-pa0-x236.google.com with SMTP id bz2so61065441pad.1 for <icnrg@irtf.org>; Mon, 27 Jun 2016 10:51:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cAInm67udTgmD1nZPx3xSU14sp7sf1LNWOabnDw35io=; b=m4ssoYqStYDqKR+8yc//quhtKv8VOmBt7NxoeOZhBetfI+wq5j3wd9NfLKfz06wJU0 mgKGk/A8wynyK/N1talTXk57mNohsAqg1fQlqqhXIwhUnfngbUJoamMaDucRJObAnumX dlZ8u0uGAzlNyev2KDQuPE655WRGTrDyIlyfJD8bZfg4KIKgcmjUYhnm/qyuggXfFPEO yEGh5UGjW2ryvDwP2tU77b86cuETePOX7Pa7FghET1T/3qB3mR/36BiHb69pZGRaqvdH WjHx2efwH9tfbVJG51G+GHpjtfmhU/YGdD0EnHm1DEMS1dJc6BYVAkZTOXiW1toZFN3H 8pAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cAInm67udTgmD1nZPx3xSU14sp7sf1LNWOabnDw35io=; b=jJTRo83s2psmaODDqVwbwwZLQcMC6fNu7TnqpWw43weS+TP8+Mf8IKhOBo/Rafc4O9 TgofQxcylZVH+jPXR5Jte0TPirPVNfjeNv0IX6gilqXfV+pRgDkL0s3N0kiqJMfRIe28 WpU6CFQM8nPtLgwPMLzGu9XTNh4cVxSo5ANfnELyfaxkCsYTVefsJDzrYLswu5pK+nG7 ZUDuKBHSjDzqsG9SQUC+X7vUwC7xZldtr/ink4H0rpXL44uZrB6VR243iWpa9TJP8QQA f9LFcUYETVxWd1YZEfLmmRX0h+n5/uYnkhDs4+UfL9Pz6Er/eMGCzlQ6BYL28zfuG3Bh 1SUg==
X-Gm-Message-State: ALyK8tK0/qwG8Gaxvk8zQ2DcLpyD8+xcespluSRH4HP48k0JlJLo4AaLal3dqy3Vu5Qivw==
X-Received: by 10.66.42.102 with SMTP id n6mr36887566pal.60.1467049889653; Mon, 27 Jun 2016 10:51:29 -0700 (PDT)
Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id bt5sm1339018pac.47.2016.06.27.10.51.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 27 Jun 2016 10:51:29 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <6E05A3DC-B72C-48C7-92C9-8B9625B98EB4@parc.com>
Date: Mon, 27 Jun 2016 10:52:06 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <D5B7FD95-1694-4664-AFB2-9825BB345FA5@gmail.com>
References: <6E05A3DC-B72C-48C7-92C9-8B9625B98EB4@parc.com>
To: Marc.Mosko@parc.com
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/ub-zBBlgXe4tIjibrLZosbZpEx0>
Cc: icnrg@irtf.org
Subject: Re: [icnrg] ICN routing and locators
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jun 2016 17:51:34 -0000

You could have a look at the LISP mapping database system. We have many different EID-record types that can be registered with the mapping system. Here are two recent types we just added.

https://datatracker.ietf.org/doc/draft-farinacci-lisp-name-encoding
https://datatracker.ietf.org/doc/draft-farinacci-lisp-geo

Certainly a ICN named object can be encoded as a distinguished-name in the LISP mapping system.

Let us know if the LISP WG can help you all out!

Thanks,
Dino

> On Jun 24, 2016, at 3:53 PM, <Marc.Mosko@parc.com> <Marc.Mosko@parc.com> wrote:
> 
> At this year’s Dagstuhl seminar (and prior years I understand), there has been talk about locator/identifier separation in ICN.  I would like to get feedback from ICNRG if we should continue to discuss this and see if there’s any consensus on the topic.  
>  
> The main issue related to this is how to use names in content/data objects that do not exist in the core routing tables, but do exist in some edge network(s) or edge nodes.  Two other related issues to this topic are supporting mobility and exploiting off-path copies of content (assuming routing only points towards an authority).
>  
> 1)       Some suggest that using compact network-independent routing could be sufficient.  These support application-assigned names with modest routing stretch. After first contact via the compact routing scheme, nodes may use topology-aware labels to speed up communications (i.e. stretch 1 routing with very small labels) [e.g. the Tagnet approach].  [see, for example, https://csperkins.org/research/thesis-msci-mooney.pdf]
>  
> 2)       NDN proposes NDNS (a DNS/DANE like system) to distribute signed link objects that are used in map-and-encap to route an Interest across the default-free zone (DFZ) to a region that can satisfy the original Interest predicate. The link is put in a modifiable portion of the Interest called the “selected delegation.” [see http://named-data.net/wp-content/uploads/2015/03/SNAMP-NDN-Scalability.pdf]
>  
> 3)       CCNx has been promoting nameless objects, where a Content Object without a name may be retrieved by an Interest with any name and a hash restriction.  It’s been noted that this mode is similar to a NetInf approach.  This means the name in the Interest could identify a location in some cases or an object in others.  There is not a specified method yet for distributing those locator names to use to find nameless objects, though there is some talk of using an NRS (could be like NDNS) method or tracker services.
>  
> 4)       There are some proposals [draft-ravi-ccn-forwarding-label-02] in ICNRG to add a forwarding label field to an Interest in CCNx.  This would provide functionality like the NDN link.  The formation of the forwarding label (FL) is actually very similar to the NDN link, though it does not have mandatory signing and it uses the terms locator/identifier whereas the NDN link uses the term map-and-encap.
>  
> 5)       There is also in ICNRG the “hybrid naming” proposal [draft-zhang-icnrg-hn-04.txt].  Although this splits the name between 3 pieces (hierarchical, flat, and attributes), I do not think it addresses having a changeable part based on current attachment of the data source.
>  
> One could probably show that #2 NDN link and #4 forwarding label are about the same as #1, as compact routing schemes like TZ and many others work by assigning a landmark some short distance away from a destination, then route towards the landmark then from the landmark to the destination (except they require an external NRS).  That’s essentially what the links do, though without the formal properties of compact routing.
>  
> In case #1, I think we can just keep going as we’re going and punt to routing.  In cases #2 - #4, I think we could consolidate options if desired.  If nothing else, we could close the gap between #2 NDN link and #4 forwarding labels.  Case #5 on hybrid naming I think needs to describe how mobility, off-path caching, and non-globally routable names work.
>  
> Marc
> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg