One document matched: draft-armitage-ipatm-ipmc-00.txt
Internet-Draft Grenville Armitage
Bellcore
September 6th, 1994
IP Multicast over UNI 3.0 based ATM Networks.
<draft-armitage-ipatm-ipmc-00.txt>
Status of this Memo
This document was submitted to the IETF IP over ATM WG. Publication
of this document does not imply acceptance by the IP over ATM WG of
any ideas expressed within. Comments should be submitted to the ip-
atm@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 [1])
and RFC1112 (Host Extensions for IP Multicasting [2]) 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 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 February 6th, 1995 [Page 1]
Internet Draft September 6th, 1994
subnets. RFC 1483 [3] defines a mechanism for encapsulating and
transmitting IP packets using AAL5 over ATM Virtual Channels (VCs).
RFC 1577 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. The operation of the
Internet Group Management Protocol (IGMP) is modified, and a new IGMP
message type is proposed, to support the distribution of IP group
membership information. A multicast-server architecture is used to
distribute IGMP 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.
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 IP an
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
Armitage Expires February 6th, 1995 [Page 2]
Internet Draft September 6th, 1994
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 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 February 6th, 1995 [Page 3]
Internet Draft September 6th, 1994
ipatm0
/ | \
--------- | ---------
| | |
..............................
. This draft's functionality .
..............................
| | |
IP.1 IP.2 IP.3
| | |
+++++.......+++++........+++++ ----
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 single 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,3} are the IP addresses of destinations
that the local interface is connected to through VC.{1,2,3}. In a
unicast-only LIS these IP addresses map to a single endpoint, and the
VCs allow bidirectional flow of IP packets.
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.
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.
Armitage Expires February 6th, 1995 [Page 4]
Internet Draft September 6th, 1994
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. The ARP Server functions as a
'multicast server' for traffic on the 224.0.0.1 group, in a manner
transparent to the IP hosts on the LIS. All other IP multicast groups
are supported by meshes of point to multipoint VCs. This avoids the
need to implement a new node to function as a multicast server for
conventional multicast data traffic.
The following generic signalling functions are presumed to be
available to AAL Users: [mneumonics subject to change, they're "off
the top of my head"]
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.
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_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
Armitage Expires February 6th, 1995 [Page 5]
Internet Draft September 6th, 1994
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 source must 'know' its destinations before 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 should be extended to hold
1 or 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 two new fields.
Group address 224.0.0.1 is permanently configured as a special case
with only one member, the ARP Server itself.
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
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 31 bit integer
field y - expressed as ARP_MULTI(x,y). Field y acts as a sequence
Armitage Expires February 6th, 1995 [Page 6]
Internet Draft September 6th, 1994
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.
For a group with n members the following sequence would occur:
ARP_MULTI(0,1) carries back ATM.1
ARP_MULTI(0,2) carries back ATM.2
[.......]
ARP_MULTI(1,n) carries back ATM.n
If n == 1 then only ARP_MULTI(1,1) is sent.
Typical failure mode will be losing one or more of ARP_MULTI(0,1)
through ARP_MULTI(0,n-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,n). A timer MUST be implemented to flag the
failure of the last ARP_MULTI to arrive. [timer value to be decided].
If a 'sequence jump' is detected, the host MUST wait for the
ARP_MULTI(1,n), discard all results, and repeat the ARP REQUEST.
If a timeout occurs, the host MUST discard all results, and repeat
the ARP_REQUEST.
5.2 Format of the ARP_MULTI message.
The ATM ARP_MULTI message is based on the ARP_REPLY message, with an
additional 32 bit field to hold x and y. An ARP_MULTI is 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$seqxy 32 bits Boolean flag x and sequence number y.
ar$sha qoctets source ATM number
ar$ssa roctets source ATM subaddress
ar$spa soctets source protocol address
ar$tha xoctets target ATM number
ar$tsa yoctets target ATM subaddress
ar$tpa zoctets target protocol address
Armitage Expires February 6th, 1995 [Page 7]
Internet Draft September 6th, 1994
ar$seqxy is coded with flag x in the leading bit, and sequence number
y coded as an unsigned integer in the remaining 31 bits.
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x| y |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Section 6.6 of RFC 1577 should be consulted for specific details and
coding of all other fields.
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
necessary?]
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
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.
Special handling of packets transmitted to 224.0.0.1 is left up to
the ARP Server. ARP_REQUESTS for this group receive the ARP Server's
own ATM address in response, resulting in the ARPing host creating a
Armitage Expires February 6th, 1995 [Page 8]
Internet Draft September 6th, 1994
unidirectional VC to the ARP Server's IP layer. From the host's
perspective it is the root of a normal multicast VC, although it has
only one leaf. Section 6 describes how the ARP Server handles
224.0.0.1 and tracks current group membership.
Section 7 describes what happens if group membership changes 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. The 224.0.0.1
multicast group plays a key role in distributing information about
group membership to the ARP Server and multicast capable hosts in the
LIS. For this reason the 224.0.0.1 group is constructed differently.
The ARP Server takes an active role and establishes itself as a
multicast server for this group, rather than allowing the IP hosts to
construct a point to point mesh.
RFC1112 expects that routers are capable of behaving 'promiscuously'.
This is 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:
A new IGMP message type is defined called ATMMC, with two
subtypes:
ATMMC_JOIN 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).
ATMMC_LEAVE carries a Class D IP address and 32 bit mask (to
specify a contiguous set of groups being left) and a unicast
ATM address (of the node leaving).
IGMP ATMMC messages MUST be transmitted to address 224.0.0.1. The
Armitage Expires February 6th, 1995 [Page 9]
Internet Draft September 6th, 1994
mechanism described in RFC 1112 for redundant transmission of IGMP
Reports MUST be applied to IGMP ATMMC messages.
The ARP Server contains an IP layer, with an IGMP entity and
exception handling for packets received for group 224.0.0.1.
JoinLocalGroup allows only a single group to be joined at a time.
Two IGMP messages are transmitted:
IGMP Report, and
IGMP ATMMC_JOIN, identifying the IP group being joined, and the
hosts ATM address.
LeaveLocalGroup now results in an IGMP ATMMC_LEAVE being
transmitted, 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 IGMP ATMMC_JOINs and ATMMC_LEAVEs specifying
groups of Class D addresses. An IGMP Report cannot be issued for
such an operation.
When an IGMP ATMMC_JOIN is received by the ARP Server's IGMP
entity, it adds the specified ATM address to the ARP entry for the
specified Class D address(es). This includes ATMMC_JOINs for group
224.0.0.1, although these are never reported in response to
ARP_REQUESTs.
When an IGMP ATMMC_LEAVE is received by the ARP Server's IGMP
entity, it removes the specified ATM address(es) from the ARP
entry for the specified Class D address.
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.
Most IGMP messages arriving from individual hosts are processed
locally AND retransmitted on the Point to Multipoint VC.
ATMMC_JOINs for group 224.0.0.1 are NOT retransmitted by the ARP
Server's IGMP entity.
IGMP entities ignore ATMMC_JOIN or ATMMC_LEAVE messages that
simply confirm information already held by the entity.
Armitage Expires February 6th, 1995 [Page 10]
Internet Draft September 6th, 1994
6.1 Format of the IGMP ATMMC Messages.
IGMP messages are encapsulated in IP datagrams, with an IP protocol
number of 2.
IGMP messages start with the following 4 byte header:
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type | Subtype | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version = 1
The Type field values are:
1 = Host Membership Query. (Subtype is ignored).
2 = Host Membership Report. (Subtype is ignored).
3 = DVMRP [5]. (4 subtypes defined).
4 = ATMMC. (2 subtypes defined)
For ATMMC the Subtype field values shall be:
1 = JOIN.
2 = LEAVE.
The ATMMC message contents follow immediately after the IGMP header
in the IP packet. The format of ATMMC_JOIN and ATMMC_LEAVE are
exactly the same. It borrows fields from the ATM ARP packet format in
RFC 1577 to carry a single IP address, an IP address mask, an ATM
address, and (optionally) an ATM subaddress:
Data:
ar$shtl 8 bits Type & length of source ATM number (q).
ar$sstl 8 bits Type & length of source ATM subaddress (r).
ar$spa 32 bits Class D address of IP multicast group.
ar$mask 32 bits Mask defining block of Class D addresses.
ar$sha qoctets source ATM number (E.164 or ATM Forum NSAPA).
ar$ssa roctets source ATM subaddress (ATM Forum NSAPA).
Refer to RFC 1577, section 6.6 for the coding of the ar$shtl and
ar$sstl fields.
Armitage Expires February 6th, 1995 [Page 11]
Internet Draft September 6th, 1994
6.1.1 Construction of the Class D address and Mask.
The field ar$spa 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$spa MUST be set to
"1110".
No bit in ar$spa 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$spa)
Some examples:
ar$spa = 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$spa = 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.
ar$spa = 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 ATMMC_JOIN with the following field values refers
to a single Class D address X:
ar$spa = 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$spa = 224.0.0.0 and ar$mask = 240.0.0.0
The exception is group 224.0.0.1, which the ARP Server will ONLY ever
return its own ATM address for.
The use of alternative mask values is discussed in Section 9.
Armitage Expires February 6th, 1995 [Page 12]
Internet Draft September 6th, 1994
6.2 Establishing the 224.0.0.1 signalling group.
Consider that the transmit side functions independently, as described
in section 5. The ARP Server only returns itself as a member of
224.0.0.1, no matter what additional hosts it actually knows about.
When multicast hosts on the LIS start up RFC1112 requires that they
join 224.0.0.1. The first host to execute JoinLocalGroup to 224.0.0.1
must send an IGMP ATMMC_JOIN to 224.0.0.1. The transmit side has no
VC to this group, so it queries the ARP Server. The ARP Server
returns itself as the only group member. The host then establishes a
multicast VC to the ARP Server, marking it as the VC for traffic to
224.0.0.1. (The reason for a multicast VC is explained at the end of
this subsection). Finally the IGMP ATMMC_JOIN is sent over the VC.
The ARP Server's IGMP entity receives the ATMMC_JOIN and adds the
host to its list of members of 224.0.0.1. The ARP Server maintains a
multicast VC out to all members of 224.0.0.1, and it adds the new
host as a new leaf node. The ATMMC_JOIN message is not propagated.
The second host to execute JoinLocalGroup for 224.0.0.1 will perform
exactly the same procedure, with the ARP Server still only returning
itself as the only member of 224.0.0.1. The second host establishes a
multicast VC to the ARP Server and sends the IGMP ATMMC_JOIN for
224.0.0.1.
As for the first host, this results in the second host being added to
the ARP Server's list of 224.0.0.1 members. The new host is also
added as a leaf node of the ARP Server's 224.0.0.1 multicast VC. The
second host's ATMMC_JOIN message is not propagated.
This process continues for all IP multicast hosts on the LIS
(including IP multicast routers). Once initialised, each IP multicast
host on the LIS will have a multicast VC to the ARP Server marked as
'224.0.0.1', and an incoming VC from the ARP Server on which IGMP
traffic from other hosts will arrive.
The VC to the ARP Server for 224.0.0.1 traffic is established as a
'multicast' VC for two reasons:
The transmit side of each host does not need 'special case' code
to handle 224.0.0.1 any differently from other Class D addresses.
A multicast VC uses no reverse path resources, which is reasonable
as the reverse path is handled by the multicast VC originating
from the ARP Server.
Armitage Expires February 6th, 1995 [Page 13]
Internet Draft September 6th, 1994
6.3 Joining A General Group X.
When a host joins any other IP multicast group it sends an IGMP
ATMMC_JOIN to 224.0.0.1. Now the ARP Server's IGMP entity handles
things slightly differently. It updates the ARP tables (as before)
AND retransmits the IGMP message to all other members of 224.0.0.1.
This behaviour is used in section 7 to allow nodes that are already
members of a given group to note the new member.
The transmission of an IGMP Report to the group being joined causes
an ARP request to be issued and the establishment of a VC out the
group being joined. If the local host does not transmit to the group
for a period of time the inactivity timer will trigger the closure of
the VC. This will not alter the hosts 'membership' of the group.
6.4 Redundant IGMP Messages.
As a weak form of protection from loss, IGMP messages MUST be
retransmitted twice. Host and Router IGMP entities MUST silently
discard incoming IGMP 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's IGMP entity MUST propagate all IGMP
messages (except as noted in section 6.2).
7. Adding A New Leaf to Outgoing Multicast VC.
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
IGMP entity to inspect ATMMC_JOIN and ATMMC_LEAVE messages arriving
on 224.0.0.1.
If an ATMMC_JOIN 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.
Blocking the propagation of ATMMC_JOINs to 224.0.0.1 by the ARP
Server's IGMP entity ensures the 224.0.0.1 group remains a special
case.
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
Armitage Expires February 6th, 1995 [Page 14]
Internet Draft September 6th, 1994
leaving node. Both are the reverse of the 'join' operations described
in section 6 and 7.
The ARP Server's response:
LeaveLocalGroup results in ATMMC_LEAVE messages being sent to
224.0.0.1 using the same procedure as for ATMMC_JOIN. The ARP
Server's IGMP entity notes the event, and removes the specified
ATM address appropriately.
If an IP multicast host issues a LeaveLocalGroup for 224.0.0.1 it
will be considered to have ceased membership of all other groups
for which it may have joined. The ARP Server MUST flush that
hosts's ATM address from any Class D address entries it appears
in.
Response of an arbitrary host in the LIS:
If an ATMMC_LEAVE 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 ATMMC_LEAVE is seen that refers to group 224.0.0.1 then the
ATM address of the host issuing the IGMP messages 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 multicast IP hosts to be members of 224.0.0.1,
so leaving 224.0.0.1 is considered to indicate cessation of support
for IP multicasting. Normally this is not expected to happen.
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]).
Armitage Expires February 6th, 1995 [Page 15]
Internet Draft September 6th, 1994
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.
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 IGMP entity monitors 224.0.0.1 for IGMP
ATMMC_JOIN and ATMMC_LEAVE messages to update the set of leaf nodes
it sends to, 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 ATMMC_JOIN 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.
Armitage Expires February 6th, 1995 [Page 16]
Internet Draft September 6th, 1994
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
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.
In this situation the LIS administrator might configure their
multicast routers to exclude sections of the Class D address space
when issuing ATMMC_JOIN(s).
Another scenario involves the product M*N exceeding the capacity of a
single router's interface (especially if the same interface must also
Armitage Expires February 6th, 1995 [Page 17]
Internet Draft September 6th, 1994
support a unicast IP router service).
A LIS administrator may choose to add a second node, to function as a
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. All routers are
able to track membership changes through the IGMP ATMMC traffic on
224.0.0.1 anyway.
Mechanisms for establishing these modes of operation are beyond the
scope of this memo.
10. ARP Server Implementation Issues.
This memo specifies the ARP Server's required behaviour, without
direct reference to internal architecture or implementation.
The ARP tables must be carefully constructed to support 'wild card'
entries.
Interaction between the IGMP entity, the ARP tables, and the
retransmission of IGMP messages on the 224.0.0.1 VC has the potential
to generate 'race' conditions if implemented poorly. The ARP Server
may need to serialise its processing of 'simultaneous' ARP_REQUEST
and IGMP messages, to ensure all multicast nodes remain aware of
changes to group memberships.
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 one
exception is group 224.0.0.1, for which the ARP Server
transparently establishes itself as a Multicast Server.
ATM ARP Server role extended.
Class D IP addresses may be mapped to 0 or more ATM addresses.
Class D address 224.0.0.1 returns only the ARP Server's
Armitage Expires February 6th, 1995 [Page 18]
Internet Draft September 6th, 1994
address.
New ARP message type, ARP_MULTI. ATM 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.
IGMP entity added to ARP Server, with ability to modify ARP
table entries.
Specific handling of 224.0.0.1 membership to create a
'multicast server' architecture.
'wild card' ARP table entries possible, where a single ATM
address is simultaneously associated with blocks of Class D
addresses.
IGMP protocol modified and extended.
Two new IGMP messages - ATMMC_JOIN and ATMMC_LEAVE.
All IGMP ATMMC messages, from hosts or routers, are sent to
224.0.0.1.
IGMP entities on all nodes monitor ATMMC traffic to add or
remove leaf nodes to active, outgoing, multicast VCs.
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.
Quality of Service has not been addressed. This is a current issue
for both unicast and multicast IP over ATM.
No attempt has been made to reconcile or optimise the use of IGMP
messages. ATMMC_JOIN and ATMMC_LEAVE contain a superset of the
information in an IGMP Report.
Robustness of IGMP message exchange. Current mechanism inherits
Armitage Expires February 6th, 1995 [Page 19]
Internet Draft September 6th, 1994
the RFC 1112 approach of "repeat it a couple of times, and pray".
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
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
I would like to thank John Moy of Cascade Communications Corp. for
initially suggesting the idea of wild-card entries in the ARP Server.
Author's Address
Grenville Armitage
MRE 2P340, 445 South Street
Morristown, NJ, 07960-6438
USA
Email: gja@thumper.bellcore.com
References
[1] Laubach, M., "Classical IP and ARP over ATM", RFC1577, Hewlett-
Packard Laboratories, December 1993
Armitage Expires February 6th, 1995 [Page 20]
Internet Draft September 6th, 1994
[2] S. Deering, "Host Extensions for IP Multicasting", RFC 1112,
Standford University, August 1989.
[3] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaption
Layer 5", RFC 1483, USC/Information Science Institute, July 1993.
[4] ATM Forum, "ATM User-Network Interface Specification Version
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.
Appendix A. UNI 3.0 Multicast Support - A Brief Overview.
This section provides a summary of point-to-multipoint signaling
procedures. Readers are referred to [4].
[...to be written. <draft-ietf-ipatm-sig-02.txt> will be used as a
basis for relevant IEs and signalling behaviour...]
Armitage Expires February 6th, 1995 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-23 17:19:34 |