Hi Toni, Thanks for your reply, in which you wrote:
>>> do you consent that nodes (instead of interfaces) have to be >>> referenced with locators(addresses)/identifiers? >> >> I do not support the change you are suggesting, which I >> understand involves changing the Internet protocols to coerce all >> nodes to communicate only in terms of themselves, irrespective of >> what interfaces they are using. > > The change is relevant to the general communication between nodes > where packet relaying occurs. The distinction of nodes' interfaces > is only adequate in physical communication between neighbors. I don't understand these two sentences. >> One reason is that a node might not want incoming traffic to >> arrive on all its interfaces. Another is that it might not want >> to send traffic on all its interfaces. > > Should the node bother its overseas correspondents with that? > Sending them packets with interface reply-to addresses. That is what happens now, and it involves no complication or extra effort to the correspondent node. I will call the initiating node "AAA" and the node it sends packets to, and expects a reply from "BBB". BTW, I consider "node" and "host" to mean the same thing, but am using the former since this seems to be your preference. It would be more complexity and effort for BBB to meet the requirements of being told by AAA to send packets back to AAA addressed to two or more IP addresses - or to two or more Locators, if Locator / Identifier Separation was introduced. This would be more effort, since BBB would need to store more information, make decisions about how to address the packets, and presumably do extra work to decide which of the two or more IP addresses / Locators to use, based on whether they were reachable, or some other criteria such as AAA's preferences for which to use, or perhaps some load sharing preferences expressed by AAA. > For traffic arriving on particular interfaces nodes shall make > arrangements with their linked gateways. For sending, each node's > decision is its own business. I agree with the second sentence regarding the current arrangements - each node sends packets on whichever interface it likes. How the stack and application decides this depends on how the application is written. However, in Locator / Identifier Separation (as used by Core Edge Elimination architectures), BBB can have two or more Locators which match the Identifier for AAA. Then BBB (presumably the stack, since the application is either written to refer to AAA by its Identifier, or is referring to AAA via one of its multiple IP addresses) is expected to make decisions about which of these Locators to use in the destination field of packets it sends to AAA, and those decisions are expected to support portability, multihoming, inbound TE (from AAA's perspective) and probably mobility of AAA. So Locator / Identifier Separation involves a great deal more effort and responsibilities for all hosts - including sending and receiving more packets and/or longer packets, and also typically involving longer delays due to the need to look up an Identifier to reliably ascertain its current Locator(s). I argue against this: "Overloading" of Loc & ID functions is good for hosts and should be maintained 2010-06-22 http://www.ietf.org/mail-archive/web/rrg/current/msg07017.html >> Some interfaces may be slow, expensive or unreliable - or the >> node may want to avoid using them so they are ready to accept >> some other stream of packets. > > So if you are a node, make the choice for yourself. Don't make > remote (more than a hop away) nodes take the burden of your inner > considerations. Sure - it is easy for node AAA to do this regarding outgoing packets, as long as either: BBB uses existing protocols, in which a session is bound to whichever interface and IP address AAA uses to start the session. or BBB uses Loc/ID Separation so it will accept packets from multiple interfaces of AAA as part of the one session. However, this extra burden of work would be placed on all nodes if Locator / Identifier Separation is introduced. With Loc/ID Separation, AAA says to BBB, or to any other node it communicates with, something like: My locators are 111, 222 and 333. Please send packets to whichever of these is reachable. If two or more are reachable, then please send them preferably to 222, since this is the fastest and cheapest link. >> Some interfaces might, for policy reasons, be unsuitable for >> particular types of communication. Some interfaces might use >> networks with too high a latency, or too high a packet loss, or >> too small an MTU. > > These are node's own regulations, so nodes shall apply them with > internal means. OK - but if you are proposing that the Internet's routing and addressing system be changed so that a node (AAA) can only identify itself, for the purpose of receiving packets from another node, by its node Identifier, with the requirement that all of its interfaces can be used for receiving packets from the correspondent node (BBB), then you are requiring BBB to know all these interfaces and to make decisions about which of these interfaces to send packets to, in a way which reflects the desires and needs of AAA. For instance, AAA might have: 1 - A 3G interface: not as fast as the others, but which may persist if the WiFi link dies. However, it may disappear at any moment, since even without movement, the radio propagation conditions and base-station management system may cause the the wireless interface to another base-station which uses another IP-gateway, in which case this interface will lose its current IP address or Locator, and gain another one via the new IP-gateway. The traffic on this link is typically paid for at a rate higher than the other two links below. 2 - A WiFi link within the office. This will generally persist even if the link below disappears. This is generally fast and involves little or no expense. 3 - A 100Mbps or 1Gbps wired Ethernet link. This is faster than the other two, and generally preferred, but if the device has its cable unplugged so it can be moved somewhere else, this will disappear and WiFi link would be the preferred interface to receive packets on. You could have a physical device, such as a laptop (or in the future a 3G / WiFi Dick Tracy watch, which the latest Apple Nano is fast approaching) have multiple node Identifiers, even though it it is a single physical node. Each such node Identifier could have a different set of Interfaces (AKA Locators in a Loc/ID Separation architecture). This would provide some flexibility, in that the node's applications could choose to use a particular node Identifier from this set depending on what sort of communications the application was engaging in. >> So, to make your idea workable, I think a given physical >> computer would need to generate multiple Identities, with each >> such Identity assigned a set of its Interfaces suitable for >> particular kinds of communication. > > No. Particularization of those kinds of communication is the > computer's own affair. So the computer shall take care of > identification of the various kinds of communication internally. I don't understand this well enough to respond. >> This can already be done by any application which is suitably >> written, as I just described. > > This is a hand-over of the responsibility for communication policy > to a certain other layer. OK, to easily jump among "layers" we just > need Role-Based Architecture, where each function is performed by a > relevant actor – application, protocol heap, driver. > http://isi.edu/newarch/DOCUMENTS/hotrba.paper.pdf I think this paper is from HotNets 1, 2002: "From Protocol Stack to Protocol Heap - Role-Based Architecture." Robert Braden, Ted Faber, and Mark Handley I mentioned that an application could do this already, if it was written appropriately and was communicating with nodes using either the same application, or applications which used the same arrangement. I was not advocating this as a solution to the routing scaling problem. I support adding a CES architecture to the existing system so nodes can continue to refer to each other by IP addresses, as both Identifier and Locator, with the modified routing system doing extra work to provide portability, multihoming, inbound TE and mobility on a highly scalable basis. > And still the > identification of a node's points of attachment to links is its own > matter, and we don't need it in the inter-node path selection > system. I agree that with Loc/ID Separation, the routing system can remain as it is, and doesn't need to know anything about nodes as such. However, the extra work then needs to be done by all nodes - which I am opposed to, especially considering the burden this places on hand-held wireless connected mobile devices. Or wrist-worn or lapel-worn devices such as the new Nano, or its descendent organisms "Pico" (ear-worn), "Femto" (brain implant) etc. as soon as one of these sprouts a radio interface! > When a node communicates to its neighbor it just needs the data > sent to and received by the neighbor. If the node minds the links > to its neighbor, it shall take care fore that itself; it may > arrange special link usage with the neighbor. OK - as I noted, this can be done today, if the application is written to do so. With Loc/ID Separation, all nodes are upgraded to arbitrarily handle the potentially multiple Locators of every node they send packets to. Each node, in its sending capacity, is therefore responsible for choosing which Locator to send the packets to - which involves a lot of work. For instance, if BBB gets a packet with the source Identifier AAA and some Locators 333, 444 and 555, it can't accept that these are AAA's true Locators. If it cares at all about which node will get the packet it sends ostensibly to AAA, then BBB needs to do a lookup of AAA's Identifier to securely and reliably retrieve the current Locators for AAA. This involves delays and extra packets. > When a node > communicates to a distant node (more than a hop away) it still just > needs the data sent to and received by the distant node. The > sending node generally doesn't need to mind the links of the > corresponding node; it's the business of the correspondent and its > neighboring gateways. So, the address/locator a node needs to put > in a packet to another node just has to be of that entire node. I don't understand this clearly enough to respond. Are you discussing the current arrangements, or Loc/ID Separation? ILNP, Name Based Sockets - and I think, RANGI and GLI-Split - have the Identifier referring to the node itself, meaning that packets can be received by that node, or sent by that node, from any of the node's interfaces. The Locator typically or in these architectures specifies the particular interface of the node. - Robin _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
