Hi,
I'm joining the school of ID/Locator separation, and would like to propose
the following architecture:
A. Fundamentals:
o Skeletons:
o ID is global, Locator is local(private) to AS.
o Keep use of DNS, with some extension.
o TCP works on ID, IP on Loctor, Gateways(BGP) on AS #.
o Gateways advertises only AS #s, not network prefixes.
o Corollaries:
o Number space of AS is limited to 2^^16(64K) in one tier.
o AS tier recurs hierarchically, downward and upwards(or inwards
and outwards). In each tier, the maximum number of ASs is limited to 2^^16.
o AS(cloud) can float within and across tiers. AS(ISP) can change
is neighbor relation anytime in the course of its existence within and
across the tier architecture.
o Implementation choices:
o Take IPv6 and IPv6 addresses as IDs. That is, IP addresses in the
current Internet infrastructure is to be used as IDs, not anymore as
locators.
o DNS is extended to serve not only name-to-address(ID) mapping but
also ID-to-AS mapping.
B. Scenario of outgoing communication example:
1. DNS returns the remote (glabal) ID as well as the AS number it
belongs to.
2. TCP establishes connections by use of ID.
3. TCP requests, to IP, transmission of segments with the AS number, as
a parameter, of the domain where the destination peer belongs.
4a. If the target AS is local domain, IP uses a local locator to deliver
the packet.
4b. If the target AS is foreign, IP uses a local locator to deliver the
packet to the egress gateway(BGP) router.
5. Local gateway relays the packet to one of the next hop gateways that
advertised the target AS #.
C. Scenario of incoming communication example:
(Your homework.)
D. Consequences.
o Gateway routing table doesn't explode, never exceeds 64K(2^^16).
o AS tier can recurs, theoretically, indefinitely. The whole Internet
can scale to infinity.
o NAT is a norm, not an evil.
o The current IP address management infrastructure won't be abandoned.
They operate exactly the same way as it does. Only that the number is now
used as IDs, not for locators.
o The current DNS infrastructure is maintained, only with a bit of
extension. It now has to keep database of (domain name, ID, AS number)
tuples.
o Minimal disturbance to the current Internet infrastructure, with a
path out for sustainable scalability.
I'm also attaching the text. The idea has yet to be elaborated more and be
documented in far more detail in a proper form.
Your comments are solicited.
On Wed, Nov 18, 2009 at 12:46 AM, Tony Li <[email protected]> wrote:
> Lixia Zhang wrote:
>
>>
>>> Well, what we already know is that we want our routing tokens to be
>>> changeable. We need hierarchy in the address space to provide scalability.
>>> We have seen that we need to form that hierarchy on the topology,
>>>
>>
>> the above seems a general statement that everyone would agree.
>> the real question is: are we talking about a single address hierarchy that
>> everyone's routing table would conform to, or somewhat different hierarchies
>> as viewed from different ASes...
>>
>
>
> First, 'address' is a horribly overloaded term that we should simply excise
> from our discussions. We cannot have a semantically useful conversation if
> we cannot have common, precise terminology.
>
> I'm going to interpret your 'address' in the above to be purely a routing
> token (a.k.a., a locator). Yes, I think we agree that we need multiple
> namespaces, with at least one locator and one identifier namespace.
>
> You _could_ have more, but it would seem to fly in the face of Occam's
> razor. That said, it's not an unthinkable architecture.
>
>
>
> So when a host changes its position in the topology, the routing token
>>> needs to change.
>>>
>>
>> I could not decipher the last sentence: when a host changes its attachment
>> point, its IP address changes -- do you mean routing token = IP address?
>>
>
>
> Again, you're falling trap to the vague meaning of 'address'. Yes, when a
> host changes its point of attachment, its locator needs to change.
>
>
>
> Unfortunately, that breaks the transport connection.
>>>
>>
>> depends.
>> there exist multiple implementations today that do not break transport
>> connections when host change IP addresses.
>>
>
>
> Do tell. Normal TCP will not do this.
>
>
>
> Relevance? I have yet to see one proposal make this mistake.
>>>
>>
>> Do not depend on DNS to get packet delivered.
>>
>
>
> Sorry, we already broke that. When DNS is down, the net is down. ;-)
>
>
>
> But we still want to be able to send IP packets even when DNS is done.
>>
>
> Well, assuming that the end user already has the necessary bits, I have yet
> to see any proposal that will not deliver the packets, even if DNS is down.
> Did I miss something? With ILNP, it will revert to legacy IPv6 semantics,
> which seems perfectly acceptable.
>
> Note that all proposals are going to have issues when their mapping system
> is down. Again, the real point of the original point is to avoid the
> circular dependency, where you can't ever get the system up. Again, I
> haven't seen anyone fall into that trap. And it applies to the mapping
> system, not just DNS.
>
> Tony
>
>
> _______________________________________________
> rrg mailing list
> [email protected]
> http://www.irtf.org/mailman/listinfo/rrg
>
--
Regards,
DY
http://cnu.kr/~dykim <http://cnu.kr/%7Edykim>
SCALABLE INTERNET
dykim, 09.11.18
A. Fundamentals:
o Skeletons:
o ID is global, Locator is local(private) to AS.
o Keep use of DNS, with some extension.
o TCP works on ID, IP on Loctor, Gateways(BGP) on AS #.
o Gateways advertises only AS #s, not network prefixes.
o Corollaries:
o Number space of AS is limited to 2^^16(64K) in one tier.
o AS tier recurs hierarchically, downward and upwards(or inwards and
outwards). In each tier, the maximum number of ASs is limited to 2^^16.
o AS(cloud) can float within and across tiers. AS(ISP) can change is
neighbor relation anytime in the course of its existence within and across the
tier architecture.
o Implementation choices:
o Take IPv6 and IPv6 addresses as IDs. That is, IP addresses in the
current Internet infrastructure is to be used as IDs, not anymore as locators.
o DNS is extended to serve not only name-to-address(ID) mapping but
also ID-to-AS mapping.
B. Scenario of outgoing communication example:
1. DNS returns the remote (glabal) ID as well as the AS number it belongs
to.
2. TCP establishes connections by use of ID.
3. TCP requests, to IP, transmission of segments with the AS number, as a
parameter, of the domain where the destination peer belongs.
4a. If the target AS is local domain, IP uses a local locator to deliver the
packet.
4b. If the target AS is foreign, IP uses a local locator to deliver the
packet to the egress gateway(BGP) router.
5. Local gateway relays the packet to one of the next hop gateways that
advertised the target AS #.
C. Scenario of incoming communication example:
(Your homework.)
D. Consequences.
o Gateway routing table doesn't explode, never exceeds 64K(2^^16).
o AS tier can recurs, theoretically, indefinitely. The whole Internet can
scale to infinity.
o NAT is a norm, not an evil.
o The current IP address management infrastructure won't be abandoned. They
operate exactly the same way as it does. Only that the number is now used as
IDs, not for locators.
o The current DNS infrastructure is maintained, only with a bit of
extension. It now has to keep database of (domain name, ID, AS number) tuples.
o Minimal disturbance to the current Internet infrastructure, with a path
out for sustainable scalability.
Your comments are solicited._______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
