Re: [rrg] belated msg: further description of the recommendation process

"Yangyang Wang" <> Thu, 17 December 2009 16:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C8BC03A69FF for <>; Thu, 17 Dec 2009 08:36:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nxcWQrzUAZ6z for <>; Thu, 17 Dec 2009 08:36:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id AAD3328C0F5 for <>; Thu, 17 Dec 2009 08:36:07 -0800 (PST)
Received: by ywh33 with SMTP id 33so2282509ywh.23 for <>; Thu, 17 Dec 2009 08:35:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id y15mr4313534ybb.162.1261067738676; Thu, 17 Dec 2009 08:35:38 -0800 (PST)
Received: from wyystar ( []) by with ESMTPS id 6sm784195ywc.9.2009. (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 17 Dec 2009 08:35:36 -0800 (PST)
Message-ID: <ADFBA7CF8EAA40D698CD30376F2ADCF6@wyystar>
From: Yangyang Wang <>
To: Lixia Zhang <lixia@CS.UCLA.EDU>,
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-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 


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 The needed DNS entries and 

    query is just for "", 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.