Re: My ID on addressing
Garrett.Wollman@uvm.edu Tue, 12 January 1993 20:49 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09350;
12 Jan 93 15:49 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09346;
12 Jan 93 15:49 EST
Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa24947;
12 Jan 93 15:50 EST
Received: by thumper.bellcore.com (4.1/4.7)
id <AA02988> for ietf-archive@nri.reston.va.us; Tue, 12 Jan 93 15:47:06 EST
Received: from sadye.emba.uvm.edu by thumper.bellcore.com (4.1/4.7)
id <AA02978> for /usr/lib/sendmail -oi -fowner-pip X-pip;
Tue, 12 Jan 93 15:47:05 EST
Received: by sadye.emba.uvm.edu id AA14846
(5.65/6.02); Tue, 12 Jan 93 15:47:02 -0500
Date: Tue, 12 Jan 93 15:47:02 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Garrett.Wollman@uvm.edu
Message-Id: <9301122047.AA14846@sadye.emba.uvm.edu>
To: pip@thumper.bellcore.com
Subject: Re: My ID on addressing
In-Reply-To: <9301120405.AA02979@chiya.bellcore.com>
References: <9301120405.AA02979@chiya.bellcore.com>
<<On Mon, 11 Jan 93 23:05:26 EST, tsuchiya@thumper.bellcore.com (Paul Tsuchiya) said: > I suggest that you try to pry it loose from the DNS WG. I can't > imagine that they'd know what to do with it....... I sent a note to the ID person at CNRI asking to have it re-filed. > The one thing I either didn't understand or didn't agree > with in your spec is the NAP identifiers. I couldn't figure > out if the NAP identifiers are used just to talk to NAPS, > or if they actually become part of the address as it is > encoded in the packet. > Probably you could clear it up for me by giving an example > of the process you describe in paragraph 4 of section 2.4. > There you talk about querying local and foreign NAPs, and > getting fragments in return. I don't really understand > this part. Well, I'll see if I can explain this better. The idea behind a NAP identifier is that it's a cookie that you get from the DNS that has meaning for the ``foreign NAP address server''. (For administrativbe convenience, the DNS also allows you to turn that cookie into a name; there should be no software which actually depends on this ability.) A concrete example is in order (I didn't want to include something like this in the ID because I didn't want to give the impression that it was PIP-specific). Say my machine, tsornin.emba.uvm.edu, wants to talk to chiya.bellcore.com. Here are the steps involved: 0. Let's say tsornin has NAP ID 23, provider part 178, and local address fragment "4(down)5". The address to my NAP is "4(up)5(up)200(up)195(up)3". 1. Look up `chiya.bellcore.com.' in the DNS, and get back an EID, a NAP ID (magic cookie), a provider part (another magic cookie), and the address fragment "15(down)23". 2. Compare the NAP ID to my own. 3a. The NAP IDs differ (call it 35), so send a message to the foreign NAP address server or servers at my site, asking for the address of NAP ID 35. Get back the fragment "2(up)3(up)29(none)5(down)68". 3b. The NAP IDs are the same, so we won't ever climb that high in the hierarchy and don't need to know an inter-NAP address fragment. 4a. Send a message to the provider-part server at the foreign NAP asking for the fragment corresponding to provider part 12. Get back the fragment "25". 4b. Send a message to the provider-part server at our NAP asking for the fragment corresponding to provider part 12. Get back the fragment "3(down)19". 5a. The FTIF chain to get from tsornin.emba.uvm.edu to chiya.bellcore.com is then 4(up)5(up)200(up)195(up)3(up)2(up)3(up)29(none)5(down)68(down)25(down) 15(down)23 5b. The FTIF chain is then 4(up)5(up)200(up)195(none)19(down)15(down)23 If your host wants to talk back to me, it can either reverse the address, or perform an address calculation process of its own, possibly generating something different. (For example, I may prefer to use network X to talk to you, but you want to use network Y to talk back to me.) I will admit that I picked addresses that were more complex than reality.... > The architecture that I am thinking of (that hasn't really > been published yet.....sorry) Well, please, publish it! > I'd guess that I am trying to do with the pip header server > that you are doing with the NAPs, so I'd like to see how > we differ in approach...... Well, the basic idea is to note that geographic addressing is a fairly decent model of how the Internet actually looks at any given moment; where it breaks down is when you start time going and watch the network change. This scheme is basically a geographic system in which a level of indirection has been added so that the location information doesn't get in the way of changes in the routing, with Clark's Route Fragments stuck on as a way to get between locations. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance. uvm-gen!wollman | It is a bond more powerful than absence. We like people UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant
- My ID on addressing Garrett.Wollman
- Re: My ID on addressing Paul Tsuchiya
- Re: My ID on addressing Garrett.Wollman