Internet DRAFT - draft-armitage-ipatm-tn

draft-armitage-ipatm-tn



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
                    <draft-armitage-ipatm-tn-00.txt>


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]