One document matched: draft-armitage-ipatm-ipmc-02.txt
Differences from draft-armitage-ipatm-ipmc-01.txt
Internet-Draft Grenville Armitage
Bellcore
November 3rd, 1994
IP Multicast over UNI 3.0 based ATM Networks.
<draft-armitage-ipatm-ipmc-02.txt>
Status of this Memo
This document was submitted to the IETF IP over ATM WG. Publication
of this document does not imply acceptance by the IP over ATM WG of
any ideas expressed within. Comments should be submitted to the ip-
atm@matmos.hpl.hp.com mailing list.
Distribution of this memo is unlimited.
This memo is an internet draft. Internet Drafts are working documents
of the Internet Engineering Task Force (IETF), its Areas, and its
Working Groups. Note that other groups may also distribute working
documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress". Please check the lid-abstracts.txt
listing contained in the internet-drafts shadow directories on
nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.src.com, or
munnari.oz.au to learn the current status of any Internet Draft.
Abstract
This memo describes extensions to RFC1577 (Classical IP over ATM) and
RFC1112 (Host Extensions for IP Multicasting) to allow present
generation IP multicasting on ATM networks that support Version 3.0
of the ATM Forum's UNI signalling specification.
1. Overview
RFC 1112 [1] introduces the concept of IP multicasting and defines
the required behaviour of hosts desiring to send to, or receive from,
IP multicast groups. The example link layer technology given in that
RFC is Ethernet, a technology that directly supports multicasting.
ATM is a new link layer technology being utilised to support IP
Armitage Expires May 3rd, 1995 [Page 1]
Internet Draft November 3rd, 1994
subnets. RFC 1483 [2] defines a mechanism for encapsulating and
transmitting IP packets using AAL5 over ATM Virtual Channels (VCs).
RFC 1577 [3] defines the basic 'Classical' model of IP subnets mapped
to restricted groups of ATM-connected nodes - the Logical IP Subnet
(LIS).
The currently published signalling specification from the ATM Forum
is Version 3.0 [4] (UNI 3.0). In addition to the Bidirectional
Unicast VCs used to provide the basic Classical model, UNI 3.0 also
provides support for Unidirectional, Point to Multipoint VCs. This
memo will describe how IP multicasting within a LIS may be achieved
using meshes of UNI 3.0 point to multipoint VCs. It will also
describe how IP multicast routers may extend IP multicast beyond the
LIS.
The ARP Server's role in the LIS is extended to keep track of IP
multicast groups that are active within the LIS. New ATMARP message
types are proposed, to support the distribution of IP group
membership information. A multicast-server architecture is used to
distribute the new ATMARP messages within the LIS. Each multicast
host establishes a VC to the ARP Server, and the ARP Server
establishes a multicast VC back to all multicast hosts in the LIS.
Section 2 provides an overview of IP multicast and what RFC 1112
required from Ethernet. Section 3 outlines the IP/ATM interface model
that is assumed in this draft, while section 4 describes a set of
generic functions that should be available to clients of a local
host's UNI 3.0 signalling service. The basic behaviour for the
sending side of an IP/ATM interface is described in section 5, with
section 6 covering the mechanism whereby a host joins and leaves an
IP multicast group. Sections 7 and 8 cover the way in which hosts
respond to dynamic group membership changes. Support for IP multicast
routers is described in section 9, and section 10 explains the
features included to improve the reliability of the membership
management mechanisms.
This memo assumes an understanding of concepts explained in greater
detail in RFC 1112, RFC 1577, UNI 3.0, and <draft-ietf-ipatm-sig-
02.txt>.
2. Review of RFC 1112 and IP Multicast over Ethernet.
In RFC 1112 the behaviour of the transmit and receive sides are quite
independent. This makes the concept of being a 'member' of an IP
multicast group imprecise at the link layer interface.
The interface must support the transmission of IP packets to an IP
Armitage Expires May 3rd, 1995 [Page 2]
Internet Draft November 3rd, 1994
multicast group address, whether or not the node considers itself a
'member' of that group. Consequently, group membership is effectively
irrelevant to the transmit side of the link layer interfaces. No
address resolution is required to transmit packets - an algorithmic
mapping from IP multicast address to Ethernet multicast address is
performed locally before the packet is sent out the local interface
in the same 'send and forget' manner as a unicast IP packet.
Joining and Leaving an IP multicast group is more explicit on the
receive side - with the primitives JoinLocalGroup and LeaveLocalGroup
affecting what groups the local link layer interface should accept
packets from. When the IP layer wants to receive packets from a
group, it issues JoinLocalGroup. When it no longer wants to receive
packets, it issues LeaveLocalGroup.
The role of IGMP in RFC 1112 is to support IP multicast routers
attached to a given subnet. Hosts issue IGMP Report messages when
they perform a JoinLocalGroup, or in response to an IP multicast
router sending an IGMP Query. The sole function is to allow routers
to identify what IP multicast groups have non-zero membership on the
subnet.
A specific IP multicast address, 224.0.0.1, is allocated for the
transmission of IGMP Query messages. All IP multicast hosts must
issue JoinLocalGroup for 224.0.0.1 during their initialisation. Each
host keeps a list of IP multicast groups it has been JoinLocalGroup'd
to. When a router issues an IGMP Query on 224.0.0.1 each host begins
to send IGMP Reports for each group it is a member of. IGMP Reports
are sent to the group address, not 224.0.0.1, "so that other members
of the same group on the same network can overhear the Report" and
not bother sending one of their own.
Under RFC 1112 multicast IP routers are expected to passively receive
packets on all groups. IP multicast routers conclude that a group no
longer has members on the subnet when IGMP Queries no longer elict
replies for a group.
3. Model of an IP over ATM endpoint.
LLC/SNAP encapsulated IP packets are the default specified by RFC
1577. This model implies that IP over ATM endpoints should be viewed
as having LLC entities terminating VCs on behalf of higher layer
protocols (e.g. IP or ARP). The LLC entity encapsulates/multiplexes
outgoing packets according to RFC 1483, and demultiplexes incoming
packets. It is a client of the endpoint's AAL and UNI 3.0 signalling
services. Only VCs directed at ISO 8802/2 Layer 2 endpoints are
terminated on the LLC entity.
Armitage Expires May 3rd, 1995 [Page 3]
Internet Draft November 3rd, 1994
ipatm0
| |
--------- | arp
| | |
..............................
. This draft's functionality .
..............................
| | |
IP.1 IP.2 |
| | |
+++++.......+++++........+++++ ----
LLC +L.1+ +L.2+ +L.3+ ====>| U |
+++++.......+++++........+++++ | N |
AAL to AAL-User | | | | I |
interface VC.1 VC.2 VC.3 | |
| | | | 3 |
+++++.......+++++........+++++ | . |
AAL +A5 + +A5 + +A5 + <====| 0 |
+++++.......+++++........+++++ ----
| | |
--------- | ---------
\ | /
atm
Figure 1.
A unicast host's IP interface may have multiple VCs open to different
destinations. Each VC is mapped through separate instances of the
LLC layer and AAL5 service. Figure 1 attempts to show this
relationship, where IP.{1,2} are the IP addresses of destinations
that the local interface is connected to through VC.{1,2}. In a
unicast-only LIS these IP addresses map to a single endpoint, and the
VCs allow bidirectional flow of IP packets. The ARP entity is also
shown in Figure 1, with a VC to the ARP Server for the LIS. This VC
is not associated with an IP address, although the ARP client exists
within and below the IP layer.
The goal of this memo is to add multicast support to the model shown
in Figure 1 that closely resembles the spirit of RFC 1112. References
to 'transmit' and 'receive' sides refer to sections of the LLC and IP
interface that handle outgoing and incoming packets respectively.
In the abscence of explicit text to the contrary a few key phrases
are used in the following manner within this document:
"...the ARP Server..."
This refers to the actual ARP entity that acts as a centralised
cache of address mappings for an RFC 1577 LIS. This entity is a
Armitage Expires May 3rd, 1995 [Page 4]
Internet Draft November 3rd, 1994
local client of the LLC entity on an arbitrary node addressable
at the ATM level by members of the LIS. The node supporting the
ARP Server entity may or may not have a co-resident entities
supporting IP or other protocols.
"...a VC to the ARP Server..."
This actually denotes a VC established to the LLC entity of the
node on which the ARP Server entity exists. As the default is
to establish VCs to carry LLC/SNAP encapsulated traffic, the VC
may then carry packets of a range of protocols.
4. Multicast VCs under UNI 3.0.
This memo will describe its operation in terms of 'generic' functions
that should be available to clients of a UNI 3.0 signalling entity in
a given ATM endpoint.
The most fundamental limitations of UNI 3.0's multicast support are:
Only point to multipoint, unidirectional VCs may be established.
Only the root node of a given VC may add or remove leaf nodes.
Within these constraints, multicast group members can communicate by
the use of full meshes, or a Multicast Server. With a mesh each
transmitting host is the Root of an ATM multicast tree that has every
other host in the group as a Leaf. The Multicast Server model has
every group member establish a point to point VC to the Server. The
Server then receives packets from members and retransmits copies to
all other members.
This memo utilises both models. All IP multicast groups are supported
by meshes of point to multipoint VCs. For LIS members that register
as multicast IP hosts the ARP Server behaves as a 'multicast server'
for ARP traffic, in addition to its conventional use of unicast VCs
in accordance with RFC1577.
The following generic signalling functions are presumed to be
available to AAL Users: [mneumonics TBD]
L_CALL_RQ - Establish a unicast VC to a specific endpoint.
L_MULTI_RQ - Establish multicast VC to a specific endpoint.
L_MULTI_ADD - Add new leaf node to previously established VC.
L_MULTI_DROP - Remove specific leaf node from established VC.
L_RELEASE - Release unicast VC, or all Leaves of a multicast VC.
Armitage Expires May 3rd, 1995 [Page 5]
Internet Draft November 3rd, 1994
The UNI 3.0 signalling exchanges that occur as a consequence of these
functions are described in Appendix A. The local information passed
between AAL User and UNI 3.0 signalling entity with these functions
is currently beyond the scope of this memo.
The following indications are assumed to be available to AAL Users,
generated by by the local UNI 3.0 signalling entity:
L_ACK - Succesful completion of a request to signalling
entity.
L_REMOTE_CALL - A new VC has been established to the AAL User.
ERR_L_RQFAILED - A remote ATM endpoint rejected an L_CALL_RQ,
L_MULTI_RQ, or L_MULTI_ADD.
ERR_L_RELEASE - A remote ATM endpoint has elected to terminate a
pre-existing VC.
The UNI 3.0 signalling exchanges that occur to cause these
indications are described in Appendix A. The local information passed
between UNI 3.0 signalling entity and AAL User by these indications
is currently beyond the scope of this memo.
UNI 3.0 defines two ATM address formats - E.164 and ISO NSAP. UNI 3.0
defines an 'ATM Number' to identify an ATM endpoint using either
format. Some public networks may only understand E.164 formatted
addresses, so the ISO NSAP formatted address is included as an
additional 'ATM Subaddress'. For the rest of this memo the term 'ATM
Address' will be used to mean either a single 'ATM Number' or an 'ATM
Number' combined with an 'ATM Subaddress'.
5. Transmitting IP packets to Multicast groups.
The IP layer must be able to send a packet to an IP multicast group
at any time, without prior warning. This implies a mechanism for
keeping track of group membership (because unlike Ethernet multicast
the ATM source must 'know' its destinations before a VC can be
established for transmissions).
The RFC 1577 ARP Server is an ideal candidate for extension to
provide this mechanism. It keeps a table of {IP,ATM} address pairs
for all IP endpoints in the LIS (hosts, or routers with other
interfaces outside the LIS). It can either be configured with
certain table entries, or 'learn' entries from the ARPing activity of
hosts on the LIS. The extension for multicast is as follows:
Table entries for Class D IP addresses MUST contain space for 1 or
Armitage Expires May 3rd, 1995 [Page 6]
Internet Draft November 3rd, 1994
more ATM addresses, i.e. {IP, ATM.1, ATM.2, .... ATM.n}
A new ARP message type is added - ARP_MULTI. This is based on
ARP_REPLY but includes new fields to allow one or more ATM
addresses to be returned in a single reply.
The ARP_MULTI message MUST be sent back to the requesting host on a
previously established unicast VC between the host and the ARP
Server.
5.1 Retrieving Group Membership from the ARP Server.
When a host is required to transmit a packet to a Class D address it
issues an ARP_REQUEST to the ARP Server in exactly the same manner as
for a unicast packet.
If the ARP Server had no mapping for the desired Class D address an
ARP_NAK will be returned. In this case the IP packet MUST be
discarded silently. If a match is found in the ARP Server's tables it
proceeds to return addresses ATM.1 through ATM.n in a sequence of one
or more ARP_MULTIs. A simplistic mechanism is used to detect and
recover from loss of ARP_MULTI messages.
Each ARP_MULTI carries a new boolean field x, and a 15 bit integer
field y - expressed as ARP_MULTI(x,y). Field y acts as a sequence
number, starting at 1 and incrementing for each ARP_MULTI sent.
Field x acts as an 'end of reply' marker. When x == 1 the ARP
procedure is considered complete.
In addition, each ARP_MULTI may carry multiple ATM addresses from the
set {ATM.1, ATM.2, .... ATM.n}. An ARP Server MUST minimise the
number of ARP_MULTIs transmitted by placing as many group member's
addresses in a single ARP_MULTI as possible. The limit on ARP_MULTI
message length MUST be the MTU of the underlying VC.
Assume n ATM addresses must be returned, each ARP_MULTI is limited to
only p ATM addresses, and p << n. This would require a sequence of k
ARP_MULTI messages (where k = (n/p)+1, using integer arithmetic),
transmitted as follows:
ARP_MULTI(0,1) carries back {ATM.1 ... ATM.p}
ARP_MULTI(0,2) carries back {ATM.(p+1) ... ATM.(2p)}
[.......]
ARP_MULTI(1,k) carries back { ... ATM.n}
If k == 1 then only ARP_MULTI(1,1) is sent.
Typical failure mode will be losing one or more of ARP_MULTI(0,1)
Armitage Expires May 3rd, 1995 [Page 7]
Internet Draft November 3rd, 1994
through ARP_MULTI(0,k-1). This is detected when y jumps by more than
one between consecutive ARP_MULTI's. An alternative failure mode is
losing ARP_MULTI(1,k). A timer MUST be implemented to flag the
failure of the last ARP_MULTI to arrive. [timer value TBD].
If a 'sequence jump' is detected, the host MUST wait for the
ARP_MULTI(1,k), discard all results, and repeat the ARP REQUEST.
If a timeout occurs, the host MUST discard all results, and repeat
the ARP_REQUEST.
Where n < p, k = 1, only one ARP_MULTI is ever sent in response to an
ARP_REQUEST. This removes the possibility of cell loss causing
undetected loss of a group member's address.
5.2 Format of the ARP_MULTI message.
The ATM ARP_MULTI message is based on the ARP_REPLY message,
indicated by an 'operation type value' of 11 (decimal). The message
format is:
Data:
ar$hrd 16 bits Hardware type
ar$pro 16 bits Protocol type
ar$shtl 8 bits Type & length of source ATM number (q)
ar$sstl 8 bits Type & length of source ATM subaddress (r)
ar$op 16 bits Operation code (request, reply, or NAK)
ar$spln 8 bits Length of source protocol address (s)
ar$thtl 8 bits Type & length of target ATM number (x)
ar$tstl 8 bits Type & length of target ATM subaddress (y)
ar$tpln 8 bits Length of target protocol address (z)
ar$tnum 16 bits Number of target ATM addresses returned (N).
ar$seqxy 16 bits Boolean flag x and sequence number y.
ar$assn 32 bits ARP Server Sequence Number.
ar$sha qoctets source ATM number
ar$ssa roctets source ATM subaddress
ar$spa soctets source protocol address
ar$tha.1 xoctets target ATM number 1
ar$tsa.1 yoctets target ATM subaddress 1
ar$tpa zoctets target protocol address
ar$tha.2 xoctets target ATM number 2
ar$tsa.2 yoctets target ATM subaddress 2
[.......]
ar$tha.N xoctets target ATM number N
ar$tsa.N yoctets target ATM subaddress N
ar$seqxy is coded with flag x in the leading bit, and sequence number
y coded as an unsigned integer in the remaining 15 bits.
Armitage Expires May 3rd, 1995 [Page 8]
Internet Draft November 3rd, 1994
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x| y |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ar$tnum is an unsigned integer indicating how many pairs of
{ar$tha,ar$tsa} (i.e. how many group member's ATM addresses) are
present in the message. Section 6.6 of RFC 1577 should be consulted
for specific details and coding of all other fields. ar$assn is an
unsigned 32 bit number filled in by the ARP Server before
transmitting each ARP_MULTI. Its use is described further in section
10.
As an example, assume we have a LIS using 4 byte protocol addresses,
20 byte ATM numbers, and 0 byte ATM subaddresses. For n group members
in a single ARP_MULTI we require a (44 + 20n) byte message. If we
assume the default MTU of 9180 bytes, we can return a maximum of 456
group member's addresses in a single ARP_MULTI.
5.3 Establishing the Multicast VC.
An L_MULTI_RQ is then issued for ATM.n, followed by an L_MULTI_ADD
for every member of the set {ATM.1, ....ATM.(n-1)} (assuming the set
is non-null). The packet is then transmitted over the newly created
VC just as it would be for a unicast VC.
After transmitting the packet the local interface holds the VC open
and marks it as the active path out of the host for any subsequent IP
packets being sent to that Class D address.
When establishing a new multicast VC is is possible that one or more
ostensible group members may reject an L_MULTI_RQ or L_MULTI_ADD. If
this occurs then the ATM address of the node responsible is dropped
from the set {ATM.1, ATM.2, .... ATM.n} returned by the ARP Server,
and the creation of the multicast VC continues. [Further action? TBD]
5.4 Managing the Multicast VC.
Multicast VCs have the potential to be expensive in their use of
resources. Therefore each VC MUST have a configurable inactivity
timer associated with it. If the timer expires, an L_RELEASE is
issued for that VC, and the Class D address is no longer considered
to have an active path out of the local host. Choice of timer period
is beyond the scope of this memo.
During the life of a multicast VC an ERR_L_RELEASE may be received
indicating that a leaf node has terminated its participation at the
Armitage Expires May 3rd, 1995 [Page 9]
Internet Draft November 3rd, 1994
ATM level. The ATM endpoint associated with the ERR_L_RELEASE MUST be
removed from the locally held set {ATM.1, ATM.2, .... ATM.n}
associated with the VC.
Section 7 describes what happens if group membership changes while
the VC is open. Section 10 describes the mechanism for ensuring hosts
remain up to date with changes that occur while the VC is open.
6. Joining an IP Multicast Group to Receive packets.
A host is a 'group member', in the sense that a member receives
packets directed at the group, when its ATM address appears in the
ARP Server's table entry for the group's IP address. A key function
within the LIS is the distribution of group membership information to
the ARP Server and multicast capable hosts in the LIS.
The ARP Server's links to multicast hosts in the LIS differs from its
links to unicast hosts. The ARP Server maintains an outgoing, one-
to-many multicast VC, with each multicast host as a leaf node. Two
new ATMARP messages are defined: ARP_MCJOIN and ARP_MCLEAVE. These
are sent to the ARP Server by hosts joining or leaving a group, and
the ARP Server propagates them to other hosts to ensure the knowledge
is distributed in a timely fashion.
RFC1112 expects that routers are capable of behaving 'promiscuously'.
This functionality may achieved by allowing routers to register with
the ARP Server to be returned as 'wild card' members of all Class D
addresses. However, a problem inherent in the current ATM model is
that such behaviour may be wasteful of reassembly resources on the
router's ATM interface. This draft proposes a generalisation to the
notion of 'wild card' entries, enabling routers to limit themselves
to 'blocks' of the Class D address space. The application of this
facility is described in greater detail in Section 9.
A block can be as small as 1 (a single group) or as large as the
entire Class D address space (default 'promiscuous' behaviour).
The key extensions required to manage the ARP Server table entries
are:
Two new ATMARP message types are defined:
ARP_MCJOIN carries a Class D IP address and 32 bit mask (to
specify a contiguous block of groups being joined) and a
unicast ATM address (of the node joining).
ARP_MCLEAVE carries a Class D IP address and 32 bit mask (to
specify a contiguous set of groups being left) and a unicast
Armitage Expires May 3rd, 1995 [Page 10]
Internet Draft November 3rd, 1994
ATM address (of the node leaving).
JoinLocalGroup results in two messages being transmitted:
ARP_MCJOIN, sent over a VC to the ARP Server. It identifyies
the IP group being joined, a mask indicating a single group is
being joined, and the hosts ATM address.
An IGMP Report, except for 224.0.0.1 (in accordance with
RFC1112).
LeaveLocalGroup now results in an ARP_MCLEAVE being sent over a VC
to the ARP Server, identifying the IP group being left, and the
host's ATM address.
IP endpoints with special requirements (e.g. IP multicast routers)
may directly issue ARP_MCJOINs and ARP_MCLEAVEs specifying groups
of Class D addresses. No IGMP Report is issued for such
operations.
When an ARP_MCJOIN is received by the ARP Server it adds the
specified ATM address to the ARP entry for the specified Class D
address(es).
When an ARP_MCLEAVE is received by the ARP Server it removes the
specified ATM address from the ARP entry for the specified Class D
address(es).
The ARP Server maintains a single Point to Multipoint VC out to
every IP multicast host. When they join group 224.0.0.1 they are
added as a leaf, when they leave group 224.0.0.1 they are dropped.
ARP_MCJOIN and ARP_MCLEAVE messages arriving from individual hosts
are processed locally by the ARP Server AND retransmitted on the
Point to Multipoint VC to all multicast hosts.
All host ARP entities ignore ARP_MCJOINN or ARP_MCLEAVE messages
that simply confirm information already held by the entity. The
ARP Server retransmits redundant messages, but otherwise takes no
action.
6.1 Format of the ARP_MCJOIN and ARP_MCLEAVE Messages.
The ATM ARP_MCJOIN message is a variation on the ARP_REPLY message,
indicated by an 'operation type value' of 12 (decimal). ARP_MCLEAVE
has the same format and operation type value of 13 (decimal). The
message format is:
Armitage Expires May 3rd, 1995 [Page 11]
Internet Draft November 3rd, 1994
Data:
ar$hrd 16 bits Hardware type
ar$pro 16 bits Protocol type
ar$shtl 8 bits Type & length of source ATM number (q)
ar$sstl 8 bits Type & length of source ATM subaddress (r)
ar$op 16 bits Operation code ( = 12 or 13, JOIN or LEAVE)
ar$spln 8 bits Length of source protocol address (s)
ar$tpln 8 bits Length of multicast group address (z)
ar$assn 32 bits ARP Server Sequence Number.
ar$sha qoctets source ATM number (E.164 or ATM Forum NSAPA).
ar$ssa roctets source ATM subaddress (ATM Forum NSAPA).
ar$spa soctets source protocol address
ar$gpa zoctets multicast group address.
ar$mask zoctets multicast group mask.
Refer to RFC 1577, section 6.6 for the coding of the ar$shtl and
ar$sstl fields. For conventional IPv4 environments ar$spln and
ar$tpln are both set to 4. Note that the message format differs from
ARP_REPLY in the fields after ar$op. ar$assn is an unsigned 32 bit
number filled in by the ARP Server before re-transmitting an
ARP_MCJOIN or ARP_MCLEAVE. The originating host SHOULD set it to
zero, although it will be ignored by the ARP Server. Its use is
described further in section 10.
6.1.1 Construction of the Class D address and Mask.
The field ar$gpa specifies a base address of a block containing one
or more Class D addresses. Class D addresses are in the range
224.0.0.0 to The high-order four bits of ar$gpa MUST be set to
"1110".
No bit in ar$gpa may be set to 1 if the corresponding bit in ar$mask
is set to 0. The high-order four bits in ar$mask MUST be set to
"1111".
A 'block' is the set of IP addresses that conform to the following
equation:
(IP address) AND (ar$mask) == (ar$gpa)
Some examples:
ar$gpa = 224.0.0.32 and ar$mask = 255.255.255.224
refers to the block between 224.0.0.32 and 224.0.0.63.
ar$gpa = 224.0.0.0 and ar$mask = 255.255.255.224
refers to the block between 224.0.0.0 and 224.0.0.31.
Armitage Expires May 3rd, 1995 [Page 12]
Internet Draft November 3rd, 1994
ar$gpa = 224.0.20.0 and ar$mask = 255.255.252.0
refers to the block between 224.0.20.0 and 224.0.23.255.
6.1.2 Important Default Values.
JoinLocalGroup and LeaveLocalGroup MUST specify a mask value of
255.255.255.255. An ARP_MCJOIN with the following field values refers
to a single Class D address X:
ar$gpa = X and ar$mask = 255.255.255.255
A router choosing to behave strictly in accordance with RFC1112 MUST
specify a mask value of 240.0.0.0. The following field values
encompass the entire Class D space:
ar$gpa = 224.0.0.0 and ar$mask = 240.0.0.0
The use of alternative mask values is discussed in Section 9.
6.2 Registering with the ARP Server as a Multicast Host.
Unicast IP hosts exchange ARP traffic with the ARP Server over a
bidirectional unicast VC. Multicast IP hosts receive an additional
incoming VC from the ARP Server, which is used to receive group
membership updates. This VC is maintained by the ARP Server as a
point to multipoint undirectional VC, with each multicast host as a
leaf node.
In order for the ARP Server to maintain a list of multicast hosts on
the LIS there must be a mechanism for 'registering' hosts. A solution
is found in the requirements of RFC 1112. A multicast host must
explicitly issue a JoinLocalGroup for group 224.0.0.1 when it
initialises.
This act of joining group 224.0.0.1 is sufficient to register the
host with the ARP Server. The host's JoinLocalGroup to 224.0.0.1 will
result in an ARP_MCJOIN being transmitted from the host to the ARP
Server. The ARP Server monitors the membership of 224.0.0.1 and
ensures each listed member is added as a leaf to its outgoing
multicast VC.
6.3 Joining A General Group X.
Two things occur when a host joins an arbitrary group X by sending an
ARP_MCJOIN to the ARP Server. First the ARP Server updates its ARP
tables. Then it retransmits the ARP_MCJOIN message on the multicast
VC it has established out to other multicast IP hosts on the LIS.
This behaviour is used in section 7 to allow nodes that are already
Armitage Expires May 3rd, 1995 [Page 13]
Internet Draft November 3rd, 1994
members of a given group to note the new member.
6.4 Redundant ATM_MCJOIN and ATM_MCLEAVE Messages.
Host and Router ARP entities MUST silently discard incoming
ATM_MCJOIN and ATM_MCLEAVE messages that appear redundant (e.g.
declaring a new host has left a group when that host is not listed as
being a member). The ARP Server MUST retransmit ATM_MCJOIN and
ATM_MCLEAVE messages even if they appear redundant.
7. Adding A New Leaf to Outgoing Multicast VC.
Just updating the ARP Server's tables does not account for hosts who
have already established multicast VCs for transmission to the
group's previous members. The solution to this problem is for every
host's ARP entity to inform the host's transmit side of ARP_MCJOIN
and ARP_MCLEAVE messages it receives. These messages will be received
from the ARP Server when other hosts change their group membership
status, as described in section 6.
If an ARP_MCJOIN is seen that refers to (or encompasses) an IP group
for which the transmit side already has a VC open, the new member's
ATM address is extracted and an L_MULTI_ADD issued locally. This
ensures that hosts already sending to a given group will immediately
add the new member to their list of recipients. It also ensures that
routers joining a 'block' of groups are added by all hosts sending to
groups within the block.
Section 10 deals with the possibility of lost ARP messages causing
hosts to miss membership additions.
8. Leaving an IP Multicast Group.
Leaving an IP multicast group involves removing the local hosts entry
from the ARP Server, and ensuring that hosts stop sending to the
leaving node. Both are the reverse of the 'join' operations described
in section 6 and 7.
The ARP Server's response:
LeaveLocalGroup results in ARP_MCLEAVE messages being sent to the
ARP Server. The ARP Server removes the specified ATM address from
the specified group(s) and retransmits the message to all other
multicast hosts.
If an IP multicast host issues a LeaveLocalGroup for 224.0.0.1 it
will also be considered to have ceased membership of all other
groups for which it may have joined. The ARP Server MUST flush
Armitage Expires May 3rd, 1995 [Page 14]
Internet Draft November 3rd, 1994
that hosts's ATM address from any Class D address entries it
appears in. Finally, the host is released as a Leaf node from the
ARP Server's outgoing multicast VC.
Response of an arbitrary host in the LIS:
If an ARP_MCLEAVE is seen that refers to (or encompasses) an IP
group for which the transmit side already has a VC open, the
leaving member's ATM address is extracted and an L_MULTI_DROP
issued locally. This ensures that hosts already sending to a given
group will immediately delete the leaving member from their list
of recipients (Leaf nodes).
If an ARP_MCLEAVE is seen that refers to group 224.0.0.1 then the
ATM address of the host originating the message MUST be removed
from every multicast VC on the local host that it may be a Leaf
of.
The transmit side of the interface MUST NOT shut down an active VC to
a group for which the receive side has just executed a
LeaveLocalGroup. This behaviour is consistent with the model of
hosts transmitting to groups regardless of their own membership
status.
RFC 1112 requires all active multicast IP hosts to be members of
224.0.0.1. Leaving this group seems a reasonable indication that a
given host has ceased support for IP multicasting.
Section 10 deals with the possibility of lost ARP messages causing
hosts to miss membership additions.
9. Beyond the LIS - Multicast IP Router behaviour.
Multicast routers are required for an IP multicast group to span more
than the local LIS. The multicast router may be a tunneling router,
or may have direct connection to another multicast-capable link
layer. Decisions by routers to receive packets from given multicast
groups will depend on algorithms or policies beyond the scope of this
memo (e.g. DVMRP [5]).
It is assumed that the IP multicast router will be implemented over
the same sort of IP-ATM interface that a multicast host's IP layer
would use. They will use the basic services described in the
preceeding sections to join and leave IP multicast groups as
necessary.
Armitage Expires May 3rd, 1995 [Page 15]
Internet Draft November 3rd, 1994
9.1 Sending to a Group.
If the router needs to transmit a packet to a group within the LIS it
opens a multicast VC in the same manner as a normal host would. Once
a VC is open, the router's ARP entity watches for ARP_MCJOIN and
ARP_MCLEAVE messages and responds to them as a normal host would.
The IP multicast router's transmit side MUST implement inactivity
timers to shut down idle outgoing VCs, as for normal hosts.
As with normal host, the router does not need to be a member of a
group it is sending to.
9.2 Promiscuously Joining Groups.
Once initialised, the simplest model of router operation is that it
issues an ARP_MCJOIN encompassing the entire Class D address space.
In effect it becomes 'promiscuous', as it will be a leaf node to all
present and future multicast VCs established on the LIS.
How a router chooses which groups to propagate outside the LIS is
beyond the scope of this memo.
Consistent with RFC 1112, IP multicast routers may retain the use of
IGMP Query and IGMP Report messages to ascertain group membership.
9.3 Forward Multicast Traffic Across the LIS.
Under some circumstances the LIS may simply be another hop between IP
subnets that have participants in a multicast group.
[LAN.1] ----- IPmcR.1 -- [LIS] -- IPmcR.2 ----- [LAN.2]
LAN.1 and LAN.2 are subnets (such as Ethernet) with attached hosts
that are members of group X.
IPmcR.1 and IPmcR.2 are multicast routers with interfaces to the LIS.
A traditional solution would be to treat the LIS as a unicast subnet,
and use tunneling routers. However, this would not allow hosts on the
LIS to participate in the cross-LIS traffic.
Assume IPmcR.1 is receiving packets promiscuously on its LAN.1
interface. Assume further it is configured to propagate multicast
traffic to all attached interfaces. In this case that means the LIS.
When a packet for group X arrives on its LAN.1 interface, IPmcR.1
simply sends the packet to group X on the LIS interface as a normal
Armitage Expires May 3rd, 1995 [Page 16]
Internet Draft November 3rd, 1994
host would (ARPing for group X, creating the VC, sending the packet).
Assuming IPmcR.2 initialised itself as a wild-card entry in the ARP
Server's tables, it will have been returned as a member of X, even if
no other nodes on the LIS were members. All packets for group X
received on its LIS interface may be retransmitted on LAN.2.
If IPmcR.1 is similarly initialised the reverse process will apply
for multicast traffic from LAN.2 to LAN.1, for any multicast group.
The benefit of this scenario is that other hosts directly attached to
the LIS may also join and leave group X at anytime.
9.4 Restricted 'promiscous' Operation.
Both Unicast and Multicast IP routers have a common problem. Each
will suffer from limitations on the number of reassembly engines
available at their ATM interfaces. For the unicast router this will
limit the number of destinations outside the RFC 1577 LIS that hosts
may be sending to at any one time. Each destination IP address
results in a new VC to the router (and because of the bidirectional
nature of a unicast VC, this consumes a segmentation engine too).
The problem is magnified in the multicast situation. Being
'promiscuous' in the RFC 1112 sense means that for every M hosts
sending to N groups, the router's ATM interface will have M*N
incoming reassembly engines tied up.
It is not hard to envisage situations where a number of multicast
groups are active within the LIS but are not required to be
propagated beyond the LIS itself. An example might be a distributed
simulation system specifically designed to use the high speed IP/ATM
environment. There may be no practical way its traffic could be
utilised on 'the other side' of the multicast router, yet under the
conventional scheme the router would have to be a leaf to each
participating host anyway.
As this problem occurs at the Link Layer, it is worth noting that
'scoping' mechanisms at the IP level are not a solution.
In this situation the LIS administrator might configure their
multicast routers to exclude sections of the Class D address space
when issuing ARP_MCJOIN(s).
Another scenario involves the product M*N exceeding the capacity of a
single router's interface (especially if the same interface must also
support a unicast IP router service).
A LIS administrator may choose to add a second node, to function as a
Armitage Expires May 3rd, 1995 [Page 17]
Internet Draft November 3rd, 1994
parallel IP multicast router to the same 'out of LIS' networks. Each
router would be configured to be 'promiscuous' over separate parts of
the Class D address space, thus sharing the load. This sharing would
be completely transparent to IP hosts within the LIS.
Restricted promiscuous mode does not break RFC 1112's use of IGMP
Report messages. If the router is configured to serve a given block
of Class D addresses, it will receive the IGMP Report. If the router
is not configured to support a given block, then the existence of an
IGMP Report for a group in that block is irrelevant to the router.
All routers are able to track membership changes through the
ARP_MCJOIN and ARP_MCLEAVE traffic anyway.
Mechanisms for establishing these modes of operation are beyond the
scope of this memo.
10. Robustness of interaction with the ARP Server.
Transient problems on the path between ARP clients and the ARP Server
may result in lost ARP messages. There are two problem scenarios that
are addressed in this document. The first is the loss of an
ARP_MCJOIN or ARP_MCLEAVE between the host originating the message
and the ARP Server itself. In this case the host is the only member
of the LIS that is aware of the change.
The second is with the ARP_MCJOIN and ARP_MCLEAVE messages re-
transmitted from the ARP Server. If a host currently sending to a
group misses an ARP_MCJOIN, the newly joined member misses out on
that host's traffic to the group. If a host currently sending to a
group misses an ARP_MCLEAVE, the host that left will continue to
receive packets unecessarily.
10.1 Ensuring the ARP Server hears you.
A simple algorithm solves the first problem. Simply retransmit
ARP_MCJOIN and ARP_MCLEAVE messages at regular intervals until you
receive a copy back again on the multicast VC from the ARP Server. At
this point the local host's ARP entity can be certain that at least
the ARP Server received it, and can signal successful completion of
the operation to the IP layer.
An appropriate interval is [TBD - 5 seconds?]. After [TBD - 30?]
retransmissions the attempt should be flagged locally as a failure.
10.2 The ARP Server Sequence Number.
In each ARP_MULTI, ARP_MCJOIN, and ARP_MCLEAVE there is a 32 bit
sequence number identified as ar$assn. The following extensions
Armitage Expires May 3rd, 1995 [Page 18]
Internet Draft November 3rd, 1994
govern its use:
The ARP Server keeps a central counter, ASSN, and increments it
each time a single ARP_MCJOIN or ARP_MCLEAVE results in a change
to the Class D address mapping table.
When the ARP Server receives an ARP_REQUEST for a Class D address,
the current value of ASSN is noted and copied into the as$assn
field of every ARP_MULTI sent in response.
After the ARP Server processes an ARP_MCJOIN or ARP_MCLEAVE
message it copies the new ASSN value into the ar$assn field of the
message before retransmitting it.
Every host's ARP entity keeps its own 32 bit Host Sequence Number
(HSN) to track the ARP Server's sequence number. Whenever an
ARP_MULTI, ARP_MCJOIN, or ARP_MCLEAVE is received the following
check is then performed on the ar$assn field of the new message:
Seq.diff = ar$assn - HSN
ar$assn -> HSN
{...process ARP message as appropriate...}
if ((Seq.diff != 1) && (Seq.diff != 0))
then {...revalidate group membership information...}
Revalidating group membership information involves re-executing an
ARP_REQUEST for every IP multicast group that the local host is
currently sending to.
The basic result is that the host attempts to keep locked in step
with membership changes noted by the ARP Server. If it ever detects
that a membership change occurred (in any group) without the local
host noticing, at re-validates the membership of all groups it
currently has multicast VCs open to.
One implication of this mechanism is that the ARP Server should
serialize its processing of 'simultaneous' ARP_REQUEST, ARP_MCJOIN
and ARP_MCLEAVE messages. Join and Leave operations should be queued
within the ARP Server along with ARP_REQUESTS, and not processed
until all the ARP_MULTIs of a preceeding ARP_REQUEST have been
transmitted.
The ARP Server is free to choose a value of ASSN. When a new host
starts up it should initialise HSN to zero. When the host sends the
ARP_MCJOIN for 224.0.0.1 the HSN will be correctly set when it
receives a copy of its ARP_MCJOIN from the ARP Server. If Seq.diff >
Armitage Expires May 3rd, 1995 [Page 19]
Internet Draft November 3rd, 1994
1 when the ARP_MCJOIN returns no action will be taken anyway, as the
host will not have any multicast VCs established at this point.
If a host notices a sequence number jump when establishing a new
group's VC it should not revalidate the membership of the group it
just established. The membership returned in the ARP_MULTIs that
carried the new ar$assn field should be considered already validated.
When more than one ARP_MULTI is sent in response to an ARP_REQUEST
the ar$assn field of consecutive ARP_MULTIs must be constant. If the
ar$assn field changes then all the messages MUST be discarded at the
completion of the response, and the ARP_REQUEST re-issued.
An ARP Server should be carefully designed to minimise the
possibility of the ASSN jumping unecessarily. Under normal operation
only hosts that are affected by transient link problems will miss
ar$assn updates and be forced to revalidate. If the ARP Server itself
glitches it will be innundated with ARP requests for a period as
every multicast host in the LIS attempts to revalidate.
10.3 Why a Gobal sequence number?
The ASSN is global in that it counts the number of ARP_MCJOIN or
ARP_MCLEAVE operations it has processed, without reference to
group(s) affected. This may be perceived as a limitation, because
there is no way for LIS hosts to isolate exactly which Class D group
they may have missed an update for. An alternative was to try and
provide a per-group sequence number.
Unfortunately per-group sequence numbers are not practical. The
current mechanism allows sequence information to be piggy-backed onto
ARP messages already in transit for other reasons. The ability to
specify blocks of Class D addresses with a single ARP_MCJOIN or
ARP_MCLEAVE means that a single message can refer to membership
change for multiple groups simultaneously. A single ar$assn field
cannot provide meaningful information about each group's sequence.
Multiple ar$assn fields would have been unwieldy.
11. Summary of Key Decisions.
The key decisions this memo proposes:
General IP multicast in the LIS is through mesh of Point to
Multipoint VCs rather than a central Multicast Server. The ARP
Server transparently establishes itself as a Multicast Server for
certain classes of ARP traffic from itself to multicast hosts on
the LIS.
Armitage Expires May 3rd, 1995 [Page 20]
Internet Draft November 3rd, 1994
ATM ARP Server role extended.
Class D IP addresses may be mapped to 0 or more ATM addresses.
New ARP message type, ARP_MULTI. ARP_REQUESTS issued for Class
D addresses may get 1 or more ARP_MULTI messages as the ARP
Server passes back all group member's ATM addresses.
New ARP message type, ARP_MCJOIN. Issued by LIS hosts to inform
the ARP Server they are now members of a group or block of
groups.
New ARP message type, ARP_MCLEAVE. Issued by LIS hosts to
inform the ARP Server they are no longer members of a group or
block of groups.
Specific interpretation of 224.0.0.1 membership to register LIS
hosts and support a 'multicast server' architecture for certain
types of ARP traffic.
'wild card' ARP table entries possible, where a single ATM
address is simultaneously associated with blocks of Class D
addresses.
ATM endpoint model.
Attempted decoupling of IP-ATM interface, local UNI 3.0
signalling service, and local ATM/AAL service descriptions.
Explicitly identifies an LLC 'entity' that terminates or
originates VCs for RFC 1483 compliant LLC/SNAP encapsulated
traffic.
12. Open Issues.
Some issues have not been addressed, although they may be in future
revisions.
ARP Server has no mechanism for realising group members have
silently died. [This probably should be attended to as a
priority].
Using a mesh of point to multipoint VCs to connect group members
places a high load on both the switch and the ATM reassembly
engines of each host receiving group transmissions. When an IP
host joins a group, every host transmitting to that group adds it
as a new leaf. This results in a new incoming VC and reassembly
instance at the receiver for every VC it has become a leaf to. If
Armitage Expires May 3rd, 1995 [Page 21]
Internet Draft November 3rd, 1994
an IP host joins multiple groups the situation is exacerbated.
Implementations might consider reusing VCs if a destination ATM
node's IP interface is a member of multiple groups.
No attempt is made to utilise indications from the ATM layer that
remote nodes have either added the local node as a leaf, or
dropped themselves from a VC originating at the local node.
The future development of ATM Group Addresses and Leaf Initiated
Join to ATM Forum's UNI specification has not been addressed. The
problems identified in this memo with respect to VC scarcity and
impact on receive side reassembly engines will not be fixed by
such developments in the signalling protocol.
Security Consideration
Security consideration are not addressed in this memo.
Acknowledgments
The discussions within the IP over ATM Working Group have helped
clarify the ideas expressed in this document. John Moy of Cascade
Communications Corp. initially suggested the idea of wild-card
entries in the ARP Server. Drew Perkins of Fore Systems provided
rigorous and useful critique of early proposed mechanisms for
distributing and validating group membership information.
Author's Address
Grenville Armitage
MRE 2P340, 445 South Street
Morristown, NJ, 07960-6438
USA
Email: gja@thumper.bellcore.com
References
[1] S. Deering, "Host Extensions for IP Multicasting", RFC 1112,
Standford University, August 1989.
[2] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaption
Layer 5", RFC 1483, USC/Information Science Institute, July 1993.
[3] Laubach, M., "Classical IP and ARP over ATM", RFC1577, Hewlett-
Packard Laboratories, December 1993
[4] ATM Forum, "ATM User-Network Interface Specification Version
Armitage Expires May 3rd, 1995 [Page 22]
Internet Draft November 3rd, 1994
3.0", Englewood Cliffs, NJ: Prentice Hall, September 1993
[5] D. Waitzman, C. Partridge, S. Deering, "Distance Vector Multicast
Routing Protocol", RFC 1075, November 1988.
[6] M. Perez, F. Liaw, D. Grossman, A. Mankin, E. Hoffman, A. Malis,
"ATM Signaling Support for IP over ATM", Internet Draft, IP over ATM
Working Group, draft-ietf-ipatm-sig-02.txt, August 14, 1994.
Armitage Expires May 3rd, 1995 [Page 23]
Internet Draft November 3rd, 1994
Appendix A. UNI 3.0 Multicast Support - A Brief Overview.
This section provides a general description of point-to-multipoint
signaling procedures. Readers are referred to [4] for details of UNI
3.0 signalling elements, and to [6] (or later versions) for
descriptions of ATM signalling for unicast services within the LIS.
In section 4 a list of 'generic' functions were suggested for the
interface between the ATM network and an AAL User (e.g. the LLC
entity) within each LIS host. The interaction between the LLC entity
and its clients (e.g. IP and ARP entities) is discussed in some
further detail in Appendix B.
It is vital to note that this document specifies the interface
between the LLC entity and higher layer protocols in a completely
indirect fashion. For example, where the text refers to the IP
entity issuing an L_MULTI_ADD, it is implicit that some local
mechanism is in place for the IP entity to cause the LLC entity to
issue an L_MULTI_ADD on its behalf.
A.1 The Unicast case - Originating action on a VC.
L_CALL_RQ is issued by the LLC entity to the local UNI 3.0 entity.
This initiates a signalling exchange between the local host's UNI 3.0
entity and the ATM network to establish a new VC. The L_CALL_RQ is
passed with sufficient information so that the initial SETUP message
can be constructed as outlined in [6]. If the signalling exchange is
successful an L_ACK is returned to the LLC entity
The signalling sequence may be represented as:
[AAL User] [UNI 3.0 entity] [The Network]
L_CALL_RQ ----->
SETUP ------> (stuff happens)
(optionally <------ CALL PROCEEDING)
<------ CONNECT
CONNECT ACK ------>
<----- L_ACK
(AAL User
now assumes
VC is active)
If the network rejects the call setup an ERR_L_RQFAILED is returned.
This sequence may be represented as:
[AAL User] [UNI 3.0 entity] [The Network]
Armitage Expires May 3rd, 1995 [Page 24]
Internet Draft November 3rd, 1994
L_CALL_RQ ----->
SETUP ------> (stuff happens)
<------ RELEASE COMPLETE
<----- ERR_L_RQFAILED
A more complex failure sequence (if the network first passed back a
CALL PROCEEDING) may be represented by:
[AAL User] [UNI 3.0 entity] [The Network]
L_CALL_RQ ----->
SETUP ------>
<------ CALL PROCEEDING
(stuff happens)
<------ RELEASE
RELEASE COMPLETE ------>
<----- ERR_L_RQFAILED
Both L_ACK and ERR_L_RQFAILED indications should carry enough
information to identify the local request being responded to.
L_RELEASE is similar to L_CALL_RQ except that it initiates a
signalling exchange to release the VC. Sufficient information is
passed so that the RELEASE message can be constructed appropriately.
The signalling sequence may be represented as:
[AAL User] [UNI 3.0 entity] [The Network]
L_RELEASE ----->
RELEASE ------> (stuff happens)
<------ RELEASE COMPLETE
It is implementation specific how the local host's UNI 3.0 entity
associates the VC terminating in the underlying AAL service with the
AAL User that issued the L_CALL_RQ.
A.2 The Unicast case - Reacting to action on a VC.
The process of binding an AAL User to the general services of the AAL
and UNI 3.0 entity are implementation specific. However, the
interface between the UNI 3.0 entity and AAL Users should allow an
AAL User to request indication of remotely originated requests to
establish or tear down VCs.
L_REMOTE_CALL is issued to the AAL User when the UNI 3.0 entity has
accepted a remotely originated call on its behalf (based on
information provided by the AAL User during binding). The signalling
Armitage Expires May 3rd, 1995 [Page 25]
Internet Draft November 3rd, 1994
sequence may be represented as:
[AAL User] [UNI 3.0 entity] [The Network]
<------ SETUP
CONNECT ------>
<------ CONNECT ACK
<----- L_REMOTE_CALL
The L_REMOTE_CALL is expected to carry back sufficient locally
significant information for the AAL User to identify and utilise the
newly terminated VC.
An extended interface would also allow AAL Users to such as the LLC
entity to block VC establishment requests if necessary. We can
postulate the following signalling exchange:
[AAL User] [UNI 3.0 entity] [The Network]
<------ SETUP
CALL PROCEEDING ------>
<----- L_REMOTE_RQ
L_REMOTE_ACK ----->
CONNECT ------>
<------ CONNECT ACK
<----- L_REMOTE_CALL
In this scenario the UNI 3.0 entity informs the network that the
request is being processed, then passes information about the call
request to the appropriate AAL User in an L_REMOTE_RQ indication. If
the conditions are acceptable, an L_REMOTE_ACK is passed back,
allowing the UNI 3.0 entity to complete the acceptance procedure.
Finally the call is formally announced with L_REMOTE_CALL.
When the remote node terminates the VC, the AAL User receives an
appropriate ERR_L_RELEASE indication (the analog of L_REMOTE_CALL).
No mechanism is required to query the AAL User before releasing a VC.
The signalling sequence may be represented as:
[AAL User] [UNI 3.0 entity] [The Network]
<------ RELEASE
RELEASE COMPLETE ------>
<----- ERR_L_RELEASE
Armitage Expires May 3rd, 1995 [Page 26]
Internet Draft November 3rd, 1994
A.3 The Multicast case - Originating action on a VC.
A point to multipoint VC begins with a SETUP being issued to
establish a multicast call to a single destination - the first Leaf
node. However, the SETUP differs from that used in the unicast case.
An additional Endpoint reference Information Element (IE) is added,
and the Broadband Bearer Capability IE is set to indicate point to
multipoint instead of point to point. L_CALL_RQ's functionality is
provided by L_MULTI_RQ when first establishing the VC. The signalling
sequence may be represented as:
[AAL User] [UNI 3.0 entity] [The Network]
L_MULTI_RQ ----->
SETUP ------> (stuff happens)
(optionally <------ CALL PROCEEDING)
<------ CONNECT
CONNECT ACK ------>
<----- L_ACK
(AAL User
now assumes
VC is active)
The Endpoint IE is set to zero for this SETUP.
The node initiating the VC is the Root node. Adding new Leaf nodes
requires the UNI 3.0 entity to issue an ADD PARTY message, which is
initiated by the receipt of an L_MULTI_ADD from the AAL User.
Mechanisms to associate L_MULTI_ADDs with a given multicast VC are
implementation specific. The signalling sequence for successfully
adding a new Leaf node may be represented by:
[AAL User] [UNI 3.0 entity] [The Network]
L_MULTI_ADD ----->
ADD PARTY ------> (stuff happens)
<------ ADD PARTY ACK
<----- L_ACK
(AAL User
now assumes
new Leaf is
active)
The Endpoint IE is set to a non-zero value before transmission of the
ADD PARTY to uniquely identify the new Leaf node (section 5.4.8.1
[4]).
Dropping a Leaf node requires an DROP PARTY from the UNI 3.0 entity,
Armitage Expires May 3rd, 1995 [Page 27]
Internet Draft November 3rd, 1994
which is generated in response to an L_MULTI_DROP from the AAL User.
The signalling sequence for successfully dropping a Leaf node may be
represented by:
[AAL User] [UNI 3.0 entity] [The Network]
L_MULTI_DROP ----->
DROP PARTY ------> (stuff happens)
<------ DROP PARTY ACK
A.4 The Multicast case - Reacting to action on a VC.
From the Leaf node's perspective there is little difference between
reacting to a remotely originated unicast VC, and being made a Leaf
to a remotely originated multicast VC. The main difference will be
the lack of return bandwidth to the Root node, so the UNI 3.0 entity
will need some local mechanism to indicate to the AAL User that it
cannot return traffic to the remote AAL User on this VC.
If the L_REMOTE_RQ and L_REMOTE_CALL indications are capable of
carrying information specifying zero bandwidth in the Leaf to Root
direction, then the signalling sequences are as described in section
A.2.
A.5 Signalling Elements.
Information Element codings will be based completely on their unicast
counterparts described in [6], with only minimal variations as
required by section 5.6 [4].
Armitage Expires May 3rd, 1995 [Page 28]
Internet Draft November 3rd, 1994
Appendix B. Thoughts on the behaviour of ARP entities.
The ARP Server model contains a few pitfalls for the unwary, as it
marks a departure from the familiar 'peer client' model generally
used in environments such as Ethernet subnets. Some of the
consequences of following the RFC 1577 model, and extending it
further as described in this document, are gradually being clarified.
An additional source of difficulty lies in the implications of using
LLC/SNAP encapsulation to enable 'multiprotocol' traffic on AAL5 VCs.
The major issues may be summarised as follows:
The ARP Server is strictly nothing more than an ARP entity
attached to an LLC entity. Unlike the traditional case where an
ARP entity was always co-resident with an IP entity over the same
link layer interface, this can no longer be assumed. However, in
order to perform InARP according to RFC 1577, the ARP entity needs
to be assigned an IP address from the pool available to the LIS.
The signalling method described in [6] supports the identification
of the ATM endpoint, and a layer 2 endpoint within the ATM
endpoint. It does not allow the layer 2 client (a layer 3
endpoint) to be explicitly identified (although such a facility
does exist within UNI 3.0). However, RFC 1577 requires the ARP
Server entity to pre-emptively perform InARP on any new VCs that
are remotely originated to its underlying LLC entity. (In effect
the ARP Server entity makes an assumption that new VCs are
intended for carrying ARP traffic and were initiated by a remote
IP/ARP protocol stack.) This requires that the LLC/LLC-client
interface supports the passage of indications to LLC clients when
a new VC 'arrives'.
The first issue is easily solved (just allocate an unused IP address
within the LIS), but requires clear understanding that the ARP
Server's apparent IP address does not imply the existence of a co-
resident IP stack.
The second issue is of interest to implementors of IP multicast
hosts. In addition to sending ARP_REQUESTs, the ARP entity in a
multicast LIS hosts will also be sending ARP_MCJOINs and ARP_MCLEAVEs
at various unrelated times. Implementations must be ready to respond
correctly to InARPs everytime they open or re-open a VC to the ARP
Server node during group membership changes. They must also be ready
to use any VC that is already open to the ARP Server's LLC entity
when possible.
The second issue may also cause problems in true multiprotocol
environments. Consider the ARP Server entity sharing an LLC entity
Armitage Expires May 3rd, 1995 [Page 29]
Internet Draft November 3rd, 1994
with a non-IP protocol stack. If a client of the non-IP protocol
stack initiates a VC to the LLC entity shared by the ARP Server
entity, it will receive InARP request(s) from the ARP Server entity.
The handling of this scenario is one for careful thought by ARP
Server implementors, as the InARP Request(s) will most likely go
unanswered.
Finally, all LIS hosts must be capable of sensibly terminating VCs
that are remotely originated and have zero reverse bandwidth. Without
this capacity they cannot become Leaf nodes to any multicast VCs. The
most important multicast VC in this document is the one from the ARP
Server's ARP entity out to all registered multicast hosts. Host
implementations must be careful not to mistake this VC from the ARP
Server as an open VC they can send ARP_REQUESTs, ARP_MCJOINs, or
ARP_MCLEAVEs on. When a multicast host is registered, its ARP entity
will send ARP messages over a normal unicast VC, and receive
ARP_MCJOIN and ARP_MCLEAVE messages over the multicast VC it is a
Leaf on.
ARP Server's should return ARP_MULTIs on the VC that the ARP_REQUEST
arrived on, even if the requesting host is already a registered
multicast host.
Armitage Expires May 3rd, 1995 [Page 30]
| PAFTECH AB 2003-2026 | 2026-04-23 17:17:54 |