Internet-Draft Bryan Gleeson
Adaptec
Grenville Armitage
Bellcore
May 23rd, 1995
Issues surrounding a new encapsulation for IP over ATM.
<draft-armitage-ipatm-encaps-01.txt>
Status of this Memo
This is purely an informational I-D, to capture the current state of
a somewhat thorny issue and focus further comment. This is the second
version of this draft and it contains extra encapsulation options,
more details on co-existence with existing unicast encapsulations and
more details on the use of the Cluster Member Id.
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".
To learn the current status of any Internet-Draft, please check the
"lid-abstracts.txt" listing contained in the Internet-Drafts shadow
directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Abstract
The Internet Draft draft-ietf-ipatm-ipmc-04.txt ("Support for
Multicast over UNI 3.1 based ATM Networks") describes a mechanism for
handling IP multicast over ATM. In doing so it notes two different
Gleeson, Armitage Expires November 23rd, 1995 [Page 1]
Internet Draft New encapsulation for IP over ATM May 23rd, 1995
mechanisms for actually achieving the multicasting of packet traffic
at the ATM level. These are meshes of point to multipoint VCs, or ATM
level multicast servers. If a multicast server is in use a host or
router may receive a transmitted packet back on the same interface it
was originally sent on. It is necessary for IP hosts and routers to
be able to distinguish and discard these packets which are reflected
back. This memo describes the issue in greater detail, and suggests a
range of new encapsulation options.
1. Introduction.
The general problem can be summarised as follows:
What can an IP layer or IP multicast forwarding entity do when
faced with an underlying link layer interface that sends back
exact copies of the IP packets transmitted by the local IP entity?
(Furthermore, the underlying interface currently provides no
indication of the packet's link layer source.)
More specifically, current IP over ATM encapsulation does not provide
any per-packet information on the source ATM interface. This has not
been an issue for unicast communication, where the ATM source is
either irrelevant or deduced from the IP source address. However,
certain ATM multicast architectures described in draft-ietf-ipatm-
ipmc-04.txt (hereafter referred to as 'ipmc-04') result in packets
being reflected back to their sources. (The problem arises when a
multicast server, rather than a VC mesh, is used to achieve the
multicasting of AAL5 SDUs within a Cluster).
In the case of a directly attached IP source, it can check the IP
source address in every incoming packet to discover if the packet has
actually arrived from a remote IP entity, or is just a reflection
from a multicast server.
The case of the IP multicast forwarding entity currently appears to
have no general solution, but the issue has not yet been
satisfactorily resolved. It is multicast routing protocol dependent.
On the one hand it has been asserted that IP multicast routing
algorithms do not allow any time-invariant associations to be made
between unicast IP source identities and their likely arrival
interface at the IP multicast forwarding entity. On the other hand it
has been asserted that for many current IP multicast routing
protocols, there is a mechanism to do this. However it is not clear
that in all cases the mechanism is efficient or desirable (for
example PIM, which uses duplicate packets to detect parallel paths,
Gleeson, Armitage Expires November 23rd, 1995 [Page 2]
Internet Draft New encapsulation for IP over ATM May 23rd, 1995
and then takes further action to eliminate the parallel path by
issuing PIM Assert messages). A more extreme case is CBT (one of a
class that uses shared distribution trees) for which there is no
solution if we focus solely on the IP level.
More significantly perhaps is that even if an efficient solution is
found for today's multicast routing protocols, it may not work with a
new protocol. Also Layer 3 solutions will become more inefficient
with the adoption of IPV6, and longer IP addresses.
An ATM Adaptation Layer or Layer 2 solution to the problem makes the
solution completely Layer 3 protocol independent, and that is what
this draft outlines.
The proposed solution is:
Add functionality to the IP/ATM mechanism so that it _is_ possible
to identify the packet's actual source within the Cluster to which
the IP/ATM port is 'attached'.
If an AAL_SDU arrives which can be seen to have been originated by
you, drop it _before_ it gets to the overlying IP stack.
This solution has two parts:
- Establishing a mechanism for identifying sources within
multicast Clusters.
and
- Carrying this source identification along with each IP multicast
packet.
(The first item can be solved independently of the second, and may be
made part of the MARS architecture before the WG reaches any
agreement on the second item.)
Section 2 describes a simple extension of the existing MARS protocol
that will allow management of what I'll term Cluster Member IDs
(CMIs). Section 3 will describe some of our options with respect to
carrying the CMI. Section 4 outlines co-existence issues with
existing unicast encapsulations. Section 5 provides additional
information on the allocation and use of the CMI in the case of a
router with multiple interfaces.
Gleeson, Armitage Expires November 23rd, 1995 [Page 3]
Internet Draft New encapsulation for IP over ATM May 23rd, 1995
2. Managing the Cluster Member ID.
Each cluster member is dynamically allocated a 16 bit Cluster Member
ID (CMI) by the MARS when they register as a member of
ClusterControlVC.
(This CMI is included in every IP over ATM packet using whatever
extended encapsulation mechanism is chosen.)
The ar$resv field in the MARS_JOIN message (expanded to 32 bits as
one of the corrections in the 04 to 05 transition) is subdivided into
two 16 bit fields. These subfields are ar$cmi (the 16 bit CMI), and
ar$resv (16 bits reserved).
When a host sends a MARS_JOIN the ar$cmi MUST be zeroed.
When the MARS receives a MARS_JOIN for "0.0.0.0" it adds the source
to ClusterControlVC, allocates a new CMI, fills in the ar$cmi field
with the new value, then retransmits the MARS_JOIN as currently
defined. (The only new step is allocating and filling the ar$cmi
field).
A host receiving its own MARS_JOIN for "0.0.0.0" back extracts the
ar$cmi field. This CMI is then compared with the CMI in every
incoming IP over ATM AAL_SDU which contains a CMI. If a match occurs,
the packet is deemed to be a reflection from a multicast server, and
is dropped before it even reaches the local IP layers receive queue.
When a host issues a MARS_LEAVE for "0.0.0.0" it must fill in the
ar$cmi field with its allocated CMI, which the MARS then uses to
deallocate the CMI value.
3. Possible encapsulation options.
Ideally the encapsulation should have the following characteristics:
- does not require any change to the signalling requirements RFC
1755
- is suitable for multiprotocol use
- allows unicast and multicast packets to share a VCC
Options 1 - 4 are mapped into AAL5 PDUs according to RFC1483.
Option 5 defines a different mapping.
Gleeson, Armitage Expires November 23rd, 1995 [Page 4]
Internet Draft New encapsulation for IP over ATM May 23rd, 1995
Option 1:
Get a whole OUI allocated for IP over ATM, and use the PID space
for the CMI. This would retain the current 32bit packet boundary.
[0xAA-AA-03][new OUI][2byte CMI][IP packet]
This is not suitable for multiprotocol use. The IETF / IANA
already has an OUI for use with ethernet multicast (00-00-5E).
This could probably be reused. Being an LLC encapsulation,
multicast and standard LLC/SNAP encapsulated unicast packets may
be carried on the same VCC.
Option 2:
Allocate a new Ethertype for IPmc packets which defines a payload
consisting of a 16 bit CMI and 16 bit pad field followed
immediately by an IP packet. This is used to define a new PID and
consequential payload format. The AAL5 PDU is 32 bits longer, but
the IP packet is still 32 bit aligned.
[0xAA-AA-03][0x00-00-00][New PID][2byte CMI][2byte pad][IP packet]
This is not suitable for multiprotocol use. A new PID for IPmc
packets is required. Being an LLC encapsulation, multicast and
standard LLC/SNAP encapsulated unicast packets may be carried on
the same VCC.
Option 3:
Get a new OUI and allow specification of the existing set of
PID/Ethertypes to support AppleTalk, IPX, etc too.
[0xAA-AA-03][New OUI][Old PID][2byte CMI][2byte pad][IP packet]
This is suitable for multiprotocol use. The IETF / IANA already
has an OUI for use with ethernet multicast (00-00-5E). This could
probably be reused. Being an LLC encapsulation, multicast and
standard LLC/SNAP encapsulated unicast packets may be carried on
the same VCC. The Old PID field contains an existing
PID/Ethertype.
Option 4:
Like Option 2 except the pad field is used to carry the
PID/Ethertype,
[0xAA-AA-03][0x00-00-00][New PID][2byte CMI][Old PID][IP packet]
Gleeson, Armitage Expires November 23rd, 1995 [Page 5]
Internet Draft New encapsulation for IP over ATM May 23rd, 1995
This is suitable for multiprotocol use. A new PID for MARS is
required. Being an LLC encapsulation, multicast and standard
LLC/SNAP encapsulated unicast packets may be carried on the same
VCC. The Old PID field contains an existing PID/Ethertype.
Option 5:
This is a different approach and tackles the problem at a
different level, which has advantages and disadvantages.
[CMI][ Any layer 2 / 3 encapsulated packet][UU][CPI][LEN][CRC]
This option defines a new SSCS layer. The UU byte is significant
and is set to the length of the CMI. By examining the UU byte the
existence / length of the CMI can be determined. Has the advantage
that it can be used with any layer 2 or layer 3 encapsulation,
including the null encapsulation. It is suitable for multiprotocol
use. It can be used to carry existing encapsulations on the same
VCC by setting the UU byte to zero. Has the disadvantage that its
use of the UU byte in this fashion is not RFC 1483 compliant. The
use of the other AAL5 trailer fields are as defined by 1483.
A new codepoint is needed to identify the SSCS and this would be
assigned by the ITU. This is indicated in the AAL5 parameters IE
when the VCC is signalled. Note that the BLLI encapsulation
negotiation is orthogonal to the SCCS selection.
No assumption can currently be made that the UU byte in AAL5
frames that carry existing 1483 encapsulations is set to zero, as
1483 allows it to be set to any value, and does not require it to
be zero. If it was required to be set to zero then the allocation
of a new codepoint to identify whether the UU byte was significant
would not be needed. In this case this option would not be a new
SSCS but would be a new mapping of AAL5-SDUs onto the null SSCS.
However given existing 1483 implementations I don't think this
variant of Option 5 is feasible.
New Number assignment:
The question arises as to which of these schemes is most feasible
from the perspective of obtaining the allocation of new OUI or PID
values.
Allocating a new PID under OUI 0x00-00-00 (Options 2,4) is trivial in
that these PID values are inherited from the set of Ethertypes
maintained by Xerox. Xerox registers new Ethertypes for a nominal
fee, and there is obviously no requirement that we actually use the
Gleeson, Armitage Expires November 23rd, 1995 [Page 6]
Internet Draft New encapsulation for IP over ATM May 23rd, 1995
Ethertype on an actual Ethernet anywhere in the world.
Assuming that the existing IETF / IANA OUI could be used no new OUI
is needed (Options 1,3). If one was needed it would be assigned by
the IETF and costs $1000 I believe.
Allocating a new SSCS codepoint (Option 5) could be a long process.
An SSCS is part of the AAL layer and so would be defined in an ITU
Recommendation. A contribution would need to be made to the ATM
Forum, which was then brought to the relevant ITU group, by an ITU
member. UNI signalling has provisions for user-defined AALs, but not
user-defined SSCSs.
4. Use of the extended encapsulation
The intent of this section is that the text be included as normative
text in the ipmc-04 draft (or appropriate latest version).
This section distinguishes between multicast-capable stations (MC-
stations) and unicast-only stations (UC-stations). UC-stations are
those conformant to RFC 1577 and RFC 1755 and only transmit or
receive unicast IP packets. An MC-station supports the same unicast
functionality and in addition supports multicast as defined by the
IPMC draft.
Note that even in a mixed MC-station and UC-station environment a
UC-station will never receive a multicast packet, as it will not
register with the MARS as being a member of any IP Class D groups.
An packet with extended encapsulation will never be received by a
UC-station, so there is no compatibility problem. A UC-station will
never send a multicast packet as by definition it has no mechanism
for using the MARS to resolv multicast destination addresses.
The following applies to MC-stations:
Unicast IP transmissions are handled exactly as they are by UC-
stations. An encapsulation is negotiated at VCC establishment. The
default is LLC/SNAP. If LLC encapsulation is negotiated a unicast
packet must use the standard existing encapsulation ( [AA-AA-03][00-
00-00][08-00] ). A unicast packet must not be transmitted using the
extended encapsulation.
An MC-station must support echo detection using the extended
encapsulation. All multicast packets must be transmitted using the
extended encapsulation. The CMI field is set the the CMI value
allocated to the MC-station by the MARS. On receive an extended
encapsulated packet is recognized and the CMI extracted and compared
Gleeson, Armitage Expires November 23rd, 1995 [Page 7]
Internet Draft New encapsulation for IP over ATM May 23rd, 1995
with the MC-station's own CMI. If there is a match the packet is
silently discarded otherwise packet processing continues as normal.
When a VCC is signalled on which multicast traffic is to be sent,
encapsulation negotiation using a list of BLLI IEs must not be
performed. Instead only one BLLI IE must be present - that for LLC.
This implies that all point to multipoint VCCs must use the LLC
encapsulation.
An MC-station must be prepared to receive both standard and extended
encapsulated packets on any VCC which uses LLC encapsulation.
5. What about routers with multiple interfaces?
This is not a problem. However, this section will briefly describe a
concern that may occur to readers, and then show how it is not
actually an issue.
The Cluster Member ID is only unique within the Cluster managed by a
given MARS. On the surface this might appear to leave us with a
problem when an IPmc router is routing between two or more Clusters
using a single physical ATM interface. The router will register with
two or more MARSs, and thereby acquire two or more independent CMI's.
Given that each MARS has no reason to synchronise their CMI
allocations, it is possible for a host in one cluster to have the
same CMI has the router's interface to another Cluster. How does the
router distinguish between its own reflected packets, and packets
from that other host?
The answer lies in the fact that routers (and hosts) actually
implement _logical_ IP/ATM interfaces over a single physical ATM
interface. Each logical interface will have a unique Called Party
Number (eg. an NSAP with different SELector fields, one for each
logical interface).
Each logical IP/ATM interface is configured with the address of a
single MARS, attaches to only ONE cluster, and so had only one CMI to
worry about. Viewed from the MARS perspective, each of the MARSs that
the router is registered with will have been given a different NSAPA
(corresponding to the different SELectors, corresponding to the
different logical IP/ATM interfaces).
When hosts in a cluster add the router as a leaf node, they'll
specify the NSAPA of the appropriate logical IP/ATM interface on the
router in the ADD_PARTY message. Thus, each logical IP/ATM interface
will only have to check and filter on CMIs assigned by its own MARS.
Gleeson, Armitage Expires November 23rd, 1995 [Page 8]
Internet Draft New encapsulation for IP over ATM May 23rd, 1995
In essence the 'Cluster Identification' is achieved by ensuring that
logical IP/ATM interfaces can be differentiated by being assigned
different Called Party Numbers. If the router's physical ATM
interface is attached to a public UNI that routes on E.164 addresses,
a similar effect can be achieved. The router could register its E.164
address and an NSAPA Called Party Sub Address with the MARS. The MARS
(and MARS clients) will store the Called Party Sub Address without
modification, and it will be passed back to the router when a MARS
client issues an ADD_PARTY. When it receives an ADD_PARTY, the
router uses the Called Party Sub Address to identify the desired
logical IP/ATM interfaces.
Acknowledgements
This I-D is a distillation of issues raised during discussions, both
in private and on the IP-ATM mailing list. Thanks to all who have
contributed, including Keith McCloghrie (Cisco) who suggested Option
4.
Security Consideration
Security considerations are not addressed in this memo.
Authors' addresses
Bryan Gleeson
Adaptec,
691 South Milpitas Boulevard,
Milpitas, California 95035.
USA
Email: bryang@eng.adaptec.com
Grenville Armitage
MRE 2P340, 445 South Street
Morristown, NJ, 07960-6438
USA
Email: gja@thumper.bellcore.com
Gleeson, Armitage Expires November 23rd, 1995 [Page 9]