The IP Over NBMA (ION) Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] (LONG!!!) draft-ietf-ion-ipv6atm-framework-00.txt
This is the full text of draft-ietf-ion-ipv6atm-framework-00.txt which
will be presented in the Tuesday ION session at the Montreal IETF meeting.
I apologize for sending such a huge mail to the list. We sent this draft
last week to the I-D editor before the deadline. But it either didn't make
it in time for some reason or got lost. So as a last resort, I've sent it
to the list.
Markus
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
INTERNET-DRAFT Peter Schulter
Markus Jork
Geraldine Harter
Digital Equipment Corp.
June 13, 1996
A Framework for IPv6 Over ATM
<draft-ietf-ion-ipv6atm-framework-00.txt>
Status of this Memo
This document 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 and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to site them other than as ``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 ftp.is.co.za (Africa), nic.nordu.net
(Europe), munnari.os.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast).
This Internet Draft Expires December 15, 1996.
Abstract
Work in specifying the IPv6 [IPv6-SPEC] has now progressed to a
point that the base set of IPv6 specs are on a standards track and
work on IPv6 implementations is beginning at many organizations.
So far, the IPv6 specifications have dealt with broadcast media
LANs [IPv6-ETHER]with very little attention to ATM. The IP over
ATM WG is now starting to look at IPv6 over ATM [IPV6-ND]. Many of
the problems encountered in running IPv4 over ATM [IP-FRAME, IP-
ATM, IP-ATMU, IP-ATMMC, NHRP] must also be dealt with when running
IPv6 over ATM. Since ATM networks are point-to-point networks that
offer no connectionless broadcast or multicast capabilities, many
of the IPv6 protocols can't be directly applied to the ATM
datalink. Instead, some software framework built on top of the ATM
datalink is needed to handle those protocols or functions which
rely on connectionless multicast capabilities. Among these
functions are Neighbor Discovery, Router Discovery, and address
configuration.
This document describes a framework for adapting IPv6 and its base
protocols [IPv6-SPEC, IPV6-ND, IPV6-ADDRCONF, IPV6-ADDRARCH, IPV6-
DHCP] to ATM networks while maintaining the complete functionality
and semantics of these protocols. This is done by defining an IPv6
``link'' for ATM networks in a way which preserves all the
draft-ietf-ion-ipv6atm-framework-00.txt [page 1]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
fundamental IPv6 concepts and functionality while still taking
advantage of the unique capabilities of ATM.
draft-ietf-ion-ipv6atm-framework-00.txt [page 2]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
Status of this Memo ......................................1
Abstract .................................................1
1. Introduction and Background ............................5
1.1. Requirements ........................................6
2. Definitions of Terms ...................................7
2.1. IPv6 Terminology ....................................7
2.2. ATM Terminology .....................................8
2.3. New Terminology .....................................9
2.4. Addresses ..........................................10
3. IPv6 Over ATM Framework Description ...................10
3.1. IPv6 over ATM Link Requirements ....................10
3.2. IPv6 over ATM Logical Links ........................11
3.3. Logical Link Servers ...............................13
4. VC Characteristics and Message Formats ................16
4.1. Message Encapsulation ..............................16
4.1.1. IPv6 Unicast Packet Encapsulation Format .......16
4.1.2. IPv6 Multicast Packet Encapsulation Format .....17
4.1.3. LLS Control Message Encapsulation Format .......17
4.2. ATM Address Format .................................17
4.3. ATM IPv6 Interface Token Format ....................18
4.3.1. Generating Interface-tokens from NIC MACs ......19
4.3.2. Generating Interface-Tokens from NSAPAs ........19
4.3.3. Generating Interface-Tokens from E.164 Addresses19
4.3.4. Generating Interface-tokens Algorithmically ....19
4.4. LLS VC Characteristics .............................19
4.5. Data VC Characteristics ............................20
5. Logical Link Control Messages .........................20
5.1. Logical Link Control Message Formats ...............21
5.1.1. The IPv6 Multicast Address Option Format .......21
5.1.2. The ATM Address Option Format ..................22
5.1.3. The IPv6 multicast Address Range Option Format .22
5.1.4. The Sequence Identifier Option Format ..........23
5.1.5. The Sequence Index Option Format ...............23
5.1.6. The LL Entity Identifier Option Format .........24
5.1.7. The Authentication Option Format ...............24
5.2. The Authentication and Identification Message .....24
5.3. The Acknowledgment Message .........................25
5.4. The Negative Acknowledgment Message ................26
5.5. The Link Configuration Advertisement Message .......26
5.6. The Link Configuration Query Message ...............28
5.7. The Multicast Group Join Message ...................28
5.8. The Multicast Group Leave Message ..................29
6. Security ..............................................30
7. Conceptual Model and Configuration ....................31
7.1. Conceptual Model ...................................31
7.1.1. LLS Model ......................................31
7.1.2. Node Model .....................................32
7.2. Manual Configuration ...............................34
7.3. Autoconfiguration ..................................35
8. Common LLS and Node Operations .......................35
8.1. Common Logical Link Connection Processing ..........35
8.2. Common Recovery from Logical Link Connection Failures37
8.2.1. Reconnecting Using Highest Priority Peer-set ..37
draft-ietf-ion-ipv6atm-framework-00.txt [page 3]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
8.2.2. Handling VC Releases and Errors ................38
8.3. Common Configuration Advertisement Message
Processing ..............................................39
9. Logical Link Server Operation .........................40
9.1. LLS Operation ......................................41
9.1.1. Connecting to Higher Level LLS .................41
9.1.2. Receiving Connections from Lower Level Entities 42
9.1.3. Disseminating LLS Configuration Advertisements .43
9.1.4. Receiving Multicast Group Joins ................45
9.1.5. Receiving Multicast Group Leaves ...............47
9.1.6. Receiving Promiscuous Joins ....................49
9.1.7. Receiving Promiscuous Leaves ...................50
9.1.8. Receiving Packets From a Lower Entity ..........51
9.1.9. Receiving Packets from a Higher LLS ............52
9.2. LLS(Root) Operations ...............................52
10. Node Operation .......................................52
10.1.Connecting to A LLS ................................52
10.2. Handling LLS Configuration Advertisements ........54
10.3. Joining a Multicast Group .........................54
10.3.1. Joining in Promiscuous Mode ...................54
10.4. Leaving a Multicast Group .........................55
10.4.1. Leaving Promiscuous Mode ......................56
10.5. Sending Data ......................................56
10.5.1. Sending Logical Link Control Data .............56
10.5.2. Sending Unicast Data ..........................57
10.5.3. Sending Multicast Data ........................57
10.6. Receiving Data ....................................57
10.6.1. Receiving Logical Link Control Data ...........58
10.6.2. Receiving Unicast Data ........................58
10.6.3. Receiving Multicast Data ......................58
10.7. Unicast Data VC Setup and Release ................58
10.8. Node Failover and Interface Transition Operations .59
Appendix A. IPv6 Protocol Operation .....................59
A.1 Neighbor Discovery ..................................59
A.1.1 Performing Address Resolution ...................59
A.1.2 Performing Router Discovery .....................61
A.1.3 Performing Neighbor Unreachability Detection (NUD)63
A.1.4 Performing Duplicate Address Detection (DAD) ....64
A.1.5 Processing Redirects ............................65
A.2 Address Configuration ...............................66
A.2.1 Stateless Address Configuration .................66
A.2.2 Stateful Address Configuration (DHCP) ..........67
A.2.3 Manual Address Configuration ....................68
A.3 Internet Group Management Protocol (IGMP) ...........68
Acknowledgments ..........................................70
Authors' Addresses .......................................70
References ...............................................70
draft-ietf-ion-ipv6atm-framework-00.txt [page 4]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
1. Introduction and Background
The basic problem in adapting IPv6 to ATM networks is that IPv6
relies very heavily on connectionless multicast capabilities (IPv6-
SPEC, IPV6-ND, IPV6-ADDRCONF). However, ATM networks do not
provide a connectionless multicast link services at the datalink,
and therefore, ATM does not inherently provide a framework for the
various IPv6 discovery, address configuration, and routing
protocols. Thus, some mechanism to provide a multicast service for
use by IPv6 must be provided if all the IPv6 discovery protocols
are to be preserved on ATM networks.
Additionally, IPv6 differs from IPv4 in that address resolution and
address configuration are located in the network layer rather than
the datalink layer. That is, the Neighbor Discovery protocols
which IPv6 uses to perform neighbor and router discovery are an
integral part of the IPv6 network layer (ICMPv6), and any mechanism
that is used to adapt ATM to IPv6 must deal with the Neighbor
Discovery protocols. This is in contrast to IPv4 where the address
resolution protocols are not part of the base IP protocols but are
part of each individual datalink layer (i.e., ARP for broadcast
media, ATMARP or NHRP for ATM). In IPv4 new datalink layers could
define their own address resolution protocols as necessary (as was
done with ATMARP) since this function is left to the datalink.
Thus, new datalinks could be added without affecting the IPv4
network layer. In IPv6 all datalinks must handle IPv6 Neighbor
Discovery packets and use them for address resolution, router
discovery and address configuration. Not using Neighbor Discovery
would require modifying the IPv6 network layer to accommodate a
specific datalink.
Further, IPv6 provides for some extra features not in IPv4. One of
these features is address autoconfiguration. Any mechanism used
to adapt IPv6 to ATM must provide for address autconfiguration
since this is expected to be the primary way in which nodes will
configure their network layer addresses. Another IPv6 feature is
security. IPv6 has been defined with network layer security
features as part of the base protocol. These security features are
applied to the discovery and configuration protocols since these
protocols are defined at the network layer. Any IPv6 over ATM
solution must also take IPv6 security into consideration and
preserve the security features built in IPv6. Finally, IPv6
includes an address architecture [IPV6-ADDRARCH] which provides for
address scoping for both unicast and multicast addresses. This
addressing architecture must also be maintained for IPv6 over ATM.
One concept which is central to IPv6 is the concept of the ``link''
An IPv6 link is a collection of nodes with a common set of prefixes
and which can directly communicate over the datalink. The ``link''
provides connectionless multicast packet delivery between members
of the link. Further, a ``link'' defines the scope of neighbor
discovery, router discovery, address configuration, host-token
draft-ietf-ion-ipv6atm-framework-00.txt [page 5]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
uniqueness, and link-local addresses. To adapt the base IPv6
protocols to ATM the first thing that must be done is to define
what an IPv6 ``link'' is on an ATM network. That is, how a set of
ATM nodes is partitioned into an autonomous group which share
common address prefixes, and between which the Neighbor Discovery
protocols can be used. Such a `link'' should be defined so that
all the base IPv6 protocols (including ND) can be run over it with
no modifications to endsystems or routers, and so that the
administration of the network layer software is the same as that on
other media. Thus, the ATM ``link'' should provide the same
semantics as other links so that all the IPv6 protocols can be used
without requiring any special modification specifically for ATM.
Once an IPv6 `link'' is defined for ATM networks, mechanisms and
policies for running IPv6 protocols over the link must be defined.
These mechanisms should meet the following goals:
. the concept of the IPv6 subnetwork/link must be maintained
. the scope of link-local unicast and multicast addresses must be
maintained
. all functionality provided by the current IPv6 Neighbor
Discovery protocols must be provided
. there must be no modifications required to the IPv6 network
layer in order to run IPv6 over ATM
. the Neighbor Discovery protocol semantics must be maintained
. the resulting protocols and architecture must scale to
arbitrarily large networks
. nodes must be permitted to join multiple subnets/links
. nodes must be permitted to join any subnet/link on the wider
ATM network without regard to the node's geographic location
. the link must provide for redundancy and failover of critical
resources
1.1. Requirements
Throughout this document, the words that are used to define the
significance of the particular requirements are capitalized. These
words are:
. MUST ---This word or the adjective ``REQUIRED'' means that the
item is an absolute requirement of this specification.
. MUST NOT --- This phrase means the item is an absolute
prohibition of this specification.
. SHOULD ---This word or the adjective ``RECOMMENDED'' means that
there may exist valid reasons in particular circumstances to
ignore this item, but the full implications should be
understood and the case carefully weighed before choosing a
different course.
. SHOULD NOT ---This phrase means that there may exist valid
reasons in particular circumstances when the listed behavior is
acceptable or even useful, but the full implications should be
understood and the case carefully weighed before implementing
any behavior described with this label.
draft-ietf-ion-ipv6atm-framework-00.txt [page 6]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
. MAY ---This word or the adjective ``OPTIONAL''means that the
item is truly optional. One vendor may choose to include the
item because a particular marketplace requires it or because it
enhances the product, for example, an other vendor may omit the
same item.
2. Definitions of Terms
Relevant terminology from the IPv6 Protocol [IPV6-SPEC], IPv6
Addressing Architecture [IPV6-ADDR], IPv6 Stateless Address
Autoconfiguration [IPV6-ADDCONF], IPv6 Neighbor Discovery [IPV6-
ND], then Classical IP and ARP over ATM [IP-ATM], UNI 3.0 [ATM-
UNI30], UNI 3.1 [ATM-UNI31], UNI 4.0 [ATM-UNI40], and PNNI [ATM-
PNNI] will be provided, and finally new terminology introduced by
this document will be given.
2.1. IPv6 Terminology
. IPv6 ---Internet Protocol Version 6.
. IPv4 ---Internet Protocol Version 4.
. Node ---a device that implements IPv6. In this document all
nodes implement IPv6 over ATM. Node are always connected to an
ATM network and may be connected to any number of other
networks.
. Router ---A node that forwards IP packets not explicitly
addressed to itself.
. Host ---Any node that is not a router
. link ---A communications facility or medium over which nodes
can communicate at the link layer, i.e., the layer immediately
below IPv6. Examples are Ethernet (simple or bridged), ATM
networks, PPP links, X.25, Frame Relay, and FDDI; and internet
(or higher) layer ``tunnels'', such as tunnels over IPv6 or IPv6
itself.
. Neighbors ---Nodes attached to the same link.
. Interface ---A node's attachment to a link
. address --An IP layer identifier for an interface or a set of
interfaces
. packet ---An IP header plus a payload.
. Communication --- Any packet exchange between nodes that
requires that the address of each node used in the exchange
remain the same for the duration of the exchange. Examples are
a TCP connection or UDP request/response.
. Unicast-address ---An identifier for a single interface. A
packet sent to a unicast address is delivered to the interface
identified by that address.
. Multicast-address ---an identifier for a set of interfaces
(typically belonging to different nodes). A packet sent to a
multicast address is delivered to all interfaces identified by
that address.
. Link-layer address ---a link-layer identifier for an interface.
Examples are an IEEE 802 address for Ethernet links, and ATM
draft-ietf-ion-ipv6atm-framework-00.txt [page 7]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
NSAP or E.164 addresses (with optional subaddresses) for ATM
networks.
. link-local address ---An address having link-only scope that
can be used to reach neighboring nodes attached to the same
link. All interfaces have a link-local address.
. Site-local address ---An address having scope that is limited
to the local site
. global address ---an address with unlimited scope
. interface token ---A link dependent identifier for an interface
this is (at least) unique per link.
. Anycast address ---an identifier for a set of interfaces
(typically belonging to different nodes). A packet sent to an
anycast address is delivered to one of the interfaces
identified by that address (the ``nearest'' one, according to
the routing protocols measurement of distance).
. On-link ---An address that is assigned to an interface on a
specified link. A node considers an address to be on-link if:
. it is covered by one of the link's prefixes
. a neighboring router specifies the address as the target of a
Redirect message
. a Neighbor Advertisement message is received for the (target)
address
. a Neighbor Discovery message is received from the address
. off-link ---the opposite of ``on-link''; and address that is
not assigned to any interfaces on the specified link.
2.2. ATM Terminology
. Point-to-Point (PtP) ---An ATM connection (virtual circuit)
connecting exactly two ATM nodes. The same set of nodes can
have multiple PtP connections to each other.
. Point-to-Multipoint (PtM) ---An ATM connection that connects
one node to many nodes. PtM connections are unidirectional
with data flowing from the ``root''node to many `leaf'' nodes.
PtM connections are created by placing a special call to each
node to be included in the PtM connection. The same set of
nodes can have multiple PtM connections to each other.
. Call ---The process of establishing a connection (virtual
circuit) between two nodes (parties). One node actively
initiates connection establishment (calling party) and the
other node passively receives the call (called party). Circuit
traffic parameters are established and negotiated during the
call.
. Release ---The process of terminating a single connection
between two more nodes. A node is always notified if a
connection is released for any reason.
. Group Address ---This type of address is specific to UNI 4.0
(UNI 3.0/3.1 does not support group addressing). An address
which identifies a set of ATM nodes. Calls to a group address
are routed by the ATM network to exactly one of the nodes
identified by the address. Group addresses are assigned a
specific scope when they are registered with the network. This
scope defines which nodes within the ATM network routing
hierarchy are able to reach the specific nodes identified by
draft-ietf-ion-ipv6atm-framework-00.txt [page 8]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
the group address. Group addresses are also referred to as
anycast addresses in the UNI 4.0 specification, but the term
group address is used in this document to avoid confusion with
IPv6 anycast addresses.
. Address registration ---The process by which an ATM node
informs the ATM network of its link-layer addresses. ATM nodes
can register multiple addresses and the addresses can take
several forms. A node must register an address to be able to
establish connections to other nodes.
. UNI ---User-Network Interface. The ATM interface and protocols
between the nodes and the network.
. PNNI ---Private Network-Network Interface. The ATM interface
and protocols between switching elements of an ATM network.
The also defines how an ATM network topology is build and how
calls are routed within that topology.
2.3. New Terminology
. Logical Link (LL) ---a set of ATM nodes which can reach each
other using only link-local addresses and which can broadcast
to all other nodes in the LL. This is analogous to a LAN
segment.
. Logical Link Server (LLS) ---An entity which provides the
services necessary to create an IPv6 link on an ATM network.
. LLS(n) ---This notation denotes a Logical Link Server at a
specific level in the LLS hierarchy.
. LLS(HIGHER) ---Any LLS server at a higher level in the
hierarchy than some LLS(n). That is, for a given LLS(n), any
LLS(n+x) for x>0.
. LLS(LOWER) ---Any LLS server at a lower level in the hierarchy
than some LLS(n). That is, for a given LLS(n), any LLS(n-x)
for x>0.
. NODEVC ---The PtP VC between a node and the LLS.
. MVC(mmcg) ---The PtM VC between a LLS and connected nodes,
originating at the LLS, over which multicast traffic for
specific multicast group addresses are sent. Mmcg is the
mapped multicast group address obtained by passing the
destination multicast address through the function fm(mcg).
The function fm(mcg) maps multicast group addresses to the VC
on which packets for that group are to be sent. Function
fm(mcg) may be used to aggregate multicast addresses. Mcg is
the destination multicast group address.
. WILDMVC(n) ---A PtM VC which carries any multicast packets
which are not sent on a specific MVC(mmcg). This VC is used
only to carry traffic for entities which have performed a
promiscuous multicast join. The VC is rooted in an LLS(n) and
carries traffic from the LLS(n) to lower entities.
. LLSVC(n) ---The PtP VC from LLS(n) to LLS(HIGHER).
. LLSMVC(n) ---The PtM VC connecting LLS(n) to LLS(LOWER),
originating at LLS(n).
. HHVC ---A PtP VC connecting two nodes.
. NODENSAP ---The NSAP over which a node places and receives all
calls for activity on a specific LL. A node has one NODENSAP
draft-ietf-ion-ipv6atm-framework-00.txt [page 9]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
for each LL to which it is connected. This NSAP is the link-
layer address placed in the Neighbor Discovery messages sent
for a specific LL.
. LLSLNSAP(n) ---The ``lower''NSAP for LLS(n). This is the NSAP
over which the LLS receives calls from the LLS(LOWER) servers
or hosts. LLS(n) places calls to LLS(LOWER) servers or hosts
through this NSAP.
. LLSUNSAP(n) ---The ``upper''NSAP for LLS(n). This is the NSAP
over which LLS(n) will place calls to the LLS(HIGHER) server
and receive call from LLS(HIGHER) server.
2.4. Addresses
. all-nodes multicast address ---The link-local scope address to
reach all nodes. FF02::1
. all-routers multicast address ---the link-local scope address
to reach all routers. FF02::2
. Solicited-node multicast address ---a link-local scope address
that is computed as a function of the solicited target's
address. See [IPV6-ND]
. link-local address ---a unicast address having link-only scope
that can be used to reach neighbors. All interfaces MUST have
a link-local address. Routers MUST NOT forward packets with
link-local source addresses. See [IPV6-ADDR]
. unspecified address ---A reserved address value that indicates
the lack of an address (e.g., the address is unknown). It is
never used as a destination address. See [IPV6-ND] and [IPV6-
ADDR].
. DHCP Server/Relay Agent address ---the link local scope address
used to reach all IPv6 DHCP Servers and Relay Agents. FF02::1:0
[IPV6-DHCP].
. tentative address ---an address that has been assigned to an
interface, but which has not yet been verified using duplicate
address discovery. A node can not use a tentative address as
the source address in a packet, or receive packets which
contain the tentative address as the destination, until
duplicate address detection has been performed [see IPV6-
ADDCONF].
3. IPv6 Over ATM Framework Description
3.1. IPv6 over ATM Link Requirements
The requirements of IPv6 over and ATM Logical Link are the same as
those for IPv6 over any other link type. That is, that all
currently defined IPv6 protocols should continue to function
without regard for link type. Thus, an ATM Logical Link must
provide all the multicast services that IPv6 expects. Once these
multicast services are provided then IPv6 protocols should be
usable on ATM LLs with no modifications. Also, it is expected that
draft-ietf-ion-ipv6atm-framework-00.txt [page 10]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
any new protocols will also operate over an ATM LL as long as they
don't use any special feature of a specific datalink.
The requirements for IPv6 over an ATM Logical Link are listed
below. These are the design requirements which were used to
develop the LL mechanism. They may not be generally accepted
requirements for IPv6 over ATM.
. All currently defined IPv6 protocols must run over ATM with no
modification to these protocols specifically for ATM other than
the handling of the larger datalink addresses.
. The semantics of IPv6 unicast and multicast addressing scopes
must not change for ATM.
. IP security mechanisms must operate in the same way on ATM as on
other networks. IP security associations must not change in any
way.
. Nodes must have ultimate authority to reply to neighbor
solicitations to maintain IP security and to permit load
balancing among multiple interfaces.
. Nodes must be able to connect to multiple Logical Links on one or
more ATM networks. These may or may not function as routers
between these Logical Links.
. The Logical Link design must include mechanisms for redundancy
and failover of critical resources.
. The number of VCs used should be scaleable to allow for
implementations across ATM hardware with varying capabilities
(i.e., SAR reassembly queues).
. The specified mechanism must not depend on a host information
database which must be replicated or synchronized between
multiple servers.
Note that none of these requirements addresses the issue of cut-
through between nodes on different LLs. This proposal does not
address a specific cut-through mechanism, but assumes that this is
a function of the routers since IPv6 provides a mechanism
(Redirect messages) which can be used to redirect nodes to off-
link hosts in NBMA networks.
3.2. IPv6 over ATM Logical Links
The IPv6 over ATM framework described here defines what an IPv6
``link''is on an ATM network, and a mechanism by which all IPv6
protocols can be applied to an ATM IPv6 ``link'' In IPv6 terms a
link is a collection of nodes which share common prefixes, can
communicate using link-local addresses, and which can use ND to
resolve link-layer addresses, perform address configuration, and
router discovery. Communication to off-link nodes is accomplished
via routers. The definition of an IPv6 ATM link described here
uses the same model of a link with one important addition which is
necessary for the media. This is, all nodes on the same link are
expected to create one or more VCs over which data is exchanged
(that is, all nodes on a link must directly connect). On an ATM
network, a link has the same semantics as it does on broadcast
draft-ietf-ion-ipv6atm-framework-00.txt [page 11]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
media. Also, just as with broadcast media, the link also defines
the scope of ND messages.
Defining an IPv6 link for ATM requires that some mechanism be
provided to provide for connectionless multicast packet delivery.
IPv6 protocols rely very heavily on the multicast capabilities of
legacy networks. If all the IPv6 protocols are to continue to work
over ATM without any modification, then this type of multicast
capability must be provided on the ATM network. While IP multicast
over ATM has been defined in IP-ATMMC, the MARS mechanism as
currently defined will not scale well in IPv6 environments where
all nodes always require multicast capabilities. For example, all
nodes would have to maintain VCs to the MARS server, an all-nodes
MCS, and an all-routers MCS, thus creating a large number of VCs on
each of these servers, plus a large MARS database. Further, the
overhead required for a node to send a single Neighbor Solicitation
(NS) message in order to perform Neighbor Discovery in the MARS
model is very high. What is needed is a way of performing ``light
weight'' multicast for discovery protocols while still using MARS
for more ``heavy weight''multicasting.
To provide ``light weight'' multicast services, and to form an IPv6
link on an ATM network we define a service call a Logical Link
Server (LLS). The role of these servers in an IPv6 over ATM
``link''is to provide connectionless multicast services for a group
of nodes which comprise an IPv6 subnet or link. Since this
collection of nodes may be smaller than the number of nodes on an
ATM network, the grouping of nodes is called a ``Logical Link ''
since it represents a logical, rather than physical, partitioning
of nodes. Each Logical Link is composed of some number of nodes
and one or more LLS servers. To provide redundancy and
scalability, the LLSs are organized into a tree structure as
described later.
An LLS server is a service that can be located on any ATM node
independent of other IPv6 services. They can function
independently of IPv6 ATM interfaces and are not addressable IPv6
entities. The LLS servers are primarily multicast packet relay
services and there are no node to LLS protocols other than control
and configuration protocols. The LLS servers themselves do not
participate in, change, or replace, any IPv6 protocol.
The LLS mechanism is not intended to replace the MARS model, but to
supplement it. The LLS mechanism is intended to be used primarily
for very low bandwidth multicast traffic where the overhead of
communicating with the MARS server and setting up a new VC would be
too high (such as in the case of discovery protocols). MARS is
still the recommended mechanism for doing general multicast on a
Logical Link, especially high bandwidth multicast. However, it is
possible to form a Logical Link with no MARS services and still
have full IPv6 services and basic multicast services as long as the
LLS tree can handle the multicast traffic.
draft-ietf-ion-ipv6atm-framework-00.txt [page 12]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
The mechanism described here requires no modification to any
existing IPv6 protocols. They will continue to operate as they do
on legacy LANs requiring no modifications of the network layer to
accommodate ATM. However, some additional protocols are required
for node and LLS server-to-server configuration and control, but
these are isolated to the convergence layer between IPv6 and ATM.
Also, this framework does not depend on any central repository of
information for the network to operate. While some small amount of
state is maintained by the LLS and hosts, this only relates to
immediate multicast group membership and tree configuration. All
node specific information remains on the end-nodes and is obtained
through the existing discovery mechanisms rather than from some
server's cache. This makes the LLS easier to implement, more
efficient, makes failover easier, and maintains the full link
semantics as expected by IPv6. For example, this allows host
aliasing and node load-balancing between interfaces by allowing
each node to choose what response to return to each solicitation.
Also, all IP security (IPv6-SPEC, IPv6-AUTH) associations and
semantics are fully preserved.
The basic idea of the LLS tree is to provide a mechanism for moving
multicast packets between nodes. While multicast packets to any
destination can be moved through the LLS tree, the tree is
primarily intended to be used by the Neighbor Discovery protocols,
as described in Appendix A. Packets sent to unicast addresses MUST
be sent over a VC connecting the source and destination nodes (or
via a router).
3.3. Logical Link Servers
A Logical Link Server (LLS) is primarily a packet relay service
which relays IPv6 multicast packets between senders and receivers.
The only function of a LLS is to relay multicast packets. An LLS
does not participate in any IPv6 protocol or maintain any database
other than a database of multicast group membership for making
packet forwarding decisions. An LLS does not provide any QoS
connections between nodes, and does not carry unicast traffic.
The basic model of a LLS is a service to which multiple IPv6 nodes
connect and send multicast packets (how a node would choose to send
a multicast packet via the LLS or the MARS mechanism is described
in detail later). The LLS then simply relays the multicast packet
from the sender to the receivers who have joined the destination
multicast address group. To distribute multicast packets to
receivers in an efficient manner, the LLS establishes a PtM VC to
all receivers which join a specific multicast group. To reduce the
number of VCs that may be required by the LLS, aggregating multiple
multicast groups over a single PtM VC is recommended (but not
required). All nodes communicate to the LLS via a PtP VC. The LLS
provides multicast services as required by IP-multicast and by IPv6
in general.
Note that the LLS does not examine the data packets sent by any
host other than to extract the destination address to determine on
draft-ietf-ion-ipv6atm-framework-00.txt [page 13]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
which PtM VC the packet should be sent. The LLS does not
participate in the IPv6 protocols in any way.
At a minimum a LLS will have a single PtM VC over which packets
sent to the all-nodes multicast address will be relayed. Other
multicast address groups may be aggregated into this single PtM
connection, or additional PtM VCs can be created. At a minimum
each node will join the all-nodes multicast group and its own
solicited node multicast group. Because of this, a LLS might end
up supporting one PtM connection for each solicited-node multicast
address, which could result in a large number of PtM VCs getting
created. To reduce the number of PtM VCs, the LLS may aggregate
multiple multicast groups onto a single PtM VC. Since hosts must
already filter incoming multicast packets at the IPv6 layer,
sending multicast packets to nodes which are not interested in them
will result in the receiving nodes silently dropping the packets.
As long as the packets get delivered to all hosts which are
interested in the packets multicast protocols will operate
normally. How many PtM VCs a LLS can create is expected to depend
on the capabilities of the device on which the LLS is implemented.
This is a scaling and implementation issue, as is how to aggregate
multiple multicast groups to specific VCs.
The number of nodes which a specific implementation of a LLS can
support is highly implementation dependent. To form large Logical
Links more than one LLS might be required to handle all the
connections from all the nodes. Even if multiple LLSs are not
needed to accommodate all the LLs nodes, in many cases it is
desirable to have multiple LLSs for redundancy so that if a LLS
fails nodes could then connect to any remaining LLSs. Since the
LLSs maintain no link wide databases, it is very easy to duplicate
them. Further, the basic structure of the LLS allows multiple LLSs
to be arranged in a tree structure to provide any level of
scalability needs. This also makes building a large LL easy since
each LLS operates in essentially the same manner, so only a single
service needs to be build and replicated.
To extend the Logical Link to multiple LLSs (which all function to
provide services for only one LL) the multiple LLSs are linked
together in a tree fashion in exactly the same way nodes are
connected to a single LLS. This enables the existing LLS
mechanisms to be use to provide a much larger ``virtual''LLS to the
nodes by simply replicating the LLS mechanism. When a LLS tree is
formed there are multiple LLSs at each level of the tree except the
root. Each LLS at a specific level functions identically to other
LLSs on the same level. To identify the LLS levels and the servers
at each level the following notation is used:
LLS(n) ---denotes a LLS at level n. The LLS at the root of the tree
is referred to by level, or by the notation LLS(Root).
An node may connect to any LLS on the tree. Since all LLSs operate
identically, there is no special requirement for node versus LLS
connections. Each LLS is configured to operate at a given level in
draft-ietf-ion-ipv6atm-framework-00.txt [page 14]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
the tree. A LLS configured to operate at level n of the tree may
connect to any level LLS operating at a level between n+1 and the
root. This is done for redundancy and failover, and to prevent two
LLSs from connecting to each other to form a ``circular'' path on
the tree.
To build a LLS tree, a LLS connects to a LLS above it via a PtP VC
just as nodes connect to LLSs. That is, LLS(n) server makes a PtP
VC to LLS(n+x) for x>0 (also referred to as an LLS(HIGHER)). The
LLS(HIGHER) server then connects each LLS(n) server to a PtM
connection through which it can send packets to all LLSs below it.
The LLS(Root) server makes no connections in the upward direction.
Only node can connect to any LLS available server. Any LLS(n)
server can connect to any available LLS(HIGHER) server. This makes
services at any level of the tree (other than the root) redundant
since any available LLS can be used when a LLS fails. Root
redundancy and failover must be handled differently since there can
be only one LLS(Root) server on the tree.
An LLS tree can be configured to be as wide or as high as is
necessary to achieve the desired level of scalability and
redundancy. Any LLS(0) can connect to any LLS(x) for x>0, and
LLS(1) can connect to any LLS(1+x) for x>0, and so on. There is no
requirement for the tree to be configured in any particular manner
as long as the tree architecture is maintained, and no node or LLS
is connected more than once.
The LLS(Root) is always the authority for any Logical Link specific
configuration information (information which relates to the
configuration and maintenance of the LL, not any IPv6 configuration
information). Administering the LL from the Root provides a single
point of administration for all services on the LL. The LL
configuration information is distributed from the Root to all other
LL entities as part of tree configuration. Configuration
information is distributed only when the tree configures, breaks
and reconfigures (due to LLS or network failures), and when the
administrator changes the LL configuration.
There are no LL wide databases. Each LLS maintains multicast group
membership lists for those entities to which it is directly
connected, but has no information on the current state of any other
part of the LL. The multicast group membership information is
needed to maintain the PtM VCs for each multicast group address (or
aggregated group addresses). If a LLS fails then the entities
which connect to it will locate another suitable LLS on the tree,
connect to it, and supply their current multicast group membership
state.
Because IPv6 makes heavy use of multicast, the responsibility of
maintaining the node multicast group state ultimately resides on
the nodes them selves. Thus, each node is required to keep track
of which multicast groups it has joined and how packets are to be
sent to each destination multicast group. This makes the
implementation of the servers less complex, and is consistent with
draft-ietf-ion-ipv6atm-framework-00.txt [page 15]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
wanting the hosts to have ultimate control over their operations on
the LL at both the ATM and IPv6 levels.
Each entity on the LL must maintain a copy of the link
configuration information distributed by the Root. Must be done so
that all entities have the same information on LL operation, and to
facilitate failover. This information is not expected to change
frequently, so the maintenance of this information will not consume
many link resources.
In operation, the various VCs on the tree will carry specific forms
of information. The PtP VCs will carry either control (tree
configuration information and responses) packets in both the ``up''
and ``down''directions. The PtP VCs will carry IPv6 multicast data
packets only in the ``up'' direction. The PtM VCs will carry only
multicast data packets.
4. VC Characteristics and Message Formats
There are two classes of VCs specified in this framework: the VCs
used to interconnects elements of the LLS tree (including nodes),
and VCs used for data communications between nodes. These two
types of VCs should share as many characteristics as possible,
particularly packet framing.
4.1. Message Encapsulation
There are three different types of messages that can be sent on VCs
on a Logical Link. Some VCs are restricted to only carrying
messages of specific types. Each LLS will enforce the message type
restriction to prevent invalid messages from being moved by the LLS
tree. The messages which can be sent between entities of a Logical
Link can be broken down into two type: 1) IPv6 datagrams, and 2)
LLS control messages. There are two IPv6 datagram types (unicast
and multicast), and only one type of control message.
Additionally, IPv6 datagrams sent over VCs managed by MARS will use
the encapsulation specified by the MARS specification.
All packets (control or data) will be sent using LLC/SNAP
encapsulation unless the sending and receiving nodes have
negotiated null encapsulation on a VC. Only PtP VCs between nodes
can use null encapsulation.
4.1.1. IPv6 Unicast Packet Encapsulation Format
All unicast IPv6 data frames MUST start with the following sequence
of octets:
0xAA 0xAA 0x03 0x00 0x00 0x00 0x86 0xDD
draft-ietf-ion-ipv6atm-framework-00.txt [page 16]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
That is, and LLC/SNAP encapsulation (0xAA-0xAA-0x03) with the IPv6
OUI/PID of 0x00-0x00-0x00-0x86-0xDD followed by the IPv6 datagram.
4.1.2. IPv6 Multicast Packet Encapsulation Format
Mutlicast packet encapsulation follows the MARS multicast packet
encapsulation and uses an eight byte CMI and type #2 encapsulation.
All IPv6 multicast data frames transmitted on the LLS tree MUST
start with the following sequence of octets:
0xAA 0xAA 0X03 0x00 0x00 0x5E 0x00 0x04 CMI 0x85 0xDD 0x00 0x00
That is, LLC/SNAP encapsulation (0xAA-0xAA-0x03) followed by the
OUI of 0x00-0x00-0x5E and a PID of 0x00-0x04. The value of the CMI
octets MUST be the sending node's host token for the sending
interface, padded to 8 octets with zeros. This is then followed by
the IPv6 protocol value of 0x86-0xDD and two octets of padding.
The IPv6 multicast datagram immediately follows the two padding
octets.
4.1.3. LLS Control Message Encapsulation Format
Control messages send between entities of the LLS tree follow the
MARS control message encapsulation format and are encapsulated as
follows:
0xAA 0xAA 0x03 0x00 0x00 0x00 0xXX 0xXX
That is, LLC/SNAP encapsulation (0xAA-0xAA-0x03) followed by the
LLS control message OUI/PID of 0x00-0x00-0x00-0xXX-0xXX (where the
value of the PID is to be determined). The control message
immediately follows the OUI/PID.
4.2. ATM Address Format
ATM addresses are exchanged and stored at both the IPv6 to ATM
convergence layer, and at the IPv6 layer. At the convergence layer
ATM addresses are used to setup calls and keep track of VCs. At
the IPv6 layer, ATM addresses are passed between nodes in IPv6
Neighbor Discovery Link Layer Address options in Neighbor
Advertisement, Router Advertisement, and Redirect messages. The
IPv6 network layer does not do anything with ATM addresses other
than exchange them and them provide them to the convergence layer.
To make these addresses easier to handle, the same format for
representing the variable length ATM addresses and subaddresses
should be used throughout the system. The format specified here is
essentially the same as described in ATM-ND except that provisions
for a second subaddress has been added to accommodate UNI 4.0
addresses.
draft-ietf-ion-ipv6atm-framework-00.txt [page 17]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
The format of ATM addresses is:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | NTL | STL1 | STL2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
/ ATM Address /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length ---The length of the ATM address or subaddresses in bytes.
This value MUST include the Length, NTL, STL1, and STL2 fields and
any padding bytes used to pad the option out to a four octet
alignment for the next option.
NTL ---This is the Number Type and length of the ATM address part
of the address. The lower six bits encode the length of the
address in octets. The second most significant bit encodes the
type of address. This bit MUST be 0 for ATM Forum NSAPA format
addresses, and 1 for native E.164 format addresses. The high order
bit is not currently defined and MUST be set to 0.
STL1 - This is the subaddress Number Type and length. If no
subaddress is present the value of this field MUST be 0. If a
subaddress is present then the lower six bits encode the length of
the address in octets. The second most significant bit encodes the
type of address. This bit MUST be 0 for ATM Forum NSAPA format
addresses, and 1 for native E.164 format addresses. The high order
bit is not currently defined and MUST be set to 0.
STL2 ---The same format as STL1. If STL1 is 0 then STL2 MUST be 0.
The ATM Address MUST be padded to a length that is a multiple of
four octets. To pad an address the appropriate number of trailing
bytes MUST be set to 0. The Length field includes the padding.
4.3. ATM IPv6 Interface Token Format
For each Logical Link which a node joins, the node must select an
interface-token as described in IPV6-ADDRCONF. This interface
token MUST be no longer than 6 octets. Additionally, each
interface-token MUST be unique on the LL on which it is used. The
same interface-token MAY be used on different LLs providing that
link-local addresses are formed as described in IPV6-IID. If IID
is not used the interface-tokens MUST be unique across all Logical
Links (since host tokens are used to create link-local addresses,
and link-local addresses must uniquely identify an interface or
virtual interface).
draft-ietf-ion-ipv6atm-framework-00.txt [page 18]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
4.3.1. Generating Interface-tokens from NIC MACs
If an interface has one or more MAC addresses configured in ROM
then these addresses MUST be used as the interface-token. If DAD
detects a duplicate address then the procedure for generating
interface-tokens algorithmically described later SHOULD be
followed. If algorithmic generation is not used or fails then the
node MUST allow the interface-token to be manually set.
A node MUST NOT join more than one Logical Link using the same
interface-token unless the process for creating link-local
addresses as described in IPV6-IID is used. If IPV6-IID is not
used then the node MUST use a different interface-token for each LL
joined by using either using the procedure for generating
interface-tokens algorithmically described later or by allowing the
interface-token to be manually set.
4.3.2. Generating Interface-Tokens from NSAPAs
For nodes which have no configured MAC addresses, but which are
configured with NSAPAs with zero or more subaddresses, the
interface-token MUST be generated using the 6 ESI octets from the
NSAPA ATM address (not from the subaddresses). If DAD detects a
duplicate address then the procedure for creating interface-tokens
algorithmically described later SHOULD be followed. If algorithmic
generation is not used or fails then the node MUST allow the
interface-token to be manually set.
4.3.3. Generating Interface-Tokens from E.164 Addresses
For interfaces which have no configured MACs but which are
configured with a native E.164 address and zero or more
subaddresses, the interface token MUST be generated from the E.164
address by converting the BCD representation into a binary value.
This value is then truncated to 48 bits and used as the host token.
If DAD detects a duplicate address then the procedure for creating
interface-tokens algorithmically described later SHOULD be
followed. If algorithmic generation is not used or fails then the
node MUST allow the interface-token to be manually set.
4.3.4. Generating Interface-tokens Algorithmically
4.4. LLS VC Characteristics
VCs between elements of the LLS tree, including the VCs between
nodes and the LLS(N) servers, should all be set up with the same
characteristics. Since these VCs are not used to carry data
between nodes, they have no QoS or bandwidth requirements.
The characteristics of the PtP VCs interconnecting elements of the
LLS tree are:
. Best effort traffic type in UNI 3.X environments, and ABR in
UNI 4.0 environments.
draft-ietf-ion-ipv6atm-framework-00.txt [page 19]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
. An MTU of 9188 bytes. The MTU MUST NOT be negotiated at call
setup time.
. LLC/SNAP encapsulation as specified in IP-ATMND. Optionally,
null encapsulation MAY be negotiated at call setup time.
The characteristics of the PtM connections which connect LLS
servers to the LLS servers or nodes below them are:
. Best effort traffic type in UNI 3.X environments, and ABR in
UNI 4.0 environments.
. An MTU of 9188. This MUST NOT be negotiated since all leaves
of the PtM connection may not be able to handle an MTU
negotiated by the root of the PtM VC and the initial leaf. All
entities MUST handle an MTU of 9188 on this connection.
. LLC/SNAP encapsulation. Encapsulation MUST NOT be negotiated
since all leaves of the PtM connection may not be able to
handle alternate encapsulation formats negotiated by the root
of the PtM call and the first leaf. All entities MUST handle
LLC/SNAP encapsulation.
4.5. Data VC Characteristics
The VCs used for data communications between nodes can be set up
according to QoS requirements of the application driving the
connection. Since the purpose of this framework is to provide an
environment where nodes on the same ATM network can directly
communicate to utilize ATM QoS features, the use of multiple VCs
with different traffic parameters is encouraged. However, the
default circuits which are established between nodes (for example,
the VC established in response to a Neighbor Solicitation) should
have the following characteristics:
. Best effort traffic type in UNI 3.X environments, and ABR in
UNI 4.0 environments.
. An MTU of 9188 bytes. The MTU MAY be negotiated at call setup
time to any value permitted by IPv6. The MTU MUST NOT be
negotiated to a value less than that supported by IPv6.
. LLC/SNAP encapsulation as specified in IP-ATMND. Optionally,
null encapsulation MAY be negotiated at call setup time. All
nodes MUST support the default LLC/SNAP encapsulation.
Additional VCs can be created as needed with any characteristics as
needed as long as both communicating nodes agree on all VC
characteristics, and the VC parameters do no violate any IPv6 or
ATM specification.
5. Logical Link Control Messages
The various entities on the Logical Link must communicate with each
other to control and maintain the Logical Link structure and
operation. These messages are independent of the IPv6 data flow on
the LL. The messages are generated and processed only by LLSs or
draft-ietf-ion-ipv6atm-framework-00.txt [page 20]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
the IPv6 to ATM convergence layer on the nodes. These messages are
not visible to IPv6.
Control messages MUST be sent between LLS entities on the PtP VCs
connecting the two entities. Control messages MUST NOT be sent
over any PtM VC.
5.1. Logical Link Control Message Formats
Each control message consists of a control message header plus zero
or more options. The options included depend on the type of
control message and the amount of information that the sender needs
to provide. Not all options apply to all control messages. The
control message headers and options MUST begin on a 32 bit aligned
boundary.
The format of the control message header is:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ctype | Modifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ctype ---This is the control message type. The type MUST be one of
the following values:
name value description
LLS_LLCAM 1 Logical Link Configuration Advertisemen
LLS_QUERY 2 Logical Link Configuration Query
LLS_ACK 3 Message Acknowledgment
LLS_NAK 4 Message Negative Acknowledgment
LLS_JOIN 5 Multicast Group Join
LLS_LEAVE 6 Multicast Group Leave
LLS_AID 7 Authentication and Identification
Modifier ---This field provides additional information for certain
control message types. This field MUST be set to 0 if it is unused
for a specific message type.
Length ---This is the total length of the control message,
including the four byte control message header, in bytes.
5.1.1. The IPv6 Multicast Address Option Format
For LL control messages which require that one or more single IPv6
multicast addresses be specified, the addresses are provided in one
or more IPv6 Multicast Address options. The format of this options
is:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
draft-ietf-ion-ipv6atm-framework-00.txt [page 21]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Otype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Multicast Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Otype ---The value 1 (LLS_OTYPE_multicast).
Reserved ---Currently unused and MUST be initialized to 0.
5.1.2. The ATM Address Option Format
In LL control messages that require an ATM address to be specified,
the address is supplied in a single ATM Address Option which
contains a single ATM address and optionally one ATM Subaddress.
The format of this option follows the format specified for use in
IPv6 Link Layer Address options. The format of these options are:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Otype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
/ ATM Address /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Otype ---The value 0x10 (LLS_OTYPE_AA) for the ATM Address Option
or the value ox11 (LLS_OTYPE_AS) for the ATM Subaddress option.
ATM Address - The ATM address and subaddress in the same format as
used in the IPv6 Link Layer Address options. The ATM Address MUST
be padded to a 32 bit alignment by padding it with zeros.
5.1.3. The IPv6 multicast Address Range Option Format
In LL control messages that require a range of IPv6 multicast
addresses to be specified, these addresses are supplied in an
multicast Address Range Option. The format of this option is:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Otype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
draft-ietf-ion-ipv6atm-framework-00.txt [page 22]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
+ +
| |
+ Lower IPv6 Multicast Address +
| |
+ +
| |
+- -+
| |
+ +
| |
+ Upper IPv6 Multicast Address +
| |
+ +
| |
+---------------------------------------------------------------+
Otype ---The value 2 (LLS_OTYPE_MMC).
Reserved ---This field is currently unspecified and MUST be
initialized to 0.
Lower and Upper IPv6 Multicast Address ---The lower and upper
boundaries (inclusive) of the range of IPv6 multicast addresses
being specified. That is, a multicast address A is within the
specified range if lower <= A <= upper.
5.1.4. The Sequence Identifier Option Format
For LL control messages that require a sequence identifier, the
identifier is supplied in a Sequence Identifier Option. The format
of these option is:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Otype | Sequence Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Otype ---The value 0x20 (LLS_OTYPE_SID).
Sequence Identifier ---A value which uniquely identifies a specific
instance of a message. This value MUST be monotonically increasing
at the source of the message. This value MUST NOT be 0.
5.1.5. The Sequence Index Option Format
For LL control messages that send a series of related information
which requires sequencing information, this information is supplied
in the Sequence Index Option. The format of this option is:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
draft-ietf-ion-ipv6atm-framework-00.txt [page 23]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
| Otype | Total | Index | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Otype ---The Value 0x22 (LLS_OTYPE_IDX).
Total ---The total number of packets in the sequence.
Index ---The current packet number in the sequence. This value
MUST be between 1 and Total, inclusive (1 <= Index <= Total).
5.1.6. The LL Entity Identifier Option Format
In LL control messages that require an LL Entity Identifier, this
information is supplied in an Entity Identifier Option. The format
of this option is:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Otype | Etype | Level | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Logical Link ID -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Otype ---The value 0x21 (LLS_OTYPE_EID).
Etype --- MUST be either the value 0 (LLS_ENODE) for endsystem
nodes, or the value 1 (LLS_ELLS) for a LLS server.
Level ---MUST be the value 0 for nodes. For LLSs this is the level
in the LLS tree at which the LLS is serving. The lowest level LLS
is level 0 and is the level at which nodes connect.
Logical Link ID (LLID) ---A unique value identifying a specific
Logical Link. This value is not used in any way by IPv6. This is
only used to identify all entities which may interconnect to form a
single Logical Link. This is primarily used for autoconfiguration
to verify that two connecting entities belong to the same LL. If
no Logical Link ID is used, then the value of this field MUST be 0.
Reserved ---This field in unused and MUST be initialized to 0.
5.1.7. The Authentication Option Format
TBD.
5.2. The Authentication and Identification Message
The Authentication and Identification Message ( LLS_AID) is used by
each entity on the LLS to identify and authenticate itself to the
next entity to which it makes a PtP connection. This message is
draft-ietf-ion-ipv6atm-framework-00.txt [page 24]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
sent by nodes to the LLS server to which they connect, and by
LLS(n) servers to the LLS(HIGHER) servers to which they connect.
This message is used to identify the connecting entity to assure
that the tree gets connected properly. This message SHOULD also be
used to authenticate the connecting entity. By making
authentication part of entity registration it will be possible to
prevent non-authenticating entities from sending or receiving data
on the LLS tree. This will help prevent many types of attacks on
the tree or on specific nodes on the tree.
The LLS_AID MUST contain the Control Message Header and the LL
Entity Identifier Option. Optionally, it SHOULD contain the
Authentication Option.
For LLS_AID messages, the fields in the Control Message Header MUST
be set to the following values:
Ctype = LLS_AID
Modifier = 0
Length = 8 (if no Authentication Option is included) or TBD if the
Authentication option is included.
The fields of the Entity Identifier Option are set as appropriate
for the sender of the message.
The fields in the Authentication Option are set as appropriate for
the security association that exists between the sender and the
intended recipient.
5.3. The Acknowledgment Message
The Acknowledgment Message is used to inform the sender of a packet
that the receiver has accepted and processed a packet. The
contents of the Acknowledgment. The contents of the Acknowledgment
message header are:
Ctype = LLS_ACK
Modifier = the Ctype of the message being acknowledged
The value of the Length field depends on the options provided in
the acknowledgment. In the simplest case, the acknowledging entity
can simply turn any received message into an acknowledgment message
by moving original Ctype to the Modifier field and then setting
Ctype to LLS_ACK. In this case the Length field will remain
unchanged, as will any options. However, in many cases it would be
a waste of bandwidth to return some options
(for example, to return the Authentication Option or an ATM address
option). An acknowledging entity SHOULD return only those options
that are necessary for the original sender to uniquely identify the
message being acknowledged. For various message types the minimum
options that MUST be including in any acknowledgment are listed in
the following table:
message minimal reply options
draft-ietf-ion-ipv6atm-framework-00.txt [page 25]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
LLS_AID none
LLS_JOIN IPv6 multicast Address
LLS_LEAVE IPv6 multicast Address
LLS_LLCAM Sequence ID, Sequence Index
Note that LLS_QUERY messages are not acknowledged.
An entity MUST accept an acknowledgment containing more than the
minimal required options as long as those options were present in
the original message.
5.4. The Negative Acknowledgment Message
The Negative Acknowledgment message is used by a receiving entity
to inform a sending entity that the receiver has been unable to
process a control message sent by the sender. The usage of this
message is the same as that of the Acknowledgment message except
that the packet header Ctype field MUST be set to LLS_NAK.
5.5. The Link Configuration Advertisement Message
The Logical Link Configuration Advertisement Message (LLCAM) is
used to distribute Logical Link wide configuration information to
all entities on the LL. To make LL administration easy, and to
assure consistency among all members of the LL, all LL
configuration information will be administered at the LLS(Root) and
then distributed throughout the LL via the LLS tree. Since LL
configuration is not expected to change frequently, it need only be
distributed as the tree is formed, or when the information is
changed at the LLS(Root).
The LL Configuration Advertisement Message contains a list of all
IPv6 Multicast addresses which are to be handled by the LLS tree.
All other multicast addresses MUST use MARS. The distribution of
this information allows a network administration to select which
IPv6 multicast addresses will be handled by the LLS tree so that
the operation of the LL can be tuned as needed.
The Control Message Header fields of a LLCAM message contain the
following information:
Ctype = LLS_LLCAM
Modifier = 0
Length = length of header and all options
An LLCAM message MUST contain a Sequence Identifier Option. The
contents of this option must uniquely identify the version of the
configuration information being distributed. This value MUST NOT
change between retransmissions of the same information. This value
MUST change if the distributed information is changed.
It is possible that the information distributed in an LLCAM message
could be too long to fit into a single AAL5 PDU. In such cases,
draft-ietf-ion-ipv6atm-framework-00.txt [page 26]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
the configuration information can be sent in a series of LLCAM
packets. When more than one LLCAM message is sent for a single
configuration update, the packet MUST contain a Sequence Index
Option so that receivers can identify all packets which comprise
the advertised configuration. The Total field in the Sequence
Index Option MUST contain the total number of packets that comprise
the advertisement. The Index field MUST be set to indicate the
position of the current packet in the sequence. Index field values
begin at 1 and MUST be less than or equal to the value of the Total
field. If supplied, the Sequence Index Option MUST occur
immediately after the Sequence Identifier Option. If only a single
LLCAM message is required to distribute the configuration
information then the Sequence Index Option is not required, but
receivers MUST accept Sequence Index Options with a Total and Index
field of 1.
Parts of multi-message configurations MUST be transmitted in index
order (i.e., lowest to highest index value).
The LLCAM messages will contain zero or more IPv6 multicast
Address Options or IPv6 multicast Address Range Options. These
addresses are those that the network administrator has designated
to be serviced by the LLS tree (in addition to those predefined
addresses which are always serviced by the LLS tree as defined
elsewhere in this document). All addresses not listed MUST be
serviced by MARS. Both options MAY be used to express a single IPv6
multicast address. In the case of an IPv6 multicast Address Range
option, a single address MAY be defined by setting both the Upper
and Lower IPv6 Multicast addresses to the same value. Receivers
MUST accept single addresses expressed in either form. Ranges of
multicast addresses are expressed using the Upper and Lower fields
of the IPv6 multicast Address Range Option. When a range option is
provided then all addresses between Lower and Upper (inclusive) are
serviced by the LLS tree.
If an LLCAM message contains no IPv6 multicast address options,
then all multicast addresses, other than the predefined set, MUST
be serviced by MARS.
If all multicast addresses are to be serviced by the tree then the
LLS(Root) MAY NOT distribute any LLCAM messages. The defined
default behavior for all nodes is to use the LLS tree for all
multicast activity until an LLCAM message with different
configuration information is received. This assures all nodes have
full multicast capabilities at boot time. Alternately, the
LLS(Root) could choose to distribute an LLCAM message with a single
IPv6 multicast Address Range option which contains the Lower value
of FF00:0:0:0:0:0:0:0 and the Upper value of
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF to indicate all multicast
addresses.
As the LLCAM packets are transmitted from entity to entity on the
LLS tree the contents of the packets MUST NOT be altered.
Intermediate LLSs MUST store the packets unchanged for forwarding
draft-ietf-ion-ipv6atm-framework-00.txt [page 27]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
down the tree. Thus, every entity on the tree will receive exactly
the same information in exactly the same format. This is required
so that individual packets in a sequence can be uniquely identified
for error recovery.
5.6. The Link Configuration Query Message
If a LLS entity needs to update its Logical Link Configuration
information, it may query the current information from the ``upper''
entity to which it's directly connected at any time. This is done
by sending a Link Configuration Query message to the ``upper''
entity. This message can be used to update all the configuration
information, or a single packet in an LLCAM sequence.
The contents of the Control Message Header for a query messages is:
Ctype = LLS_QUERY
Modifier = 0
Length = length of header plus any options
To query the current configuration information an entity sends a
Link Configuration Query message with no options to the next higher
LLS entity. The receiving entity MUST respond by transmitting its
currently stored LLCAM messages over the VC on which it received
the query. If the receiving entity does not have any LLCAM
messages stored it MUST silently discard the query.
An LLS entity can query one LLCAM message of a sequence. This is
used when an entity receiving a sequence of LLCAM messages detects
that one or more messages in the sequence has been lost (by
detecting a gap in the Index field values between two messages in
the same sequence). In cases of missed LLCAM messages, the entity
receiving the LLCAM messages can create a query message to query a
specific message in a specific sequence from the sender. To do
this, the querying system creates an query message which MUST
contain a both Sequence Identifier Option and a Sequence Index
Option. The Sequence Identifier option MUST contain the Sequence
ID from one of the received LLCAM messages. The Index field of the
Sequence Index Option MUST contain the index of the message being
queried. The Total field of the Sequence Index Option MUST contain
the Total field value from one of the received LLCAM messages.
5.7. The Multicast Group Join Message
When a node wants to receive data sent to a specific multicast
address the node must join the multicast group for that address.
This process requires that the node inform the LLS that it wants to
be sent data addressed to a specific multicast address. The LLS
then joins the node to the specified multicast group. To join a
specific multicast group, a node must send a Join message to its
LLS.
The Control Message Header values for a Join message are:
draft-ietf-ion-ipv6atm-framework-00.txt [page 28]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
Ctype = LLS_JOIN
Modifier = 0 (LLS_JOIN_ONE) or 1 (LLS_JOIN_ALL)
Length = the length of the options plus the header length
Nodes normally join a single group. To join a single multicast
group a node sends a Join message which MUST contain exactly one
IPv6 multicast Address Option and exactly one ATM Address Option.
The Modifier field of the Control Message Header MUST be set to 0
(LLS_JOIN_ONE) for individual joins. The IPv6 multicast Address
Option MUST contain the IPv6 multicast address on which the node
wants to receive data. The ATM Address Option MUST contain a valid
ATM address on which the node will accept a call to establish a VC
over which the data will be sent. Note that the processing of the
Join by the LLS will not necessarily result in a new call being
placed to the node depending on how the LLS handles multicast
address aggregation.
A node MUST NOT join more than one address in a single Join
message. If a Join message contains more than one IPv6 multicast
Address option, more than one ATM Address Option, or an IPv6
multicast Address Range Option, then the receiving LLS MUST reject
the join request.
Some nodes, particularly multicast routers, will want to listen to
all multicast traffic on the Logical Link. To do this, they must
issue a promiscuous join the LLS. A promiscuous join will join the
requesting node to all multicast groups. A promiscuous Join
message MUST NOT contain any IPv6 multicast Address Options. The
only valid options are the ATM Address Option. The value of the
Modifier field of the Control Message header MUST be set to the
value 1 (LLS_JOIN_ALL). If a promiscuous Join message contains any
IPv6 multicast Address Options the LLS MUST reject the join
request.
Node MUST NOT send more than one Join message per multicast group
address or more than one promiscuous join without first leaving a
joined group.
5.8. The Multicast Group Leave Message
When a node no longer wants to receive packets addressed to a
particular multicast address, it must leave the multicast group for
that address. The node does this by sending a Leave message to the
LLS server. A Leave message requests the LLS to remove the node
from the specified multicast group and to disconnect the associated
VC if necessary. Note that leaving a group will not necessarily
result in a VC being disconnected or in traffic on the indicated
group no longer getting delivered. The exact actions taken for a
leave request will depend on if a LLS implements multicast address
aggregation.
The Control Message Header for a Leave message MUST contain the
following values:
draft-ietf-ion-ipv6atm-framework-00.txt [page 29]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
Ctype = LLS_LEAVE
Modifier = 0 (LLS_JOIN_ONE) or 1 (LLS_JOIN_ALL)
Length = the length of the message header plus any options
When leaving a specific multicast group exactly one IPv6 multicast
Address Option MUST be included in the Leave message. The message
MUST NOT contain any other options. The Modifier field of the
message header MUST be set to the value 1 (LLS_JOIN_ONE). The IPv6
Multicast Address value in the option specifies which multicast
group the node is leaving.
If a node is leaving promiscuous mode then the Leave message MUST
NOT contain any options, and the Modifier field of the message
header must be set to 1 (LLS_JOIN_ALL).
A node MUST NOT issue more than one Leave request per Join.
6. Security
An important feature of this architecture is that IPSEC continues
to work without any changes. All IPv6 security semantics are
maintained including the use of authentication in neighbor and
router discovery. That is, solicited nodes can choose to respond
to a solicitation based on the authentication information contained
in the solicitation packet. No changes are required to any IPv6
layer or higher layer security protocols, and no security is lost.
However, even with IPv6 security, it is necessary to provide some
security at the LLS layer to insure that a Logical Link can not be
attacked by a node pretending to be an LLS. Also, since a node
could attach to a LLS and listen promiscuously to multicast
addresses, unauthorized nodes should be prevented from joining the
LL. Thus, additional security has to be introduced at the LLS
layer to provide authentication between entities in the LL. This
authentication is completely independent of any IPv6 security
mechanism and is used only to insure the integrity of the LL.
This additional security takes the form of authentication
information that is contained in all LLS control messages and of
only permitting authenticated entities to send or receive data
through the LLS tree. This is authentication information is
carried in Authentication Options that are part of each LLS Control
message. Thus, each LLS Control message is authenticated to
prevent unauthorized hosts from attacking a LL via the LLS
interfaces.
The contents of the Authentication Option is still under
consideration and will be defined in a future revision of this
daft. However, the IPSEC model will probably be used for LLS
control messages.
draft-ietf-ion-ipv6atm-framework-00.txt [page 30]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
7. Conceptual Model and Configuration
7.1. Conceptual Model
The LLS and node operations are described in detail in sections 9.
Logical Link Server Operation and 10. Node Operation, respectively.
While this document specifies LLS and node behavior and not
implementations, conceptual models of a LLS and a node are
described here to aid in understanding their behavior. The abstract
data structures described in this section are for illustrative
purposes only, to facilitate the explanation of the LLS and node
operations. Actual LLS and node implementations are not required
or expected to use these conceptual models, but must conform to the
described behavior to be compliant with this specification.
In addition to the LLS-specific or node-specific information
described in the following sections, each LLS or node MUST maintain
the following common configuration information:
. LLINK_ID ---The Logical Link ID of the Logical Link on which
the LLS will serve, or to which the node will connect. Any
instance of a LLS can serve on only one Logical Link at a time.
An IPv6 node can connect to multiple Logical Links via multiple
instances of the node convergence layer; however each node
convergence layer can connect to only one Logical Link at a
time.
. LLINK_USE_AUTH --- This flag is set if authentication
information is to be exchanged during the registration process
performed when LLSs and nodes connect to the Logical Link.
. LLINK_ADDR_LIST ---A collection of one or more prioritized sets
of LLS ATM addresses that the LLS or node can use to attach to
the Logical Link. This organization facilitates LLS load
balancing, redundancy and failover. Each set consists of a
group of peer LLS servers (henceforth called a ``peer-set'',
each of which is considered equal in terms of connection cost
or ability to handle a specific load. Each peer-set is assigned
a relative priority level, used to select the order in which
connections to LLSs are made. The priority levels need not be
sequential, and limits on the permitted number of priority
levels is implementation dependent. When attempting to attach
to the Logical Link, LLSs and nodes try to connect to each
address in the highest priority peer-set, before attempting to
iteratively connect to addresses in lower priority peer-sets.
7.1.1. LLS Model
An LLS is an ATM service which places and receives calls, and which
processes AAL5 PDUs, not ATM cells. As such, it sits above the ATM
Adaptation layer and makes direct use of ATM services. In order to
operate, each LLS must allocate the following ATM resources:
. LLSLNSAP ---ATM Address on which the LLS will accept calls from
entities at lower levels of the tree and through which it will
place calls to lower level entities. This is the ``lower''
connection endpoint for the LLS. Every LLS, including the
LLS(Root), MUST allocate and bind to exactly one ATM address
draft-ietf-ion-ipv6atm-framework-00.txt [page 31]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
for this purpose. Because this ATM address may be configured in
various LLS or node LLINK_ADDR_LISTs, this ATM address SHOULD
be deterministic.
LLSUNSAP ---ATM Address on which the LLS will accept calls from
entities at the next higher level in the tree and through which it
will place calls to higher level entities. This is the ``upper''
connection endpoint for the LLS. Every LLS, except the LLS(Root),
MUST, allocate and bind to exactly one ATM address for this
purpose.
At the ATM level a LLS will have to be configured with the
following information before any calls can be placed or received:
. LLS_LEVEL ---The level of this LLS in the tree hierarchy. A
LLS(LLS_LEVEL) may connect to any LLS(n) in the hierarchy such
that LLS_LEVEL<n<=Root. The levels of the tree are defined as
8 bit numeric values starting with the value 0 for the lowest
level. There is no pre-defined level value for the LLS(Root)
(the LLS at the top of the tree). The LLS(Root) is assigned
its level just like any other LLS.
. LLS_ISROOT ---This is a flag that is set on the LLS(Root) and
is reset on all other LLSs. This identifies a LLS as being at
the top of the hierarchy (i.e., the LLS(Root) will make no
connections to above it).
In addition to this information, each LLS MUST obtain the necessary
security keys required for authentication during the LLS
registration process if authentication is used.
The information and resources described above are all that is
needed for a LLS to boot and connect to other entities on the LLS
tree.
Each LLS MUST maintain the following data:
. LLS_CAMS ---One complete sequence of LLCAM messages. These
messages are stored as received. Each LLS MUST maintain only
one complete sequence of LLCAM messages. Incomplete sequences
MUST be discarded if the missing pieces are not successfully
queried. The current sequence MUST NOT be deleted until a new
complete sequence is received.
. LLS_multicast_VC ---A list of currently active multicast groups
mappings and the PtM VCs over which packets for that is sent.
A multicast group mapping is a function, f(multicast), which
maps a multicast group address to some value which is used to
aggregate multicast groups.
. LLS_multicast_LIST --- A list of node multicast group
membership. This information is used to keep track of which
nodes belong to which multicast group mappings.
7.1.2. Node Model
Support for the node operations is provided by a convergence layer
that sits immediately below the IPv6 Network Layer, and which
transparently maps the network services required by IPv6, to ATM
draft-ietf-ion-ipv6atm-framework-00.txt [page 32]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
data link services. An IPv6 node may interface to multiple node
convergence layers, each of which connects to exactly one Logical
Link. For multicast operations, the node convergence layer is
responsible for determining, based on the Logical Link
configuration, which operations are to be handled by the LLS tree,
and which are to be handled by MARS (if MARS is present). When
coexisting with MARS, the node convergence layer will interface to
the MARS client convergence layer as a Layer 3 entity. Throughout
this section, the terms ``node''and ``MARS client'' will refer to
their respective convergence layers.
A node will need to maintain the following information for a
Logical Link:
. NODENSAP - The ATM address over which a node places and receives
all calls on the Logical Link. This NSAP is the link-layer
address placed in the Neighbor Discovery messages.
. NODE_STATIC_MC_LIST - A static list of predefined multicast
addresses, which MUST always be handled by the LLS tree. The
predefined multicast addresses mandated by this framework are:
- The ``Link Local All Nodes'' multicast address
- All ``Solicited Node'' multicast addresses.
- The ``All Router'' multicast address
- The DHCP Server/Relay-Agent multicast address
It is recommended that each list element describe a range of
addresses, rather than an individual address. This would allow
all ``olicited Node '' multicast addresses, for example, to be
aggregated into a single list element.
. NODE_DYN_MC_LIST - A dynamic list of configured multicast
addresses that MUST be handled by that Logical Link's LLS tree.
This list is updated by a series of Logical Link Configuration
Advertisement (LLS_LLCAM) messages. It's initial value MUST
indicate that all multicast operations are handled by the LLS
tree. To facilitate processing of LLS_LLCAM message IPv6 MC
Address Range Options, it is recommended that each list element
describe a range of addresses, rather than an individual address.
This would also allow the initialized configured multicast address
list to contain only a single element.
. NODE_LLCAM_SID - A Sequence Identifier from the most recently
received series of Logical Link Configuration Advertisement
Messages. It's initial state MUST be zero.
. NODE_JOIN_LIST - A list of IPv6 multicast groups the node has
joined on the Logical Link, and the mechanism used to join each
group (i.e. the LLS tree, or MARS).
. NODE_ADDRVC_MAP - A list of link-layer-address-to-VC mappings,
each of which associates a link-layer address with the PtP VC over
which data is to be sent and received. If a mechanism for
detecting and releasing idle VCs does not exist, the node SHOULD
support a mechanism for detecting and handling obsolete mappings.
The LLS tree MUST only be used to handle the predefined multicast
addresses and the list of multicast addresses specified in the
LLS_LLCAM messages. Other multicast addresses MUST be handled by
the MARS client, if it is present. The LLS tree MUST NOT be used
draft-ietf-ion-ipv6atm-framework-00.txt [page 33]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
as an automatic MARS failover mechanism to handle these ``other''
multicast addresses; existing MARS failover/redundancy mechanisms
will be employed. However, in the event of a MARS failure, the
Network administrator could update the Logical Link's multicast
configuration information to dynamically force all multicasting
traffic through the LLS tree.
7.2. Manual Configuration
The following information, described in 7.1. Conceptual Model, MUST
be manually configured on each LLS and node on a Logical Link:
. LLINK_ID - Set to the Logical Link's Identifier. LLSs MUST
always set this to a non-zero value. Nodes MAY set this to 0
to indicate an unspecified value.
. LLINK_USE_AUTH - Set to TRUE if authentication information is
to be exchanged when connecting to the Logical Link, and FALSE
otherwise.
The following information must be manually configured on LLS
servers only:
. LLS_LEVEL ---Set to a value between 0 (for the lowest level
LLS) and 256 representing the level in the LLS hierarchy at
which the LLS will function. LLS levels SHOULD be sequential.
. LLS_ISROOT ---Set to TRUE on all LLSs at the top of the tree,
and to FALSE on all other LLSs. The LLS(Root) MUST have both a
valid LLS_LEVEL value and have LLS_ROOT set to TRUE.
. LLINK_ADDR_LIST ---Set to the ATM addresses of LLS(HIGHER)
servers that the LLS can use to connect to the Logical Link.
The ATM addresses are LLSLNSAP(HIGHER) addresses organized as
one or more prioritized peer-sets. This list MUST be empty on
the LLS(Root) and MUST contain at least one address on all
other LLSs.
The following information must be manually configured on nodes
only:
. LLINK_ADDR_LIST ---Set to the ATM addresses of LLS servers that
the node can use to connect to the Logical Link. The ATM
addresses are LLSLNSAPs, organized as one or more prioritized
peer-sets. This list MUST contain at least one address.
It is recommended that node and LLS LLINK_ADDR_LISTs be configured
so that the highest priority peer-sets contain the addresses of
servers at the next higher level in the tree, and the lowest
priority peer-set contain the address of the LLS(Root) and its
backup servers. That is, for a node, the highest priority peer-set
SHOULD contain the addresses of LLS(0) servers, the next lower
priority peer-set SHOULD contain the address of LLS(1) servers, and
so on. Similarly, for a LLS(n) server, the highest priority peer-
set SHOULD contain the addresses of LLS(n+1) servers, the next
lower priority peer-set SHOULD contain the addresses of the
LLS(n+2) servers, and so on. This will allow any node or LLS to
connect around multiple LLS failures at any level above it on the
tree.
draft-ietf-ion-ipv6atm-framework-00.txt [page 34]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
7.3. Autoconfiguration
The LLINK_ID must be manually configured on LLS servers, and
optionally configured to a non-zero value on nodes. Once the
LLINK_ID is known, there are several possible ways in which the
Logical Link could be automatically configured. Among these are the
use of configuration servers on the ATM network, the use of UNI 4.0
anycast addresses, and the use of ILMI entries. This document does
not currently specify a mechanism for autoconfiguration of a
Logical Link, but leaves it for further investigation. However,
the protocols specified in this document do attempt to take
autoconfiguration issues in to account.
8. Common LLS and Node Operations
8.1. Common Logical Link Connection Processing
This section describes the procedure LLS servers and nodes use to
connect to a Logical Link. Connections to a Logical Link are made
in the ``upward'' direction, by connecti ng to a LLS residing at a
higher level in the tree. Since nodes reside at the very bottom of
the tree, LLS(HIGHER) can be any LLS on the tree. The connection
procedure applies to all LLS servers and nodes, except for the
LLS(Root). Since, by definition, the LLS(Root) resides at the top
of the LLS tree, it does not connect upward to another LLS.
When a node or non-Root LLS boots, it MUST use one of the ATM
addresses in its LLINK_ADDR_LIST to connect to a LLS(HIGHER). It
MUST first locate the LLINK_ADDR_LIST peer-set with the highest
priority, and choose one ATM address from the peer-set at random.
The algorithm which chooses the first address from a peer-set MUST
assure that if all LLSs with the same implementation boot at the
same time the selections for equal peer-sets on each LLS will be
evenly distributed among the entries of the peer-sets. A LLS(n)
then attempts to create its LLSVC(n), and a node attempts to create
its NODEVC, by signalling a PtP call using the ATM address selected
from the peer-set.
If the call fails, the node or LLS(n) MUST try the remaining
addresses in the peer-set until all addresses have been tried. When
all addresses in a peer-set have been tried without success, the
node or LLS(n) MUST wait 10 seconds and then retry the addresses in
the peer-set again. The peer-set is tried a total of three times.
If, after three tries, no call succeeds then the process is
repeated using the next lower priority peer-set. If all peer-sets
are tried and no calls succeed then the node or LLS repeats the
process starting again with the highest priority peer-set.
When the LLSVC(n) or NODEVC is established to the LLS(HIGHER), the
calling LLS or node MUST send an LLS_AID message. This message
MUST contain a LL Entity Identifier Option, and SHOULD contain a
Authentication Option.
For the LLS(n), the LL Entity Identifier Option Etype field MUST be
set to LLS_ELLS, the Level field MUST be set to the LLS_LEVEL value
draft-ietf-ion-ipv6atm-framework-00.txt [page 35]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
of the calling LLS (i.e. `n'), and the LLID field MUST be set to
that of LLINK_ID.
For a node, the LL Entity Identifier Option Etype field MUST be set
to LLS_NODE, the Level field MUST be set 0, and the LLID field MUST
be set to that of LLINK_ID.
The contents of the Authentication Option depends on the security
association between the calling node or LLS, and the called LLS.
When the LLS or node sends an LLS_AID message it MUST start a 10
second registration response timer. If no reply to the LLS_AID
message is received before the timer expires then the LLS or node
MUST retransmit the LLS_AID message. If no response is received
after 10 retransmissions then the LLS or node MUST release the VC,
choose another LLS from the LLINK_ADDR_LIST as described above, and
continue the connection attempts using the newly selected ATM
address.
If the LLS receives an LLS_NAK message is response to the LLS_AID
message, the LLSVC(n) or NODEVC will be released by the called
party. In this case the LLS or node MUST choose another entry from
the LLINK_ADDR_LIST as described above, and continue the connection
attempts using the newly selected ATM address.
If the LLS or node receives an LLS_ACK message in response to the
LLS_AID message then it MUST stop the registration response timer.
At this point the LLS or node is successfully registered with the
higher level LLS.
Within 10 seconds of receiving the LLS_ACK, the node or LLS(n) MUST
receive an LLS_AID message from the LLS(HIGHER). If this message
is not received with this period the node or LLS(n) MUST resend the
LLS_AID. If no LLS_AID message is received after a total of three
attempts at 10 second intervals, the node MUST release the NODEVC,
or LLS(n) MUST release the LLSVC(n), and try to connect to another
LLS(HIGHER).
The purpose of the LLS_AID message is to authenticate the
LLS(HIGHER) to the node or LLS(n). The LLS(n) MUST NOT forward any
data or send any LLS_JOIN messages on its LLSVC(n) until it has
received a valid LLS_AID message and authenticated it. Similarly,
the node MUST not send any data or LLS_JOIN messages on its NODEVC
until it has received a valid LLS_AID message and authenticated it.
The node or LLS(n) MUST send its LLS_AID message to the LLS(HIGHER)
without waiting to receive the LLA_AID message. Authentication is
each direction is performed independently, but both parties MUST
successfully authenticate before data can be passed between them.
When a LLS(n) receives a LLS_AID message on an LLSVC(n), and when a
node receives a LLS_AID message on NODEVC, the message MUST be
examined and validated to validate the LLS(HIGHER) to which it has
connected. The following validation checks MUST be performed:
draft-ietf-ion-ipv6atm-framework-00.txt [page 36]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
. The LLS_AID message MUST contain a single LL Entity
Identification Option.
. If LLINK_USE_AUTH is TRUE, the LLS_AID message MUST contain an
Authentication Option.
. The LLS_AID message MUST NOT contain any other options.
. The Etype field of the LL Entity Identification Option MUST
contain LLS_ELLS.
. The value of the LLID field of the LL Entity Identification
Option MUST be equal to the value of LLINK_ID.
. If the recipient of the LLS_AID message is an LLS, the value of
the Level field of the LL Entity Identification Option MUST be
greater than the value of LLS_LEVEL.
. If the Authentication Option is present then its contents MUST
be verified by the security mechanism.
If the LLS_AID message passes all validation then the LLS or node
MUST reply with an LLS_ACK message. If any of the validation checks
fail, the LLS MUST reply with a LLS_NAK message and MUST release
LLSVC(n). Similarly, the node MUST reply with a LLS_NAK message and
MUST release NODEVC. The LLS(n) or node MUST then try to connect
to another LLS(HIGHER).
If the LLS(n) or node receives duplicate LLS_AID messages it MUST
process them normally.
The LLS MUST then perform the additional processing described in
9.1.1. Connecting to Higher Level LLS.
The node MUST then perform the additional processing described in
10.1.Connecting to A LLS.
8.2. Common Recovery from Logical Link Connection Failures
8.2.1. Reconnecting Using Highest Priority Peer-set
If, during initial configuration, an LLS(n) or node is unable to
connect to an LLS(HIGHER) in its highest priority peer-set, but is
able to connect to an LLS(HIGHER) from a lower priority peer-set,
the LLS(n) MUST periodically attempt to move it's connection from a
lower priority server to a higher priority server. This must be
done so that the load on individual LLSs will eventually become
properly redistributed if one or more LLSs does not boot
immediately or if one crashes and then reboots.
If an LLS(n) or node is connected to an LLS(HIGHER) that is not in
its highest priority peer-set, then it MUST attempt to create one
connection to any LLS in a higher peer-set every 60 seconds. To do
this, the LLS(n), starting with the ATM addresses in the highest
level peer-set, attempt to create a connection to each address in
the peer-set. If no connections are made, the LLS(n) waits 10
seconds and then repeats the operation for the next lower priority
peer-set. This process continues until the peer-set for the
current connection is reached. The process MUST stop when the
peer-set of the current connection is reached. If none of the
connection attempts are successful then the LLS(n) MUST repeat the
draft-ietf-ion-ipv6atm-framework-00.txt [page 37]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
process in 60 seconds. This process MUST be continued until the
LLS(n) or node successfully connects to an LLS(HIGHER) whose
address is in the highest priority peer-set.
If, during the search for a higher priority server, the LLS(n) or
node makes a connection to an LLS(HIGHER), it must perform the
registration/authentication procedure to establish that it is
allowed to use the LLS(HIGHER), as described in 8.1. Common Logical
Link Connection Processing. Once the LLS(n) or node successfully
registers with, and authenticates the LLS(HIGHER), it MUST move all
activity to the new LLS(HIGHER).
To move activity to the new LLS(HIGHER), the LLS(n) releases the
LLSVC(n) to the lower priority server, and releases any PtM
connections that have been made to its LLSUNSAP(n). The LLS(n)
must then perform the additional processing described in 9.1.1.
Connecting to Higher Level LLS.
To move activity to the new LLS(HIGHER), the node releases its
NODEVC, and releases any PtM connections that have been made to its
NODENSAP. The node must then perform the additional processing
described in 10.1.Connecting to A LLS.
8.2.2. Handling VC Releases and Errors
The VCs connecting LLSs and nodes to the LLS tree can be released
for any number of reasons. All releases are treated the same,
regardless of the cause of the release.
An LLS(n) or node handles VC connection failures between itself and
its LLS(HIGHER) as follows:
. When an LLS(n) or node receives a RELEASE notification for its
LLSVC(n) or NODEVC, respectively, it MUST release its leaf
connection on the LLSMVC(HIGHER). The LLS(n)or node MUST then
re-establish its connection to the Logical Link by following
the normal procedure for locating and connecting to an
LLS(HIGHER) (see 8.1. Common Logical Link Connection
Processing).
. If an LLS(n) or node detects that its leaf connection on the
LLSMVC(HIGHER) has been dropped then it MUST start a 60 second
timer. If the leaf connection is re-established before the
timer expires then the time-out MUST be canceled. If no
connection is received before the timer expires then the LLS(n)
MUST release its LLSVC(n). Similarly, the node MUST release
its NODEDVC. The LLS(n) or node MUST then follow the normal
procedure for locating and connecting to an LLS(HIGHER) (see
8.1. Common Logical Link Connection Processing).
An LLS(n) handles VC connection failures between itself and an
LLS(LOWER) or node as follows:
. When an LLS(n) receives a RELEASE notification for a PtP VC
LLSVC(LOWER) it MUST signal a DROP PARTY message to drop the
draft-ietf-ion-ipv6atm-framework-00.txt [page 38]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
endpoint from all PtM VCs to which the LLS(LOWER) or node was
previously added.
. When an LLS(n) receives a DROP PARTY notification for one of
the endpoints belonging to its LLSMC(n) VC then it MUST attempt
to re-establish the connection to the endpoint by following the
same procedure used when initially adding the endpoint to the
LLSMVC(n). As with the initial connection, if a connection can
not be made after 6 attempts, the LLS(n) MUST release the
associated LLSVC(LOWER).
8.3. Common Configuration Advertisement Message Processing
A Logical Link Configuration Advertisement message (LLS_LLCAM)
contains all or part of the configured multicast address ranges
that are to be handled by the LLS tree. If the number of
configured multicast address ranges exceeds the number that can be
transmitted in a single LLS_LLCAM message, a LLS or node will
receive a series of LLS_LLCAM messages. Each of these LLS_LLCAM
messages will contain the same Sequence Identifier Option, as well
as a Sequence Index Option denoting the message's relative position
in the sequence.
A LLS or node will initially receive the list of configured
multicast address ranges after joining the Logical Link. It may
subsequently receive an updated list, if the Logical Link list of
configured multicast address is modified, for example. The
LLS_LLCAM messages are always received over the LLS(n) server's
LLSVC(n) and over a node's NODEVC, and are specific to that Logical
Link.
A LLS server's LLS_CAMS list or a node's NODE_DYN_MC_LIST, MUST
always contain information consistent with a given Sequence
Identifier. A LLS or node, therefore, MUST NOT modify its LLS_CAMS
or NODE_DYN_MC_LIST, until it receives all the LLS_LLCAM messages
in a given series, to ensure consistent internal multicast address
information. The LLS or node will need to retain all the LLS_LLCAM
messages in the sequence, until the entire sequence is assembled.
A LLS or node MUST process a LLS_LLCAM message as follows:
. If the LLS_LLCAM message's Sequence Identifier matches the
Sequence Identifier saved from the last LLS_LLCAM series
received, then silently drop the message.
. If the LLS or node is not in the process of collecting a series
of LLS_LLCAM messages, begin a series using the LLS_LLCAM
message.
. If a series is being collected, compare the LLS_LLCAM message's
Sequence Identifier to the series Sequence Identifier. If they
match, add the LLS_LLCAM message to the series, using the
information stored in the Sequence Index Option (the LLS_LLCAM
message MUST be dropped if its Sequence Index already appears
in the series). If the Sequence Identifier does not match, then
silently drop all the LLS_LLCAM messages in the current series,
and begin a new series starting with the new LLS_LLCAM message.
draft-ietf-ion-ipv6atm-framework-00.txt [page 39]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
It is expected that each LLS_LLCAM message in a series will arrive
in sequential order. The LLS or node MUST detect holes in the
series as part of processing the LLS_LLCAM message. If the LLS or
node detects a hole in the sequence, it MUST send, over its
LLSVC(n) or NODEVC, respectively, a LLS_QUERY message containing a
Sequence Identifier Option and a Sequence Index Option. The
Sequence Identifier field of the Sequence Identifier Option MUST be
set to the series' Sequence Identifier. The Sequence Index Total
and Index fields of the Sequence Index Option MUST be set the total
number of messages in the series, and the index of the missing
message, respectively. A LLS or node MAY rely on the LLS
LLS_LLCAM series retransmission logic to avoid needing to detect
the failure to receive the last LLS_LLCAM message in a series. The
LLS(n) or node MUST NOT perform any time-outs for a reply to a
LLS_QUERY. If the LLS_QUERY is lost, the lack of a LLS_ACK
response will cause the LLS(HIGHER) to eventually retransmit the
entire LLS_LLCAM sequence, from which the missing message can be
obtained.
Once a LLS or node receives all the LLS_LLCAM messages in the
series, it MUST send a LLS_ACK message containing a single Sequence
Identifier Option set to the series' Sequence Identifier, over the
LLSVC(n) or NODEVC, respectively. A LLS or node MUST NOT respond to
an LLS_LLCAM sequence with an LLS_NAK message.
A LLS or node may solicit the current Logical Link Configuration
sequence by sending over its LLSVC(n) or NODEVC a LLS_QUERY message
containing no options. The LLS(HIGHER) will reply to this by
sending its currently stored LLCAM messages over the VC on which it
received the query. The LLS(n) or node MUST NOT perform any time-
outs for replies to this LLS_QUERY. If the LLS_QUERY is lost, the
lack of a LLS_ACK response will cause the LLS(HIGHER) to eventually
retransmit the entire LLS_LLCAM sequence.
The LLS MUST then perform the additional processing described in
9.1.3. Disseminating LLS Configuration Advertisements.
The node MUST then perform the additional processing described in
10.2. Handling LLS Configuration Advertisements.
9. Logical Link Server Operation
A Logical Link Server is primarily a multicast packet relay. An
LLS takes multicast data packets received on one VC and sends them
back out on another. The selection of the transmit side VC is
determined by the VC on which the data is received and the
destination address of the received packet.
To make the decisions on how to relay packets, a LLS must maintain
some state relating to all its currently connected VCs. This state
is entirely per-VC state used to identify the entity or entities at
the other end of the connection, not a database which can be
draft-ietf-ion-ipv6atm-framework-00.txt [page 40]
INTERNET-DRAFT A Framework for IPv6 Over ATM June 1996
queried, or information not pertaining to any directly connected
entity.
9.1. LLS Operation
The following subsections describe the operation of a LLS in
detail. These procedures are the same for all Logical Link Servers
in the tree unless noted otherwise.
The first two subsections describe how LLSs make and receive calls
to and from other entities. To allow the tree to operate if there
are many failed LLSs or if there is a major network malfunction, a
LLS is not restricted to connect to only LLS servers operating at
the level directly above it in the tree. A LLS SHOULD skip as many
levels in the tree as necessary to ``skip over'' levels which have
suffered multiple failures. The goal is that the tree should be
able to ``heal''around all but the most catastrophic failures.
Implicit in this is a way to restore the tree to its ``normal''
configuration as failures are repaired and failed resources become
available.
By allowing the tree to self ``heal'', it is possible that a LLS at
any level in the tree could end up serving both other LLSs and
nodes. Since both the node a LLS client side operations are
identical a LLS does not need to treat client LLSs and nodes
differently. Thus, any LLS can server any mixture of clients if
necessary without requiring any special operations.
9.1.1. Connecting to Higher Level LLS
An LLS(n) connects to the Logical Link by first connecting to a
LLS(HIGHER), as described in 8.1. Common Logical Link Connection
Processing. Once the LLS(n) has successfully connected to and
validated the LLS(HIGHER), the LLS(n) MUST perform the additional
processing described in this section.
Once connected to an higher level LLS, an LLS(n) MUST NOT send any
LLS_JOIN messages to the LLS(HIGHER) until it receives the first
valid connection to its LLSLNSAP(n). If an LLS(n) already has
connections on its LLSLNSAP(n) at the time it connects to the
LLS(HIGHER), it MUST send an LLS_JOIN message to join the
promiscuous multicast group on the LLS(HIGHER).
When an LLS(n) connects to an LLS(HIGHER), the LLS(n) functions as
a client that joins the promiscuous multicast group. This will
cause a |