Internet DRAFT - draft-bless-diffserv-mcast-routerext
draft-bless-diffserv-mcast-routerext
Internet-Draft DS Multicast Router Extension July 2001
INTERNET-DRAFT R. Bless
Expires: January 2002 K. Wehrle
Universitaet Karlsruhe (TH)
Document: draft-bless-diffserv-mcast-routerext-00.txt July 2001
A Router Extension to Support
Multicast in Differentiated Services Networks
<draft-bless-diffserv-mcast-routerext-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.
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 draft proposes an extension to the multicast routing table in
routers in order to achieve better support for using multicast
within Differentiated Services (DS) networks. Only one additional DS
codepoint for each virtual interface in the multicast routing table
is required to open up a variety of different uses, e.g., to solve
resource provisioning problems or to support heterogeneous DiffServ
multicast groups.
Bless & Wehrle Expires: January 2002 [Page 1]
Internet-Draft DS Multicast Router Extension July 2001
1 Introduction
Basically, Differentiated Services mechanisms are also applicable to
multicast traffic. This means that usually all replicates of an
incoming multicast packet get the same DS codepoint [1]. However,
that would not always be desirable, because provisioning of network
resources is much more difficult (see [3] and sec.5 of [2]) if joins
are happening uncontrolled. The proposed solution would allow to
assign a different DS codepoint to any branch of the multicast
delivery tree, thus allowing different forwarding treatment within a
multicast group. This can be useful to prevent resource over-
utilization or to allow multicast groups with heterogeneous quality-
of-service delivery.
2 Description of the proposed extension
Each router should provide entries to store a DS codepoint value
within each multicast routing table entry per outgoing virtual
interface (cf. Figure 1). A virtual interface means in this context,
that it is either a multicast tunnel or a real physical network
interface. So there may be several configured tunnels over one
physical interface present. The multicast routing table entry
contains usually information about the multicast group address
(destination address), source address and (virtual) outgoing
interfaces where packets should be copied to during packet
forwarding.
Multicast Other List
Destination Fields of
Address virtual Inter- DS
interfaces face ID Entry
+--------------------------------+ +-------------------+
| X | .... | *-------------------->| C | DSCP |
|--------------------------------| +-------------------+
| Y | .... | *-----------+ | D | DSCP |
|--------------------------------| | +-------------------+
| ... | .... | ... | |
. . . . | +-------------------+
. ... . .... . ... . +-------->| B | DSCP |
+--------------------------------+ +-------------------+
| ... | .... | ... | | D | DSCP |
+--------------------------------+ +-------------------+
| ... | ... |
. . .
. . .
Figure 1: Multicast routing table with additional
fields for DSCP values
Bless & Wehrle Expires: January 2002 [Page 2]
Internet-Draft DS Multicast Router Extension July 2001
Setting and use of the codepoint should be controlled by management
mechanisms allowing to either use the original codepoint of the
incoming packet or to use the stored codepoint in the multicast
routing table. Therefore, the used management protocol must be
capable of transporting the codepoint value for a specific multicast
group and interface to a certain router. Alternatively, the value
could also be distributed by an enhanced multicast routing protocol.
Actual use of the codepoint entry should be encoded together with the
codepoint entry, e.g., in the remaining 2 bits of the entry if a
whole byte is used to store the DSCP value (however, the specific
implementation technique is out of scope of this document). Possible
actions for setting the codepoint of outgoing multicast packets are:
. Copy original codepoint of incoming packet
. Use configured codepoint from multicast routing table entry
. Use configured codepoint from multicast routing table entry only
if original incoming codepoint is different from a set of pre-
configured codepoints (e.g., DSCP 0).
3 Security Considerations
Basically, service degradation or theft of resources will be possible
if an attacker is able to set codepoint entries in multicast routing
tables. This should be avoided by using only secure router
administration and configuration mechanisms which are widely known
and in use. Therefore router management should generally be protected
against unauthorized use, thus preventing such attacks.
4 References
[1] F. Baker, D. Black, S. Blake, and K. Nichols. Definition of the
Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers. RFC 2474, Dec. 1998.
[2] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W.
Weiss. An Architecture for Differentiated Services. RFC 2475,
Dec. 1998.
[3] R. Bless, K. Wehrle: "Group Communication in
Differentiated Services Networks", Internet QoS for the Global
Computing 2001 (IQ 2001), Workshop at CCGRID 2001 (IEEE
International Symposium on Cluster Computing and the Grid),
15.-18. May 2001, Brisbane, Australia, IEEE Press,
ISBN 0-7695-1010-8, pp. 618-625
Bless & Wehrle Expires: January 2002 [Page 3]
Internet-Draft DS Multicast Router Extension July 2001
5 Authors' addresses
Comments and questions related to this draft can be addressed to one
of the authors listed below.
Roland Bless
Institute of Telematics
Universitaet Karlsruhe (TH)
Zirkel 2
D-76128 Karlsruhe
Germany
Tel.: +49 721 608 6413
bless@tm.uka.de
Klaus Wehrle
Institute of Telematics
Universitaet Karlsruhe (TH)
Zirkel 2
D-76128 Karlsruhe
Germany
Tel.: +49 721 608 6414
wehrle@tm.uka.de
Bless & Wehrle Expires: January 2002 [Page 4]
