Hi Xu, Sorry for sending an empty message before.
I've been reading your draft and have a couple of comments. First of all, your HRA looks quite similar to what is defined in the Node Identity Internetworking Architecture, or NIIA like it's shortened on this list. It also employs loc/id split with cryptographic host identifiers, has the notion of locator domains (LDs) and has borders routers (LBDRs/NRs) to bridge between the locator domains. Routing is also based on a two-level routing - identifier-based routing across LD borders and locator based routing within one LD. The main difference is that HRA already prescribe running an LD based routing protocol. Unfortunately, the routing protocol is not described in the current draft version. NIIA is in it's simplest form built on a registration based routing scheme, but is open to run other (LD-based) routing protocols as well. A second difference is that you allow a hierarchical host identity tag. HRA suggests to put destination-host locators into the packets, already starting from the source host. IMO, this is problematic for the following reasons: a) If you employ an LD schemes, the destination's locator has no meaning for the source host if source and destination belong to different LDs b) How should the field in the protocol be dimensioned if you don't know in advance which underlying networking technologies will be used, i.e. you might not know the size of the locator. c) If the source host has to retrieve a destination host's locator from DNS or any other lookup system, then this information needs to be updated in the global lookup system for every locator change of the end-host. If it is e.g. based on DNS, DNS needs to be updated for every movement that implies an IP address change. What's the main reason for putting the destinations locator into the packet? Some comments on the comparison section of HRA and NIIA: > 1) Within the NIIA, there should be a stable core LD, and all the > other LDs should be connected to the core LD directly or indirectly. > Most of the traffic will go across the core LD. While within HRA, > there is no limitation on the topology, that is to say, those LDs > within HRA can be connected in mesh." NIIA assumes a (rather) stable core LD (like e.g. todays IPv4 backbone network), which gives some stability to the architecture. However, it still allows different LDs to be connected in a mesh structure. Traffic only has to go across the core LD if there is no better route known. The idea in NIIA is, if you don't know where to go, go to the core LD and you will find your way. > 2) Within the NIIA, as the network topology is tree-based, there > seems no need to run a LD-based routing protocol. Besides, the NR use > host-based routing mechanism which means a potential scalability > issues if LD contains a lot of hosts. While in HRA, LDBRs exchange LD > reachability information and support LD-based routing mechanism. It is nowhere stated in the NIIA draft that topology has to be a tree. Basically, LD structure can be anything. It is true that the registration based (default-) routing as described in the draft leads to tree-like structures, but alternative routes are still allowed. The paths build-up by registrations should however create a DAG (directed acyclic graph), it does not need to be a tree. Section 3.4.2 of the NIIA draft discusses effects of multihomed hosts and networks. Running an LD-based routing mechanism inside NIIA would also be perfectly fine, it was just excluded from the first architecture draft for simplicity. > 3) Within the NIIA, the existence and characteristics of connectivity > between two locator domains, especially the edge locator domains, may > change dynamically on relatively short timescales, due to routing > changes, mobility or multi-homing events. LD mobility triggers host > within the mobility LD to update the registration, especially when > the CER is changed, that's to say, the LD mobility is not fully > transparent to the host. Within HRA, the connectivity between locator > domains is relatively stable and the mobility of partial network in > LD still depends on the NEMO [RFC3963] like mechanism, and network > mobility is transparent to those hosts within mobile network. What do you mean with CER? Whether a mobility event is transparent to an end-host in NIIA depends on the type of mobility. If a whole LD moves, and the NR takes care of updating the hosts' registration on behalf of them, then the mobility is fully transparent to all hosts in that LD. Best regards, Simon PS: I wonder a bit why your LDBRs are named NRs in the example of section 4.4.4? ;-) > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Xu Xiaohu > Sent: Friday, November 16, 2007 12:11 PM > To: 'Routing Research Group list' > Cc: 'Tony Li'; [EMAIL PROTECTED] > Subject: [RRG] A new draft about Hierarchical Routing Architecture > > Hi all, > > I have just finished a draft about Hierarchical Routing > Architecture (HRA), > which is also a kind of id/loc split solution. The following > is an abstract > of HRA. > > Abstract: Hierarchical Routing Architecture (HRA) is a kind > of id/locator > split solution. It introduces a hierarchical routing mechanism (a > combination of LD-based routing and prefix-based routing) to > support routing > across multiple independent address spaces, besides, it also adopts a > hierarchical host identifier to ease the management of a > global id/locator > mapping system. With HRA, the Internet routing scalability > and stability are > improved evidently, and the scalability issue of flat HIT in > HIP is also > solved, besides, the necessity of adopting IPv6 is also > eliminated to some > extent as those locator domains can adopt overlapped IPv4 > address spaces. > > Sorry I missed the deadline of 00-version submission, so I > have to attach > this draft in email. Any comments are welcomed. > > Best regards, > > Xiaohu Xu > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
