Internet Draft M. Christensen
October 2001 Vitesse
Expiration Date: March 2002
MPLS multicast over Ethernet
<draft-jagd-mpls-mcast-eth-00.txt>
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]