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]
