Recursive Internetwork Architecture: Difference between revisions

Content deleted Content added
Hayazin (talk | contribs)
Rewriting: Introduction (corrected a typo and qualified more)
Hayazin (talk | contribs)
Line 97:
Saltzer took his model from operating systems, but it was not completely correct for internetworks, since there may be more than one path between the same pair of nodes (let alone whole networks). The obvious solution is that routes are sequences of nodes, and at each hop each node chooses the most appropriate PoA (path) to forward the packet to the next node. Therefore, routing is a two-step process: First the route as a sequence of node addresses is calculated, and then, for each hop, an appropriate PoA to select the specific path to be traversed is chosen. These are the steps to generate the forwarding table: forwarding is still performed with a single lookup. Moreover, the last step can be performed more frequently in order to exploit multi-homing for load-balancing.
 
With this naming structure, support for mobility and multi-homing is inherent, if the properties for the names are chosen with care: application names are ___location-independent to allow an application to move around, node addresses are ___location-dependent but route-independent. PoA addresses are by nature route-dependent. Applying this naming scheme to RINA, with recursive layers, an interesting observation can be made: mapping application names to node addresses is theanalogous same mapping thanto mapping node addresses to PoAs. In other words, forat any layer N, nodes at the layer N+1 are applications and nodes at the layer N-1 are points of attachment, making this relationship relative.
 
The [[Locator/Identifier Separation Protocol]] (LISP or Loc/ID split) <ref name="lisp">D. Farinacci, V. Fuller, D. Meyer, and D. Lewis. Locator/ID Separation Protocol (LISP). Draft IETF LISP 18, december 2011</ref> has been proposed by [[IETF]] as a solution to issues as the scalability of the routing system. LISP main argument is that the semantics of the IP address are overloaded being to be both locator and identifier of an endpoint. LISP proposes to address this issue by separating the IP address into a locator part, which is hierarchical, and an identifier, which is flat. However this is a false distinction: in Computer Science it is impossible to locate something without identifying it and to identify something without locating it, since all the names are using for locating an object within a context.<ref name="Saltzer"/> Moreover, LISP continues to use the locator for routing, therefore routes are computed between locators (inter- faces). However, a path does not end on a locator but on an identifier, in other words, the locator is not the ultimate destination of the packet but a point on the path to the ultimate destination.<ref name="lispno"/> This issue leads to path-discovery problems, as documented by <ref name="lispis"/> whose solution is known not to scale.