INTERNET-DRAFT Jiwoong Lee Expires: December 2001 Korea Telecom Freetel May 9 2001 Xcast over Ethernet Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsolete by other documents at anytime. It is inappropriate to use Internet Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. All remarks may be forwarded to author's email address or Xcast WG mailing list: xcast@public.alcatel.com 1. Introduction This document specifies how to deliver an Xcast datagram over Ethernet link. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. In addition, this document frequently uses the following terms: Ethernet A link layer technology including CSMA/CD and full-duplex subnetworks based on ISO/IEC 8802-3, with various data rates Xcast Explicit Multicast Jiwoong Lee Expire Dec 2001 [Page 1] INTERNET-DRAFT Xcast over Ethernet May 2001 X2M Conversion of Xcast to Host Group Model Multicast X2U Conversion of Xcast to Unicast The definitions of terms that are not defined here can be found at references at the end. 2. Address mapping The destination address of an Xcast datagram is a predefined link local multicast address known as All_Xcast_Nodes [XCST]. When an Xcast node maps All_Xcast_Nodes into an Ethernet link layer address, it does NOT follow the address mapping rule defined in [1112][2464][0894]. That is, All_Xcast_Nodes SHOULD NOT be mapped into a multicast Ethernet address. Instead, the target link layer address MUST be the designated Ethernet address of the next routing hop on the Ethernet link that the source node shares. 3. Transmitting an Xcast datagram over Ethernet If a next hop toward which an Xcast router sends a processed Xcast datagram resides in an Ethernet link that the router shares, the Xcast router can send the datagram in one of two ways. 3.1 Not using IP encapsulation The target link layer address MUST be the designated Ethernet address of the next hop. Note that Xcast datagram itself does not include any information addressing the next hop. Therefore the Xcast routing module should have some way to transfer the appropriate information to the link layer module so that it can acquire the link layer address of the next hop and transmit the Ethernet frame to that link layer address. 3.2 Using IP encapsulation Before the Xcast router sends a processed Xcast datagram, it MAY perform IP-in-IP encapsulation [IPIP] [TUN6] over it. The destination address of the tunnel header MUST be the unicast IP address of the next hop[XCST]. After the encapsulation, the Xcast router handles the datagram as normal outgoing unicast one. 3.3 X2M When an Xcast router performs X2M over an Xcast datagram, the result of X2M is no more an Xcast datagram but a Host Group Model multicast datagram. Therefore how to handle X2M-performed datagram is not in the scope of this document. Jiwoong Lee Expire Dec 2001 [Page 2] INTERNET-DRAFT Xcast over Ethernet May 2001 4. Receiving an Xcast datagram over Ethernet If an Xcast node receives an Xcast datagram encapsulated by the Ethernet frame which is addressed to multicast Ethernet address, it MUST discard this datagram. From the viewpoint of implementations, the subject that discards incoming Xcast datagram is the network layer module of the implementations, rather than link layer module. If an Xcast node receives an Xcast datagram encapsulated by the Ethernet frame which is addressed to unicast Ethernet address, normal Xcast operations SHALL be performed as described in [XCST]. 5. Security Considerations The addresses of the recipients carried in an Xcast datagram can be easily exposed to malicious attackers who are connected to the Ethernet links on the delivery path. Concealment of the recipients is out of the scope of this document. Appendix In this section, the rationale for section 2 & 3 will be given. A. Discussion The current version of Xcast basic specification [XCST] assumes that all links en route are point-to-point ones. However, the general Internet architecture does not consist only of point-to- point link, but consists also of shared links. In particular Ethernet has acquired its popularity and has been widespreadly deployed as WAN technology as well as LAN. Some Ethernet technology including only two nodes in its segment will not be different from the normal point-to-point link. One example of this kind of configuration is 10 Gigabit Ethernet. This document does not deal with following Xcast talk items; - Xcast-awareness test of a node on the shared link - How to elect a designated Xcast router - Interoperability between Xcast and Host Group Model multicast A.1 Why we need to invent how to transmit over Ethernet Assume Xcast basic specification [XCST] is applied to Ethernet link of (Figure A-1) while conventional Internet nodes support only the Host Group Model multicast. Sender creates an Xcast datagram whose List of Addresses includes the addresses of E, F and G. When A Jiwoong Lee Expire Dec 2001 [Page 3] INTERNET-DRAFT Xcast over Ethernet May 2001 receives the datagram, it performs Xcast routing as specified in [XCST] and generates two Xcast datagrams #1 and #2. #1 is for E and F, #2 is for G, if no premature X2U was applied. Both are addressed to All_Xcast_Nodes. Since each is encapsulated by multicast addressed Ethernet frame, it reaches both B and C Note that Xcast routers does not perform any multicast tree construction or state management. When B receives #2, B does not perform Reverse Path Forwarding check and believes that this datagram should be forwarded to C. Therefore B will toss #2 to C over Link X. The 'tossed #2' will be heard also by A and A will start to process it since A cannot distinguish 'tossed #2' and '#2' that it previously sent. A sends another #2 to Link X. B listens 'another #2', and so on. Therefore the Link X will be flooded with #1, #2 and their descendents until their lifetime expires. Multiply received datagrams will not be discarded en route (including even end hosts) if the redundancy check is not applied. For this reason, a new solution must be provided to deliver Xcast datagram over Ethernet. Link X /------E |---B------D------F #1 | Sender-----A-------| #2 | |---C------G (Figure A-1) Example network topology B. Solution candidates It has been deemed that there are various solution candidates to realize the delivery of Xcast datagram over Ethernet link. They work logically in a technical sense. They are a) Building a Multiplexed form of Xcast datagram, abiding by RFC1112 rule. b) Transmitting an Xcast datagram with one-hop tunneling. The tunnel header is unicast-addressed to the next hop. c) Building an variant Ethernet frame which carries multiple target link layer addresses. Jiwoong Lee Expire Dec 2001 [Page 4] INTERNET-DRAFT Xcast over Ethernet May 2001 d) Utilizing IEEE 802.1Q VLAN tag header to indicate legitimate next hops e) Transmitting an Xcast datagram in unicast Ethernet frame, which is destined to the next hop. B.1 Challenge and conquer a) Building the Multiplexed form of Xcast datagram, abiding by [1112] rule. On an Ethernet link, the source Xcast router does not perform replicating the datagram per next hop. Rather, it inserts some field into the Xcast datagram to indicate who are the legitimate next hops and which receiver addresses they should process. One convenient form of this particular datagram will be [ S:source, D:All_Xcast_Nodes, NextHops: N1 for L1 / N2 for L2, List:L1+L2 ] , where S stands for Source address field, D for Destination address field, NextHops for an extended version of List of Addresses field, N# for an address of a next hop, L# for a list of addresses that N# should process. The link layer module maps the destination address, All_Xcast_Nodes, into a multicast link layer address as described in [1112], and transmits this frame over Ethernet. The advantage of this form is that the Xcast can obtain the high bandwidth utilization at least as much as the Host Group Model multicast can do over an Ethernet link. One obvious obstacle is that this requires modifications in encoding scheme of Xcast since it inserts a new kind of field: NextHops. The worse one is the fact that the length of this new field can vary hop by hop. In IPv6, one 'next hop' requires 16 bytes for the address of next hop and at least one more byte for list index. Hence increased overhead. For example if there are four next hops in one Ethernet link, the required additional overhead will be ( 16 + 1 ) * 4 = 68 bytes. b) Transmitting the Xcast datagram with one-hop tunneling. The tunnel header is unicast-addressed to the next hop. This seems the easiest solution to implement. The Ethernet modules of Xcast nodes does not have to be modified at all. One disadvantage is multicast bandwidth utilization with this scheme is inferior to that of the Host Group Model multicast, since the link sees Ethernet frame as many as the number of the next hops. (Note, however, the number of next hops can be much smaller than that of recipients. Therefore the bandwidth utilization of this scheme may be superior to that of unicasting.) Another possible drawback is the performance degradation at Xcast routers due to repeated IP Jiwoong Lee Expire Dec 2001 [Page 5] INTERNET-DRAFT Xcast over Ethernet May 2001 encapsulations / decapsulations. c) Building an variant Ethernet frame which carries multiple target link layer addresses. There are at least (or approximately) 900 independent Ethernet vendors in this world (Refer to http://standards.ieee.org/regauth/oui/oui.txt) and this technology has been deployed since 1980. Ethernet is already too widespread to make some modification over it. d) Utilizing IEEE 802.1Q VLAN tag header to indicate legitimate next hops In I998 IEEE creates 4-byte VLAN tag header and adds it prior to the Length/Type field of the Ethernet frame. Since only 4 bytes are available, it is not possible to include any Ethernet address address in this field. Instead, this field can be used as an indication bitmap posterior to link-layer level signaling that shares information who are the Xcast node in that Ethernet segment. Note that this still requires another kind of signaling between nodes and modifications of IEEE standards are required. e) Transmitting an Xcast datagram in unicast Ethernet frame, which is destined to the next hop. Since the Ethernet frame is destined to a unicast address, the frame will be delivered to the intended destination without erroneous frame congestion. Since address mapping process belongs to link layer, it is performed after Xcast routing process defined in [XCST] at transmissions. One advantage of this scheme is that it requires no extra signaling or state management. One major obstacle is that it is not possible that the link layer module deduces the link layer address of the next hop from the network layer datagram, because every Xcast datagram carries an link-local multicast address ,All_Xcast_Nodes, in its destination field and carries no information regarding to the next hop with it. This implies that an implementation of 'Xcast over Ethernet' should have some way to deliver the next hop information from the network layer module to link layer module. References [XCST] R. Boivie, Y. Imai, W. Livens, D. Ooms, and O. Paridaens, Explicit Multicast Basic Specification, IETF draft-ooms-xcast-basic- spec-01.txt, March 2001 Jiwoong Lee Expire Dec 2001 [Page 6] INTERNET-DRAFT Xcast over Ethernet May 2001 [1112] S. Deering, Host Extensions for IP Multicasting, IETF RFC 1112, August 1989 [TUN6] S. Deering, Generic Packet Tunneling in IPv6 Specification, IETF RFC 2473, December 1998 [IPIP] C. Perkins, IP Encapsulation within IP, IETF RFC 2003, October 1996 [ETHR] C. Spurgeon, Ethernet: The Definitive Guide, O'Reilly & Associates, Inc., February 2000 [0894] C. Horing, A Standard for the Transmission of IP datagrams over Ethernet Networks, IETF RFC 894, Symbolics Cambridge Research Cen- ter, April 1984 [0826] D. Plummer, An Ethernet Address Resolution Protocol, IETF RFC 826, Symbolics Cambridge Research Center, November 1982 [2464] M. Crawford, Transmission of IPv6 Packets over Ethernet Networks, IETF RFC 2464, December 1998 [VLAN] IEEE Std 802.1Q-1998 Virtual Bridged Local Area Networks Author Address Jiwoong Lee Korea Telecom Freetel Advanced Technology Lab 1321-11 Seocho-Dong Seocho-Ku Seoul Phone : +82-2-3488-0416 Email : porce@computer.org Jiwoong Lee Expire Dec 2001 [Page 7]