HTTP/1.1 200 OK Date: Mon, 08 Apr 2002 22:35:52 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Tue, 04 Jun 1996 16:44:12 GMT ETag: "304aca-6299-31b467dc" Accept-Ranges: bytes Content-Length: 25241 Connection: close Content-Type: text/plain Internet-Draft Grenville Armitage Bellcore April 26th, 1996 Transient Neighbors for IPv6 over ATM Status of this Memo This document was submitted to the IETF IP over ATM WG. Publication of this document does not imply acceptance by the IP over ATM WG of any ideas expressed within. Comments should be submitted to the ip- atm@nexen.com mailing list. Distribution of this memo is unlimited. This memo is an internet draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". To learn the current status of any Internet-Draft, please check the "lid-abstracts.txt" listing contained in the Internet-Drafts shadow directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract This document is a revision of a model for IPv6 over ATM that was presented to a joint session of the IPATM, IPNG, and ROLC working groups in March 1996. The model attempts to allow conventional host-side operation of the Neighbor Discovery protocol, while also supporting the establishment of 'cut through' ATM routes. This is achieved through the use of Redirects to create Transient Neighbors, IPv6 protocol operation within the IPv6 Logical Link Group, and partial NHRP for location of off-Link destinations. The egress router detects flows that are suitable candidates for cut-through, uses NHRP to locate a better link level first hop, and then issues a Redirect message to the source. Armitage Expires October 26th, 1996 [Page 1] Internet Draft draft-armitage-ipatm-tn-00.txt April 26th, 1996 1. Introduction. The IPv4 world evolved an approach to address resolution that focussed on 'link layer' level protocol operation. ATMARP [3], and more currently NHRP [8], are the consequences of this model when applied to the IP over ATM world. IPv6 developers opted to migrate away from a link layer specific approach, chosing to combine a number of tasks into a protocol known as Neighbor Discovery [7], intended to be non-specific across a number of link layer technologies. A key assumption made by Neighbor Discovery's actual protocol is that the link technology underlying a given IP interface is capable of native multicasting. This is not immediately true of ATM interfaces, a fact that is generating a number of attempts to bypass or modify some of ND's assumptions. It has also not been clear to the IP/ATM community how Neigbor Discovery can be applied to services such as locating 'cut through' routes (where IP routing boundaries are 'cut through' if they are found to be merely logical boundaries between nodes attached to the same physical link network). A general overview of the issues facing IPv6 over ATM is provided in [10]. This document looks at a number of evolving models in the IP world, and attempts to synthesize a general solution of IPv6 ND over ATM that supports cut-through routing without requiring large scale multicasting of ND messages around an ATM network. The salient models are: - The IPv6 Neighbour model, refined as in [10], where neigbors are discovered through the use of messages multicasted to members of an IP interface's local Logical Link Group. - The MARS model, allowing emulation of general multicast using multicast servers and point to multipoint calls provided by the underlying link network. - The NHRP service for seeking out the link layer identities of IP interfaces who are logically distant in an IP topological sense. - The modelling of IP traffic as 'flows', and using the existence of a flow as the basis for attempting to set up a cut-through link level connection. In summary, this document proposes that: IPv6 over ATM interfaces utilize a MARS derived multicast server mechanism to distribute discovery messages around their Logical Link Group [10]. For destinations not currently considered to be Neighbors Armitage Expires October 26th, 1996 [Page 2] Internet Draft draft-armitage-ipatm-tn-00.txt April 26th, 1996 (initially this will include just about any destination not in the Logical Link Group), a host sends the packets to its default router. The egress router from a Logical Link Group is responsible for detecting the existence of an IP packet flow through it that might benefit from a cut-through connection. While continuing to conventionally forward the flow's packets, the router initiates an NHRP query for the flow's destination IP address. The last router/NHS before the target of the NHRP query ascertains the target interface's preferred ATM address. The originally querying router then issues a Redirect to the IP source, identifying the flow's destination as a transient Neighbor. A number of key advantages are claimed for this approach. These are: The IPv6 stacks on hosts do not implement seperate ND protocols for each link layer technology. When the destination of a flow is solicited as a transient neighbor, the returned ATM address will be the one it chose when the flow was originally established through hop-by-hop processing (for destination interface load sharing). 2. Logical Link Groups, and Transient Neighbors. (To review the model of 'link' used in this document, the following text is borrowed straight from section 5 of [10].) IPv6 contains a concept of on-link and off-link. Neighbors are those nodes that are considered on-link and whose link-layer addresses may therefore be located using Neighbor Discovery. Borrowing from the terminology definitions in the ND text: on-link - an address that is assigned to a neighbor's interface on a shared link. A host considers an address to be on-link if: - it is covered by one of the link's prefixes, or - a neighboring router specifies the address as the target of a Redirect message, or - a Neighbor Advertisement message is received for the target address, or Armitage Expires October 26th, 1996 [Page 3] Internet Draft draft-armitage-ipatm-tn-00.txt April 26th, 1996 - a Router Advertisement message is received from the address. off-link - the opposite of "on-link"; an address that is not assigned to any interfaces attached to a shared link. Off-link nodes are considered to only be accessible through one of the routers directly attached to the link. The preceding descriptions may need refinement in the context of Logical Link Groups (or equivalent concept). The LLG is the same set of hosts that make up a given MARS Cluster - an administratively defined group. These are an IPv6 interface's initial set of neighbors, and each interface's Link-Local address only needs to be unique amongst this set. Events such as the receipt of ND advertisement messages, or the operation of some alternative discovery protocol, may result in the expansion of an IPv6 interface's set of Neighbors. However, this should not be considered to have changed the set of interfaces that make up its LLG. This leads to three possible relationships between any two IPv6 interfaces: - On LLG, Neighbor. - Off LLG, Neighbor. - Off LLG, not Neigbor. Off LLG Neighors are the 'cut through' connections, where some dynamic protocol activity has ascertained that although a target IPv6 interface is not a member of the source's LLG, it is possible to achieve link level connectivity. Neigbors 'discovered' through the operation of unsolicited messages, such as Redirects, may be termed 'Transient Neighbors'. 3. Intra-LLG and Inter-LLG Discovery. This document makes a distinction between the discovery of neigbors within a Logical Link Group (intra-LLG) and neigbors beyond the LLG (inter-LLG). The goal is to allow both inter- and intra-LLG neighbor discovery to involve no changes to the host-side IPv6 stack for ATM. 3.1 Intra-LLG - ND over emulated multicast. The basic model of ND assumes that a link layer interface will do something meaningful with an ICMPv6 packet sent to a multicast IP Armitage Expires October 26th, 1996 [Page 4] Internet Draft draft-armitage-ipatm-tn-00.txt April 26th, 1996 destination address. As noted in [10], IPv6 assumes that multicasting is an integral part of the Internet service. Section 2.1 of [10] shows how this can be provided using the MARS [5] service currently being developed for IPv4 multicast over ATM. The goal of intra-LLG operation is that the IPv6 layer must be able to simply pass multicast ICMPv6 packets down to the IPv6/ATM driver without any special, ATM specific processing. The underlying mechanism for distributing Neighbor Discovery and Router Discovery messages then works as expected. The rest of this section explores the tradeoffs of various mechanisms below the IP layer for distributing ND and RD messages. 3.1.1 Simplistic approach - MARS as 'black box'. The IPv6/ATM driver utilizes the standard MARS protocol to establish a VC forwarding path out of the interface on which it can transmit the ICMPv6 packet. The ICMPv6 packet is then transmitted, and is received by the intended destination set. With such an approach all the protocol elements in [5] should work 'as is'. However, VC resource consumption must be taken into consideration. Unfortunately, the issues that affect VC resource consumption when supporting ND are not amenable to simply shifting from VC mesh to Multicast Server modes of emulating multicast. 3.1.2 MARS as a Link (Multicast) Server. ND assumes that link level multicast resources are best conserved by generating a sparsely distributed set of Solicited Node multicast addresses (to which discovery queries are initially sent). The original goal was to minimize the number of innocent nodes that simultaneously received disovery messages really intended for someone else. However, in an ATM environment it becomes equally (or more) important to minimize the number of independent VCs that a given ATM interface is required to originate or terminate. If we treat a MARS solution as a 'black box' the sparse Solicited Node address space can lead to a large number of short-use, but longer lived, pt-mpt VCs (generated whenever the node is transmitting Neighbor Solicitations). Even more annoying, these VCs are likely to be useful _only_ for additional packets being sent to the Solicited Node multicast address that caused the VC to be created in the first place. This means a new pt- pt VC is established to actually carry the unicast IPv6 traffic that prompted the Neighbor Solicitation. Armitage Expires October 26th, 1996 [Page 5] Internet Draft draft-armitage-ipatm-tn-00.txt April 26th, 1996 The axis of inefficiency brought about by the sparse Solicited Nodes address space is orthogonal to the VC mesh vs Multicast Server tradeoff. Typically a multicast server aggregates traffic flow to a common multicast group onto a single VC. To reduce the VC consumption for ND, we need to aggregate across the Solicited Node address space - performing aggregation on the basis of a packet's function rather than its explicit IPv6 destination. The trade-off here is that the aggregation removes the original value of scattering nodes sparsely across the Solicited Nodes space. This is a price of the mismatch between ND and connection oriented networks. One possible mechanism for aggregation is for every node's IPv6/ATM driver to trap multicast ICMPv6 packets carrying multicast ND or RD messages, and remap their destinations to the All Nodes group (link local scope). By ensuring that the All Nodes group is supported by an MCS, the resultant VC load within the LLG will be significantly reduced. A further optimization is for every node's IPv6/ATM driver to trap multicast ICMPv6 packets carrying multicast ND or RD messages, and send them to the MARS itself for retransmission on ClusterControlVC (involving a trivial extension to the MARS itself.) This approach recognizes that in any LLG where IPv6 multicasting is supported: - Nodes already have a pt-pt VC to their MARS. - The MARS has a pt-mpt VC (ClusterControlVC) out to all Cluster members (LLG members registered for multicast support). Because the VCs between MARS and MARS clients carry LLC/SNAP encapsulated packets we can multiplex ICMP packets in addition to its original MARS control messages. In essence the MARS behaves as a multicast server for non-MARS control message packets that it receives from around the LLG. (Indeed, if we used this approach of 'MARS as MCS' to support the All Nodes multicast group, then the preceding two ideas boil down to the same thing.) As there is no requirement that a MARS client only accepts MARS messages on ClusterControlVC, ICMP messages received in this fashion may be passed to every node's IP layer without further comment. Within the IP layer filtering will occur based on the packet's actual destination IP address, and only the targetted node will end up responding. Armitage Expires October 26th, 1996 [Page 6] Internet Draft draft-armitage-ipatm-tn-00.txt April 26th, 1996 3.2 Inter-LLG - Redirects, and their generation. The key to creating transient neighbors is the Redirect message (section 8 [7]). IPv6 allows a router to inform the members of an LLG that there is a better 'first hop' to a given destination (section 8.2 [7]). The advertisement itself is achieved through a Router Redirect message, which may carry the link layer address of this better hop. A transmitting host only listens to Router Redirects from the router that is currently acting as the default router for the IP destination that the Redirect refers to. If a Redirect arrives that indicates a better first hop for a given destination, and supplies a link layer (ATM) address to use as the better first hop, the associated Neighbor Cache entry in the source host is updated and its reachability set to STALE. Updating the cache in this context involves building a new VC to the new ATM address. If this is successful, the old VC is torn down only if it no longer required (as this VC was to the router, it may still be required by other packets from the host that are leaving the LLG). The manner by which a router determines a better first-hop is not specified or constrained in [7]. The model in this document suggests a mechanism. 3.2.1 Redirect Triggers. Technology to support cut through connections is justified on the grounds that demanding flows of IP packets may exist between source/destination pairs that are separated by IP routing boundaries. NHRP [8] is built on the premise that the source itself decides to seek a cut through connection. The Cell Switch Router [11] and the IP Switch [12] models place the detection and management of IP packet flows into the routers (where flows cross the edges of IP routing boundaries). This document suggests that router-based flow identification mechanisms can be used to trigger the eventual generation of an IPv6 Router Redirect. The actual algorithm(s) for determining when a flow should trigger an attempt to resolve a better first hop are not defined in this document yet. A router SHALL only track flows that originate from a directly attached host (a host that is within the LLG-local scope of one of the router's interfaces). IP packets arriving from another router are never used to trigger the generation of a Router Redirect. Armitage Expires October 26th, 1996 [Page 7] Internet Draft draft-armitage-ipatm-tn-00.txt April 26th, 1996 3.2.2 Partial NHRP between routers. Once flow detection has occurred, a router needs some mechanism for establishing the IP to link level address mapping of a better first hop. An obvious approach is for routers to incorporate part of the Next Hop Server (NHS) function that is proposed for them in NHRP. The routers must be able to: - Construct NHRP Requests and Replies. - Parse incoming NHRP Requests and Replies. - Forward NHRP Requests towards an NHS that is topologically closer to the IP target. - Forward NHRP Replies towards an NHS that is topologically closer to the requestor. The destination of the flow that caused the trigger is used as the target for resolution in a NHRP Request. The router then forwards this NHRP Request to the next closest NHS. The process continues (as it would for normal NHRP) until the Request reaches an NHS that believes the IP target is within link-local scope of one of its interfaces. (This may potentially occur within a single router.) To understand the next step it is important to remember that the NHRP Request originates _after_ normal hop-by-hop routing has resulted in IP connectivity between the source and destination. That means the last hop router already has a VC open to the final destination (established by the conventional use of Neighbor Discovery on the destination's LLG). As a consequence the NHRP Request may be satisfied using mapping information contained in the router's own neighbor cache. (This assumes that Neigbor Unreachability Detection at the router considers the final destination currently reachable. If not, the final router verifies the reachability of the destination, and builds a NHRP Reply with the validated mapping.) The NHRP Reply is propagated back to the source of the NHRP Request, using a hop-by-hop path as it would for normal NHRP. When it reaches the originating router, the resolved address mapping is used to construct a Router Redirect message. The Router Redirect is then unicast to the IP packet flow's source (using the VC on which the flow is arriving at the router, if it's a pt-pt VC). It is worth noting that the router constructing the NHRP Reply does so using the ATM address returned by the target host when the target host first accepted the flow of IP traffic. This retains a useful feature of ND - destination interface load sharing. Armitage Expires October 26th, 1996 [Page 8] Internet Draft draft-armitage-ipatm-tn-00.txt April 26th, 1996 (The use of NHRP between the routers is not meant to be normative. Any protocol that the routers understood, and was capable of carrying IP to link layer mappings, would suffice. Howver, current efforts to deploy NHRP in routers means it is the most likely technology on which to build the inter-LLG mechanism.) 3.3. Neigbor Unreachability Detection. Neighbor Solicitations sent for the purposes of Neigbor Unreachability Detection (NUD) are unicast to the Neighbor in question, using the VC that is already open to that Neighbor. This suggests that as far as NUD is concerned, the Transient Neighbor is indistinguishable from an On-LLG Neighbor. 3.4. Duplicate Address Detection. Duplicate Address Detection is only required within the link-local scope, which in this case is the LLG-local scope. Transient Neighbors are outside the scope of the LLG. No particular interaction is required between the mechanism for establishing cut throughs and the mechanism for detection of duplicate link local addresses. 4. Conclusion and Open Issues. This document provides a moderately high-level view of an approach to IPv6 over ATM. The proposed solution requires no ATM-specific changes to the Neighbor Discovery and Router Discovery protocols within hosts. Indeed, no special protocol is required at all in the hosts to support the use of cut through routes. Some tweaks to the MARS model are suggested to minimize the VC resource cost associated with distributing Disocvery messages around a Logical Link Group. It is suggested that we explore the model of router-identified IP flows for triggering cut through connections. It is noted that the IPv6 Router Redirect message is designed with the precise intention of supporting the advertisement of new Neighbors in NBMA environments - and proposes to use the Redirect message in exactly that role. Finally, parts of the NHRP architecture are used to support the discovery of cut through routes to Transient Neighbors. There are a number of open issues, both in general and specific senses: - Need to explore the styles of flow characterization that could meaningfully lead to the triggering of a Redirect message. - Need to clarify further the conditions under which sources may ignore a Redirect. Armitage Expires October 26th, 1996 [Page 9] Internet Draft draft-armitage-ipatm-tn-00.txt April 26th, 1996 - Need to specify more clearly how a cut through route may be invalidated or purged. - More detailed text is required for Router Redirect packets, NHRP Request/Reply packets, and the sharing of MARS ClusterControlVC by MARS control messages and Discovery related ICMPv6 packets. As with all open issues, contributions to the mailing list are solicited. Security Consideration Security considerations are not addressed in this memo. Acknowledgments Eric Nordmark confirmed the usefulness of ND Redirect messages in private email during the March 1996 IETF. Goofs are all mine. Author's address Grenville Armitage Internetworking Research Group, Bellcore. 445 South Street Morristown, NJ, 07960-6438 USA Email: gja@bellcore.com References. [1] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC-1883, December 1995. [2] ATM Forum, "ATM User Network Interface (UNI) Specification Version 3.1", ISBN 0-13-393828-X, Prentice Hall, Englewood Cliffs, NJ, June 1995. [3] M. Crawford, A Method for the Tranmission of IPv6 Packets over Ethernet Networks , INTERNET DRAFT, draft-ietf-ipngwg-ethernet- ntwrks-02.txt, March 1996. [4] J. Heinanen, "Multiprotocol Encapsulation over ATM Adaption Layer 5", RFC 1483, USC/Information Science Institute, July 1993. Armitage Expires October 26th, 1996 [Page 10] Internet Draft draft-armitage-ipatm-tn-00.txt April 26th, 1996 [5] G.J. Armitage, "Support for Multicast over UNI 3.1 based ATM Networks", INTERNET DRAFT, draft-ietf-ipatm-ipmc-12.txt, IP-over-ATM WG, February 1996. [6] S. Deering, R. Hinden, "IP Version 6 Addressing Architecture", RFC-1884, December 1995. [7] T. Narten, E. Nordmark, W.A. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", INTERNET DRAFT, draft-ietf-ipngwg-discovery- 06.txt, March 1996. [8] J. Luciani, et al, "NBMA Next Hop Resolution Protocol (NHRP)", INTERNET DRAFT, draft-ietf-rolc-nhrp-07.txt, December 1996. [9] S. Thomson, T. Nartin, "IPv6 Stateless Address Autoconfiguration", INTERNET DRAFT, INTERNET DRAFT, draft-ietf- addrconf-ipv6-auto-07.txt, December 1995. [10] G.J. Armitage, "IPv6 and Neighbor Discovery over ATM", INTERNET-DRAFT, draft-ietf-ipatm-ipv6nd-00.txt, IP-ATM WG, April 1996. [11] Yasuhiro Katsube, Ken-ichi Nagami, Hiroshi Esaki, "Router Architecture Extensions for ATM : Overview", INTERNET-DRAFT, draft- katsube-router-atm-overview-02.txt, March 1996. [12] Ipsilon, "IP Switch Technology", http://www.ipsilon.com/ips.html Armitage Expires October 26th, 1996 [Page 11]