>
> So, in your mind how many SIR prefixes will be used in a
typical T1 operator domain?
Sri, very good question and I don't think anybody figured this yet for 5G..
> Also, how can we quantify the state that ILA introduces in
different parts of the network?
Please look at topology of section 2 in
https://tools.ietf.org/html/draft-herbert-ila-ilamp-00. ILA
routers collectively contain the all the mappings for the domain. The mappings
can be sharded on the routers serving a shard can be replicated. There are two
cases where ILA transformation is needed: at netwrok ingress (e.g. from
Internet) and intra domain traffic. The first case is served by
edge routers which as I mentioned would have considerable load. For intra
domain communications routers would be used aslo, but they can be augment by
the use of mapping caches in forwarding nodes.
Forwarding nodes perform ILA to SIR transformation before
delivery-- this does not need a lot of state.
Presumably every mobile node in the network has an identifier
to locator mapping. So the number of mappings in the domain equals the number
of mobile nodes. This number is expected to reach into the the billions, a
scale a single device won't have the memory for the full mapping table so it
would be sharded. Each shard also would be replicated N ways. So number of
routers needed is num_shards * num_replicas.
Another major consideration for scaling is changes to the
mapping system. It's a little harder to quantify since the load on the system
depends on the rate at which mobile nodes are moving. I'm not sure what the
rate of device moving in cellular network is (someone might have good insights
on that), but for scaling estimates I'm using 1 % (that is at an
given time 1% of devices are moving to different eNb).
Tom, 1% seems to be incorrect assumption even for 4G and also regardless of how
you partition shreds I see potential for massive state introduced in the core
(in various nodes); and I am not even sure how "making anchorless" solution is
the most important/pressing goal.
--
Uma C.
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
