HTTP/1.1 200 OK Date: Mon, 08 Apr 2002 22:35:39 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Wed, 24 May 1995 22:00:00 GMT ETag: "2e7d3b-4f38-2fc3ac60" Accept-Ranges: bytes Content-Length: 20280 Connection: close Content-Type: text/plain Internet-Draft Bryan Gleeson Adaptec Grenville Armitage Bellcore May 23rd, 1995 Issues surrounding a new encapsulation for IP over ATM. 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]