Re: [rrg] belated msg: further description of the recommendation process
"Yangyang Wang" <wyystars@gmail.com> Thu, 17 December 2009 16:36 UTC
Return-Path: <wyystars@gmail.com>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8BC03A69FF for <rrg@core3.amsl.com>; Thu, 17 Dec 2009 08:36:15 -0800 (PST)
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 nxcWQrzUAZ6z for <rrg@core3.amsl.com>; Thu, 17 Dec 2009 08:36:08 -0800 (PST)
Received: from mail-yw0-f195.google.com (mail-yw0-f195.google.com [209.85.211.195]) by core3.amsl.com (Postfix) with ESMTP id AAD3328C0F5 for <rrg@irtf.org>; Thu, 17 Dec 2009 08:36:07 -0800 (PST)
Received: by ywh33 with SMTP id 33so2282509ywh.23 for <rrg@irtf.org>; Thu, 17 Dec 2009 08:35:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:references :subject:date:mime-version:content-type:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=e8TBUUo/DjMbzvyHgv6gIGvwu7+tv2BGdeuKhX/99+s=; b=dybkVxRoo04AyBTegVAbaE5Rv/gzBCVBwB1s5o5nzI0W1G2f/axrRdv8GHhWsKeqyd rwEL21Evzol1uI4iERjKEvAG03BYIavQeGbB8l8JjMuRXrG7IMvE14CmHHbz4gGh/fFI SCIMzjnQaALqZKx6g1iERMgN0QroeUPaqAbf0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:references:subject:date:mime-version :content-type:x-priority:x-msmail-priority:x-mailer:x-mimeole; b=PJvWkCEREjAfNwS7g3pi+mPC+HrJSZAKaYDm0zYRfTBeTmv+bmU+QcHF6mlRIeuOhm 56X7bPtFUmZrXoGd2x5nrW61w5ShAnshF2DWHUmEQ48XwW4m2QdXC6rxEF7rRJ7VfY8M JQCmo5L5AIpTHN/mvnx1C1T8BkBhWvhqPQrGM=
Received: by 10.150.101.15 with SMTP id y15mr4313534ybb.162.1261067738676; Thu, 17 Dec 2009 08:35:38 -0800 (PST)
Received: from wyystar (tu132183.ip.tsinghua.edu.cn [166.111.132.183]) by mx.google.com with ESMTPS id 6sm784195ywc.9.2009.12.17.08.35.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 17 Dec 2009 08:35:36 -0800 (PST)
Message-ID: <ADFBA7CF8EAA40D698CD30376F2ADCF6@wyystar>
From: Yangyang Wang <wyystars@gmail.com>
To: Lixia Zhang <lixia@CS.UCLA.EDU>, rrg@irtf.org
References: <5976B445-7209-4DE5-9D83-E2920265EB27@CS.UCLA.EDU>
Date: Fri, 18 Dec 2009 00:35:09 +0800
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0311_01CA7F79.F42C8850"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5843
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Subject: Re: [rrg] belated msg: further description of the recommendation process
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Dec 2009 16:36:15 -0000
Hi Lixia, Tony, and all, The following is a summary of our proposal "name overlay (NOL) service for scalable Internet routing". It is at preliminary stage for comments and hope that it can give some contribution to scaling issue. 1. key idea: ---------------- The basic idea is to add a name overlay (NOL) on the existing TCP/IP stack. Its functions include: 1) host names configuration, registration and authentication; 2) Initiate and manage transport connection channels (i.e., TCP/IP connections) by name; 3) keep application data transport continuity for mobility. At the edge network, we introduce a new type of gateway NTR (Name Transfer Relay), which block the PI addresses of edge networks into upstream transit networks. NTRs performs address and/or port translation between blocked PI addresses and globally routable addresses, which seem like today’s widely used NAT/NAPT devices. Both legacy and NOL applications behind a NTR can access the outside as usual. To access the hosts behind a NTR from outside, we need to use NOL traverse the NTR by name and initiate connections to the hosts behind it. Different from proposed host-based ID/Locator split solutions, such as HIP, Shim6, and name-oriented stack, NOL doesn’t need to change the existing TCP/IP stack, sockets and their packet formats. NOL can co-exist with the legacy infrastructure, the core-edges separation solutions (e.g., APT, LISP, Six/one, Ivip, etc.) 2. gains: ------- 1) Reduce routing table size: Prevent edge network PI address into transit netwok by deploying gateway NTR 2) Traffic Engineering: For legacy and NOL application initiating session, the incoming traffic can be directed to a specific NTR by DNS answer for names. In addition, for NOL application, its initial session can be redirected from one NTR to other appropriate NTRs. These mechanisms provide some support for traffic engineering. 3) Multi-homing: When a PI address network connects to Internet by multi-homing with several providers, it can deploy NTRs to block the PI addresses into provide networks. And the NTRs can be allocated PA addresses from the upstream providers and store them in NTRs’ address pool. By DNS query or NOL session, any session that want to access the hosts behind the NTR can be delegated to a specific PA address in the NTR address pool. 4) Mobility: NOL layer manage the traditional TCP/IP transport connections, and keeps application data transport continue by setting breakpoints and sequence numbers in data stream. 5) No need to change TCP/IP stack, sockets and DNS system. 6) No need for extra mapping system. 7) NTR can be deployed unilaterally, just like NATs 8) NOL applications can communicate with legacy applications. 9) NOL can be compatible with existing solutions, such as APT, LISP, Ivip, etc. 10) End user controlled multi-path indirect routing based on distributed NTRs. This will give benefits to the performance-aware applications, such as, MSN, Video streaming, etc. 3. costs ------ 1) Legacy applications have trouble with initiating access to the servers behind NTR. Such trouble can be resolved by deploying NOL proxy for legacy hosts, or delegating globally routable PA addresses in NTR address pool for these servers, or deploying server proxy outside NTR. 2) It may increase the number of entries of DNS, but not drastic, because it only increases DNS entries in domains granularity not hosts. The name used in NOL, for example, just like email address hostname@domain.net. The needed DNS entries and query is just for "domain.net", and The NTR knows "hostnames". The DNS entries will not only be increased, but its dynamic might be agitated as well. However the scalability and performance of DNS is guaranteed by name hierarchy and cache mechanism. 3) Address translating/rewriting costs on NTRs. 4. documents -------------- Current documents are in the attachment of this email, including a slide and a summary.
- [rrg] belated msg: further description of the rec… Lixia Zhang
- Re: [rrg] belated msg: further description of the… Patrick Frejborg
- Re: [rrg] belated msg: further description of the… Michael Menth
- Re: [rrg] belated msg: further description of the… Robin Whittle
- Re: [rrg] belated msg: further description of the… Tony Li
- Re: [rrg] belated msg: further description of the… Tony Li
- Re: [rrg] belated msg: further description of the… Brian E Carpenter
- Re: [rrg] belated msg: further description of the… Scott Brim
- Re: [rrg] belated msg: further description of the… Noel Chiappa
- [rrg] On mapping systems Michael Menth
- Re: [rrg] belated msg: further description of the… Vince Fuller
- Re: [rrg] belated msg: further description of the… Brian E Carpenter
- [rrg] Summary of RANGI//re: belated msg: further … Xu Xiaohu
- Re: [rrg] belated msg: further description of the… Lixia Zhang
- Re: [rrg] belated msg: further description of the… Lixia Zhang
- Re: [rrg] belated msg: further description of the… Lixia Zhang
- Re: [rrg] belated msg: further description of the… Lixia Zhang
- Re: [rrg] belated msg: further description of the… Tony Li
- Re: [rrg] Summary of RANGI//re: belated msg: furt… Tony Li
- Re: [rrg] belated msg: further description of the… Tony Li
- Re: [rrg] belated msg: further description of the… $witch
- Re: [rrg] belated msg: further description of the… Charrie Sun
- Re: [rrg] belated msg: further description of the… Noel Chiappa
- Re: [rrg] belated msg: further description of the… HeinerHummel
- Re: [rrg] belated msg: further description of the… Brian E Carpenter
- Re: [rrg] belated msg: further description of the… Flinck, Hannu (NSN - FI/Espoo)
- Re: [rrg] belated msg: further description of the… Patrick Frejborg
- Re: [rrg] belated msg: further description of the… heinerhummel
- Re: [rrg] belated msg: further description of the… Flinck, Hannu (NSN - FI/Espoo)
- Re: [rrg] belated msg: further description of the… Yangyang Wang
- [rrg] Summary of GLI-Split Michael Menth
- Re: [rrg] belated msg: further description of the… Lixia Zhang