Internet Draft M. Christensen October 2001 Vitesse Expiration Date: March 2002 MPLS multicast 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 [RFC2026]. 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 and may be updated, replaced, or obsoleted by other documents at any time. 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. Abstract This document is about MPLS multicast transmission over ethernet networks. Comparison is made to IP multicast and a mapping to ethernet link layer addresses is suggested. 1. Link layer multicast The current standard for transmission of MPLS over Ethernet [STACK] specifies separate Ethernet Type values for unicast and multicast (0x8847 and 0x8848 respectively). However, the value for the destination MAC (DMAC) address in the ethernet frame is unspecified. Typically, unicast MPLS is sent with a (unicast) destination MAC address matching the next hop MPLS router and here there are no ambiguity. For MPLS multicast, the framework [MCAST] state in general terms that for multiaccess networks a MPLS multicast packet should only be sent once. This indicates that multicast DMAC addresses should be used. There are several methods for doing this: Christensen [Page 1] INTERNET DRAFT October 2001 * broadcast address * arbitrary locally administered multicast address * IPv4/IPv6 mapped multicast address The broadcast address (FF-FF-FF-FF-FF-FF) is probably not a good idea because generally these frames will be sent to the local protocol stack for further protocol demultiplexing (Was it ARP?, SNMP?, ...). Setting the two least significant bits of the first byte of the Ethernet DMAC address yields a locally administrated multicast address. Although a perfectly valid approach, it is not recommended that local adminis- trated (= arbitrary) DMAC addresses are used for interoperability rea- sons. Finally the claim could be made that for all practical purposes the only protocols supported over MPLS are IPv4 and IPv6. We could then use the already described procedures for mapping these addresses to DMAC addresses [IGMPv1] [IP6ETH] (For IPv4 the mapping uses the lower 23 bits of the (32bit) IPv4 address and places them as the lower 23 bits of a DMAC with the fixed header of 01-00-5e). The argument against this method is that doing so effectively removes the meaning of Multiprotocol from MPLS by only supporting IPv4 and IPv6. Also there is an ambiguity when mapping IPv4 addresses to Ethernet DMAC addresses since 32 bits are mapped to 23. This means that two different IP multicast addresses potentially mapping to different MPLS paths and labels can map to the same DMAC address. This again means that there is a risk that traffic is distributed to the wrong recipients in certain network scenarios. We would like to suggest that a mapping similar to IPv4 and IPv6 is introduced which is reserved for MPLS. Since the MPLS label is 20bit the mapping from MPLS labels to DMAC addresses will be unambiguous. So if for example we have a MPLS label of 65535 and our chosen DMAC prefix is 01-00-88, the DMAC will be 01-00-88-00-FF-FF. 2. References [IGMPv1] Deering, S. "Host Extensions for IP Multicasting", RFC1112, August 1989. Christensen [Page 2] INTERNET DRAFT October 2001 [IP6ETH] Crawford, M. "Transmission of IPv6 Packets over Ethernet Networks", RFC2464, December 1998. [STACK] Rosen, E. "MPLS label stack encoding", RFC3032, January 2001 [MCAST] Ooms, D. "Framework for IP Multicast in MPLS", EXPIRED draft-ietf-mpls-multicast-05, January 2001 3. Author's Addresses: Morten Jagd Christensen Vitesse Semiconductor Corporation Hoerkaer 16 2730 Herlev DENMARK email: mjc@vitesse.com Christensen [Page 3] INTERNET DRAFT October 2001 Table of Contents 1. Link layer multicast . . . . . . . . . . . . . . . . . . . . . . 1 _N References . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 _N Author's Addresses: . . . . . . . . . . . . . . . . . . . . . . . 3 Christensen [Page 1]