INTERNET-DRAFT R. Bless
Expires: March 2000 K. Wehrle
Universitaet Karlsruhe (TH)
September 1999
IP Multicast in Differentiated Services Networks
<draft-bless-diffserv-multicast-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.
Distribution of this memo is unlimited.
Abstract
Besides providing basic building blocks for enabling different
quality of service levels for unicast applications, the
Differentiated Services approach will also bring benefits for
multicast applications which need quality of service support.
For instance, a highly reliable multicast service can be
provided based on the Expedited Forwarding per-hop behavior
("Premium service"). However, the current efforts mainly
concentrate on unicast services, whereas the deployment of
multicast services using Differentiated Services needs some
clarification.
This document illustrates some of the problems which will
arise when IP Multicast is used in Differentiated Services
networks without taking special provisions into account for
supplying it. Those problems mainly lead to situations in
which other service users are affected adversely in their
quality. In order to retain the benefits of the Differentiated
Services approach, a quite simple and scalable solution for
Bless & Wehrle Expires: March 2000 [Page 1]
Internet-Draft IP Multicast in DiffServ Networks September 1999
those problems is required, not resulting in additional
complexity or costs in a Differentiated Services domain. The
proposed solution in this document requires only an additional
field for the Differentiated Services Codepoint in the
multicast routing table and some support by management
mechanisms.
Contents
1 Introduction.................................................. 2
1.1 Management of Differentiated Services .................. 3
2 Problems of IP Multicast in DS Domains ....................... 3
2.1 Neglected Reservation Subtree Problem (NRS) ............ 4
2.2 Heterogeneous Multicast Groups ......................... 10
2.3 Dynamics of Arbitrary Sender Change .................... 10
3 Solutions for Enabling IP-Multicast in Differentiated Services
Networks ..................................................... 11
3.1 Solution for the NRS Problem............................ 11
3.2 Solution for Supporting Heterogeneous Multicast Groups . 14
3.3 Solution for Arbitrary Sender Change ................... 14
4 Security Considerations....................................... 15
5 References ................................................... 15
6 Authors' addresses ........................................... 16
1 Introduction
Services in the Internet offering a better quality than the current
best-effort service are increasingly required. Many advanced
applications need certain assurances from the network layer, e.g., a
maximum delay, a minimum packet loss rate or guaranteed transmission
rate. The currently used IP mechanisms are not able to offer such
guarantees, especially, if group communication is additionally required.
The "Differentiated Services" (DS) approach [1, 3, 2, 8] defines certain
building blocks and mechanisms to offer qualitatively better services
than the usual best-effort delivery service in the IP network.
In the Differentiated Services Architecture [3] scalability is achieved
by avoiding complexity and maintenance of per-flow state information in
Bless & Wehrle Expires: March 2000 [Page 2]
Internet-Draft IP Multicast in DiffServ Networks September 1999
core nodes and pushes unavoidable complexity to the network edges.
Therefore, individual flows belonging to the same service are
aggregated, thereby eliminating the need for complex classification or
managing state information per flow in interior nodes.
On the other hand, the reduced complexity in DS nodes makes it more
complex to use those "better" services together with IP Multicast (i.e.,
point-to-multipoint and multipoint-to-multipoint communication).
Problems emerging from this fact are described in section 2. However, it
is important to integrate IP Multicast functionality right from the
beginning into the architecture, and, to provide simple solutions for
those problems not defeating the so far gained advantages.
The Premium service [8] shows very interesting properties within a
multicast context. The very low packet loss characteristic makes it
suitable as a basis for a highly (but not absolute) reliable multicast
service. Packet loss cannot be fully precluded, because of aggregation
effects which may nevertheless lead to packet losses. However, in
reality packet losses should occur so infrequently that many
applications can tolerate these losses, or if this is not the case, that
at least very simple retransmission schemes can be applied.
1.1 Management of Differentiated Services
At least for Premium service admission control and resource reservation
is required [8]. Furthermore, installation and updating of traffic
profiles in boundary nodes is necessary. Most network administrators
will not accomplish this task manually, even for long term service level
agreements (SLAs). Furthermore, offering services on demand requires
some kind of signaling and automatic admission control procedures.
Therefore, the concept of Bandwidth Brokers was already suggested by Van
Jacobson at a very early stage of Differentiated Services research [9].
In this concept, the Bandwidth Broker (BB) is a dedicated node in each
DS domain, which keeps track of the amount of available and reserved
bandwidth for services, and, which processes admission control requests
from customers or BBs of adjacent domains. Additionally, it installs or
alters traffic profiles in boundary nodes.
Protocols for signaling a reservation request to a Differentiated
Services Domain are required. For accomplishing end-system signaling to
DS domains RSVP [5] may be used with new DS specific reservation
objects. RSVP is mainly designed for use in multicast scenarios and is
already supported by many operating systems. However, when applying RSVP
to a Differentiated Services network some problems will arise which are
described in the next section.
2 Problems of IP Multicast in DS Domains
Although potential problems and the complexity of providing multicast
with Differentiated Services are considered in a separate section of
Bless & Wehrle Expires: March 2000 [Page 3]
Internet-Draft IP Multicast in DiffServ Networks September 1999
[3], both aspects have to be discussed in greater detail. The simplicity
of the Differentiated Services Architecture and its router models is
necessary to reach high scalability, but it causes also fundamental
problems in conjunction with the use of IP Multicast in DS domains. The
following subsections describe these problems for which a simple
solution is proposed in section 3. This solution is scalable and needs
no resource separation by using different codepoint values for unicast
and multicast traffic.
Because Differentiated Services are unidirectional by definition, we
also consider the point-to-multipoint communication being of
unidirectional nature. In traditional IP Multicast any node can send
packets spontaneously and asynchronously to a multicast group,
respectively to its multicast group address (therefore, IP Multicast
offers a multipoint-to-multipoint service). How to partially retain this
feature in a Differentiated Services context is discussed in
section 2.3.
For subsequent considerations we assume, unless stated otherwise, at
least a unidirectional point-to-multipoint communication scenario in
which the sender generates packets which experience a "better" Per-Hop
Behavior (PHB, see [1, 3] for its exact meaning) than the traditional
default PHB, resulting in a service of better quality compared to the
default best-effort service. In order to accomplish this, a traffic
profile corresponding to the traffic conditioning specification has to
be installed in the sender's first-hop router (the first boundary node
of the first DS domain receiving those packets). Furthermore, it must be
assured that the corresponding resources are available on the path from
the sender to all the receivers, possibly requiring adaptation of
traffic profiles at involved domain boundaries. Note that the latter
process may be also initiated on demand of a receiver.
2.1 Neglected Reservation Subtree Problem (NRS)
Typically, resources for Differentiated Services must be reserved before
actually using them. But in a multicast scenario group membership is
often highly dynamic, therefore limiting the use of a sender-initiated
resource reservation in advance. Unfortunately, dynamic addition of new
members of the multicast group using Differentiated Services can
adversely affect existing other traffic, if resources were not
explicitly reserved before use.
IP Multicast packet replication usually takes places when the packet is
handled by the routing process (cf. Fig. 1). Thus, a DiffServ capable
node would also copy the content of the DS field [1] into the IP packet
header of every replicate. Consequently, replicated packets get exactly
the same DS codepoint as the original packet, and, therefore experience
the same forwarding treatment as the incoming packets of this multicast
group (see Fig. 1, in this case the egress interface comprises functions
for (BA-) classification, traffic conditioning and queueing).
Bless & Wehrle Expires: March 2000 [Page 4]
Internet-Draft IP Multicast in DiffServ Networks September 1999
Interface A Routing Interface C
+-----------+ +--------------+ +-----------+
MC-flow | | | replication | | egress |
---->| ingress |---->|------+-------|----->|(class.,TC,|---->
| | | | | | queueing) |
+-----------+ | | | +-----------+
| | |
Interface B | | | Interface D
+-----------+ | | | +-----------+
| | | | | | egress |
| ingress | | +-------|----->|(class.,TC,|---->
| | | | | queueing) |
+-----------+ +--------------+ +-----------+
Figure 1: Multicast packet replication in a DS router
Normally, the replicating node cannot test whether a corresponding
reservation exists for a particular flow of replicated packets on an
output link (resp. its corresponding interface), because a flow-specific
traffic profile is usually not available in boundary (except in
first-hop nodes) and interior nodes.
When a new receiver joins an IP Multicast group, the corresponding
multicast routing protocol (e.g., DVMRP [11, 10], PIM-DM [6] or PIM-SM
[7]) accomplishes that the multicast tree is expanded by a new subtree
which connects the new receiver to the already existing multicast tree.
As a result of tree expansion and missing per-flow classification
mechanisms, the new receiver will implicitly use the service of better
quality.
If the additional amount of resources which are consumed by the new part
of the multicast tree are not taken into account by the domain
management (cf. section 1.1), the currently provided level of quality of
service of other receivers (with correct reservations) will be adversely
affected or violated. This negative effect on existing traffic contracts
by a neglected reservation -- in the following designated as Neglected
Reservation Subtree Problem (NRS Problem) -- must be avoided under any
circumstances.
40% 40% 20%
+-------------------------------------------------------+
| Premium Service | Assured Service | Best-Effort|
+-------------------------------------------------------+
---------------------------------------------------------->
output link bandwidth
Figure 2: An example bandwidth share of different behavior aggregates
One can distinguish two distinct major cases of the NRS Problem. In
order to compare their different effects a simple example of a share of
bandwidth is illustrated in Fig. 2. Three types of services
Bless & Wehrle Expires: March 2000 [Page 5]
Internet-Draft IP Multicast in DiffServ Networks September 1999
(respectively their corresponding behavior aggregates) share the
bandwidth of the considered output link: Premium service, Assured
service and the traditional Best-Effort service. In this example we
assume that routers perform simple priority queueing, where Premium
service has the highest and Best-Effort the lowest assigned priority.
When Weighted Fair Queueing (WFQ) would be used, the described effects
would essentially also occur, only with minor differences.
The Neglected Reservation Subtree problem appears in two different
cases:
Sender
+---+
| S | DS domains .......
+---+ ..... / \ . ..
|| . . .. / \ .. .
..||.. .... .<- ->... ..
. || . . .
. +---+ +--+ +--+ *) +--+ +--+ +--+ +----+
. |FHR|===|IR|=====|BR|###########|BR|####|IR|######|BR|#####| R B|
. +---+ +--+ +--+\\ +--+ +--+ +--+ +----+
. \\ \ . \\ . \ .
. +--+ +--+ . \\ . \ .
. |IR|-----|IR| . \\ .. +--+ .
. +--+ +--+ . \\ ... ....|BR|..
. || \ ... +----+ ... +--+
. || \ . | R A|
.+--+ ...+--+ +----+
|BR|..... |BR|
+--+ +--+
||
||
FHR: First-Hop Router
S: Sender BR: Boundary Router
R x: Receiver x IR: Interior Router
===: Multicast branch with reserved bandwidth
###: Multicast branch without reservation
*) Bandwidth of PS aggregated on the output link is higher than actual
reservation, PS aggregate will be limited in bandwidth without
considering the responsible flow.
Figure 3: The NRS Problem case 1
o Case 1: If the branching point of the new subtree and the previous
multicast tree is an (egress) border router, as shown in Fig. 3,
the additional multicast flow now increases the amount of used
resources for the corresponding aggregate and will be greater than
the originally reserved amount on the affected output link.
Consequently, the policing component in the egress border router
drops packets until the traffic aggregate is in accordance to the
traffic contract. But during dropping packets, the router can not
identify the responsible flow (because of missing flow
Bless & Wehrle Expires: March 2000 [Page 6]
Internet-Draft IP Multicast in DiffServ Networks September 1999
classification functionality), and, thus randomly discards packets,
whether they belong to a correctly reserved flow or not. As a
result, there will be no longer any service guarantee for the
reserved flows.
| excess |
| bandwidth |
40% | 40% | 20% |------------>|
+-------------------------------------------------------+
| 10% |::::::::::::::| | |:::::::::::::|
+-------------------------------------------------------+
Premium Service Assured Service Best-Effort
---------------------------------------------------------->
output link bandwidth
(a)
| excess |
| bandwidth |
40% | 40% | 20% |------------>|
+-------------------------------------------------------+
| |::::::::::::::| | |:::::::::::::|
+-------------------------------------------------------+
Premium Service Assured Service Best-Effort
---------------------------------------------------------->
output link bandwidth
(b)
Figure 4: Resulting share of bandwidth in a egress border router with
a neglected reservation of a (a) Premium service flow or (b) an Assured
service flow
Fig. 4 shows the resulting share of bandwidth in cases when (a)
Premium service and (b) Assured service is used by the additional
multicast branch causing the NRS Problem. Assuming that the
additional traffic would use another 30% of the link bandwidth,
Fig. 4 (a) illustrates that the resulting aggregate of Premium
service (70% of the outgoing link bandwidth) is throttled down to
its originally reserved 40%. In this case, the amount of dropped
Premium service bandwidth is equal to the amount of excess
bandwidth. The dotted parts in Fig. 4 indicate that the original
Premium service aggregate is affected by packet losses, too. The
other services, e.g., Assured service or Best-Effort, are not
disadvantaged.
Fig. 4 (b) shows the same situation for Assured service. The only
difference is that now Assured service is solely affected by
discards, the other services will still get their guarantees.
In either case, packet losses are restricted to the misbehaving
service class by the traffic meter and policing mechanisms in
boundary routers. Moreover, the latter problem (case 1) occurs only
in egress border routers, because they are responsible, that not
more traffic is leaving the Differentiated Services domain, than
Bless & Wehrle Expires: March 2000 [Page 7]
Internet-Draft IP Multicast in DiffServ Networks September 1999
the following ingress border router will accept. Therefore, those
violations of SLAs will be already detected and processed in egress
border routers.
Sender
+---+
| S | DS domains .......
+---+ ..... / \ . ..
|| . . .. / \ .. .
..||.. .... .<- ->... ..
. || . . .
. +---+ +--+ +--+ +--+ +--+ +--+ +----+
. |FHR|===|IR|=====|BR|===========|BR|====|IR|======|BR|=====| R B|
. +---+ +--+ +--+\\ +--+ +--+ +--+ +----+
. \\ \ . \\ . # .
. +--+ +--+ . \\ . # *) .
. |IR|-----|IR| . \\ .. +--+ .
. +--+ +--+ . \\ ... ....|BR|..
. || \ ... +----+ ... +--+
. || \ . | R A| #
.+--+ ...+--+ +----+ #
|BR|..... |BR| +----+
+--+ +--+ | R C|
|| +----+
||
FHR: First-Hop Router
S: Sender BR: Boundary Router
R x: Receiver x IR: Interior Router
===: Multicast branch with reserved bandwidth
###: Multicast branch without reservation
*) Bandwidth of PS aggregated on the output link is higher than actual
reservation, PS aggregate will be limited in bandwidth without
considering the responsible flow
Figure 5: Neglected Reservation Subtree problem case 2 after join of
receiver C
o Case 2: The Neglected Reservation Subtree problem can also occur,
if the branching point between the previous multicast tree and the
new subtree is located in an interior router (as shown in Fig. 5).
Because the router is not equipped with metering or policing
functions it will not recognize any amount of excess traffic and
will forward the new multicast flow. If the latter belongs to a
higher priority service, such as Premium service, bandwidth of the
aggregate is higher than the aggregate's reservation and will steal
bandwidth from lower priority services. The additional amount of
Premium service without a corresponding reservation is forwarded
together with the aggregate which has a reservation. This results
in no packets losses for Premium service as long as the resulting
aggregate is not higher than the output link bandwidth. Because of
its higher priority, Premium service gets as much bandwidth as
needed and as is available (strictly speaking, it is implementation
Bless & Wehrle Expires: March 2000 [Page 8]
Internet-Draft IP Multicast in DiffServ Networks September 1999
dependent whether interior routers have something like a maximum
configured service rate).
| excess |
| bandwidth |
40% | 40% | 20% |------------>|
+-------------------------------------------------------+
| ::::::::::::::| |:::::::::::::|
+-------------------------------------------------------+
70% PS | 30% AS | AS | BE |
---------------------------------------------------------->
output link bandwidth
(a)
| excess |
| bandwidth |
40% | 40% | 20% |------------>|
+-------------------------------------------------------+
| | :::::::::::::::::|::::::::|
+-------------------------------------------------------+
40% PS | 60% AS | AS | BE |
---------------------------------------------------------->
output link bandwidth
(b)
Figure 6: Resulting share of bandwidth in an interior router with a
neglected reservation of (a) a Premium service flow or (b) an Assured
service flow
The result is, that there is no restriction for Premium service,
but as Fig. 6 (a) shows, other services will be extremely
disadvantaged by this use of non-reserved resources. Their
bandwidth is stolen by the new additional flow. In this case, the
additional 30% Premium service traffic preempts resources from the
Assured service traffic, which in turn preempts resources from the
best-effort traffic, resulting in 10% packet losses for the Assured
service aggregate and complete loss of best-effort traffic. The
example in Fig. 6 (b) shows that this can also happen with lower
priority services like Assured service. When a reservation for a
service flow with lower priority is neglected, other services (with
even lower priority) can be reduced in their quality (in this case
the best-effort service). As shown in the example, the service's
aggregate causing the problem can itself be affected by packet
losses (10% of the Assured service aggregate is discarded).
Besides the described problems of case 2, case 1 will arise in the
next border router, that performs traffic metering and policing for
flows of the service aggregate.
Directly applying RSVP to Differentiated Services would also result in
an NRS Problem, because a receiver has to join the IP multicast group
before sending a resource reservation request (RESV message), in order
Bless & Wehrle Expires: March 2000 [Page 9]
Internet-Draft IP Multicast in DiffServ Networks September 1999
to receive the sender's PATH messages at first. Thus, the join for
receiving PATH messages will already cause an NRS Problem if this
situation is not handled in a special way.
2.2 Heterogeneous Multicast Groups
Heterogeneous multicast groups contain one or more receivers, which
would like to get another service or quality of service as the sender
provides or other receiver subsets currently use. A very important
characteristic which should be supported by Differentiated Services is
that participants requesting a best-effort quality only should also be
able to participate in a group communication which otherwise utilizes a
better service class. The next better support for heterogeneity provides
concurrent use of more than two different service classes within a
group. Things tend to get even more complex when not only different
service classes are required, but also different values for quality
parameters within a certain service class.
A further problem is to support heterogeneous groups with different
service classes in a consistent way. It is possible that some services
will not be comparable to each other so that one service cannot be
replaced by the other and both services have to be provided over the
same link within this group.
Because an arbitrary new receiver which wants to get the different
service can be grafted to any point of the current multicast delivery
tree, even interior routers may have to replicate packets with the
different service. At a first glance, this seems to be a contradiction
with respect to simplicity of the interior routers, because they do not
even have any profile available and should now convert the service
quality of individual receivers. Consequently, in order to accomplish
this, interior routers have to change the codepoint value during packet
replication.
2.3 Dynamics of Arbitrary Sender Change
Basically, within an IP multicast group any participant (actually, it
can be any host not even receiving packets of this multicast group) can
act as a sender. This is an important feature which should also be
available in case a specific service other than best-effort is used
within the group. Differentiated Services possess conceptually a
unidirectional character. Therefore, for every multicast tree implied by
a sender resources must be reserved separately if simultaneous sending
should be possible with a better service. This is even true if shared
multicast delivery trees are used (e.g., with PIM-SM or Core Based
Trees). If not enough resources are reserved for a service within a
multicast tree allowing simultaneous sending of more than one
participant, the NRS problem will occur again.
Bless & Wehrle Expires: March 2000 [Page 10]
Internet-Draft IP Multicast in DiffServ Networks September 1999
The same argument applies to half-duplex traffic which would share the
reserved resources by several senders, because it cannot be ensured by
the network that exactly one sender sends packets to the group.
Accordingly, the corresponding RSVP reservation styles "Wildcard Filter"
and "Shared-Explicit Filter" [5] cannot be supported within
Differentiated Services. The IntServ approach is able to ensure the
half-duplex nature of the traffic, because every router can check each
packet for conformance with the stored reservation state.
3 Solutions for Enabling IP-Multicast in Differentiated Services
Networks
The problems described in the previous section are mainly caused by the
simplicity of the Differentiated Services Architecture. Solutions have
to be developed which do not introduce an additional amount of
complexity which diminishes the scalability of this approach.
In this document, a simple solution is suggested for most of the
problems. In order to keep things simple, we restrict this first
solution for supporting heterogeneous groups to the case in which only
two different services within a multicast group can be used
simultaneously.
3.1 Solution for the NRS Problem
A usage of resources which where not reserved before must be precluded.
In our example, we want to consider the case when the join of a new
receiver to a DS multicast group requires grafting of a whole new
subtree to an already existing multicast delivering tree. The connecting
node which joins both trees converts the codepoint (and therefore the
Per-Hop Behavior) to a codepoint of a PHB which is similar to the
default PHB (see (1) and (3) in Fig. 7) in order to provide a
best-effort-like service for the new subtree. More specifically, this
particular PHB has to be different from the default PHB and should
provide a service which is even worse than the best-effort service of
the default PHB.
The conversion to this specific PHB is necessary in order to avoid
unfairness being introduced otherwise within the best-effort service
aggregate, and, which results from the higher amount of resource usage
of the incoming traffic belonging to the multicast group. If the rate at
which remarked packets are injected into the outgoing aggregate is not
reduced, those remarked packets will probably cause discarding of other
flow's packets in the outgoing aggregate if resources are scarce.
Therefore, the remarked packets from this multicast group should be
discarded more aggressively than other packets in this outgoing
aggregate. This could be accomplished by using a new Lower Than Best
Effort (LBE) PHB (and a related DSCP) for those packets [4]. Merely
dropping packets more aggressively at the remarking node is not
sufficient, because there may be enough resources in the outgoing BA to
Bless & Wehrle Expires: March 2000 [Page 11]
Internet-Draft IP Multicast in DiffServ Networks September 1999
transmit every remarked packet and not requiring discarding any other
packets within the same BA. However, resources in the next node may be
short for this particular BA. Therefore, those "excess" packets must be
identifiable at this node. Mechanisms to provide a "fair" share within
the LBE aggregate or between an LBE aggregate and a BE aggregate are out
of scope of this document and are discussed in [4].
[EF| ]
||
||
||
JOIN_INDICATION \/
+------+ (2) +---------------+
Management | |<----------| |
Entity | ME | | Router |
| |---------->| |
+------+ (4) +---------------+
SET_CODEPOINT // ^ \
// | \
// \ \
// \ \
|| | |
|| (1) JOIN| |
|| | |
\/ | V
[EF| ] (3) [LBE| ]
(5) [EF| ]
===: Multicast branch with reserved resources for Expedited Forwarding
---: New Multicast branch
[x| ]: IP packet with DSCP of PHB x
Figure 7: Sequence of the proposed solution
The better service will be only provided if a reservation request was
processed by the management (e.g., Bandwidth Brokers). In case the
admission test is successful, the remarking node will be instructed by
the management entity to stop remarking and to use the original
codepoint again. Because reservation requests can also be initiated by
the sender, an incoming JOIN-Request of a new receiver subtree should be
also forwarded by a boundary node to the management node (indicated by
the JOIN_INDICATION message in step (2) in Fig. 7), so that the
remarking node can be instructed (via the SET_CODEPOINT message in step
(4)) to immediately use the same codepoint value for replicated packets
belonging to this group as for incoming packets (EF in (5) of Fig. 7).
The proposed solution does not require any additional classification of
multicast groups within an aggregate. Because every multicast packet has
to be handled by the multicast routing process (in this context, this
notion signifies the multicast forwarding part and not the multicast
route calculation and maintenance part, see Fig. 1), addition of an
extra byte in each multicast routing table entry for containing the DS
field, and, thus its DS codepoint value, per output link (resp. child
Bless & Wehrle Expires: March 2000 [Page 12]
Internet-Draft IP Multicast in DiffServ Networks September 1999
virtual interface, see Fig. 8) results in nearly no additional cost.
Packets will be replicated by the multicast routing process, so this is
also the right place for setting the correct DSCP values of the
replicated packets. Their DSCP values are not copied from the incoming
original packet, but from the additional DS field in the multicasting
routing table entry for the corresponding output link (only the DSCP
value must be copied, while the two remaining bits are ignored and are
present for simplification reasons only). This field contains initially
the codepoint of the LBE PHB if incoming packets for this specific group
do not carry the codepoint of the default PHB. When a packet arrives
with the default PHB, the outgoing replicates should also get the same
codepoint in order to retain the behavior of todays common multicast
groups using the default PHB. The SET_CODEPOINT message changes the DSCP
values in the multicast routing table and may also carry the new DSCP
value which should be set in the replicated packets.
Multicast Other List
Destination Fields of child
Address virtual Inter- DS
interfaces face ID Field
+----------------------------------+ +-------------------+
| X | .... | *-------------------->| C | (DSCP,CU) |
|----------------------------------| +-------------------+
| Y | .... | *-----------+ | D | (DSCP,CU) |
|----------------------------------| | +-------------------+
| ... | .... | ... | |
. . . . | +-------------------+
. ... . .... . ... . +-------->| B | (DSCP,CU) |
+----------------------------------+ +-------------------+
| ... | .... | ... | | D | (DSCP,CU) |
+----------------------------------+ +-------------------+
| ... | ... |
. . .
. . .
Figure 8: Multicast routing table with additional fields for DSCP values
Furthermore, there must be a mechanism for boundary nodes to inform a
management entity about the join request of a new subtree (something
like the JOIN_INDICATION message). In order to keep the complexity of
interior nodes low, this task should be preferably handled by boundary
nodes. Additionally, a mechanism must be supplied for instructing a
router to change the DSCP value in the related multicast routing table
entry (something like the SET_CODEPOINT message). This mechanism may be
also incorporated into an existing multicast routing protocol as an
extension.
In summary, only those receivers will obtain a better service within a
DiffServ multicast group, which previously reserved the corresponding
resources in the new subtree with assistance of the management.
Otherwise they get a quality which is even lower than best-effort.
Bless & Wehrle Expires: March 2000 [Page 13]
Internet-Draft IP Multicast in DiffServ Networks September 1999
3.2 Solution for Supporting Heterogeneous Multicast Groups
In this document considerations are currently limited to provision
different service classes, but not different quality parameters within a
certain service class.
The proposed concept from section 3.1 provides also a limited solution
of the heterogeneity problem. Receivers are allowed to obtain a Lower
Than Best-Effort service without a reservation, so that at least two
different service classes within a multicast group are possible.
Therefore, it is possible that any receiver may participate in the
multicast session without getting any quality of service. This is useful
if a receiver just wants to see whether the content of the multicast
group is of interest for it, before requesting a better service which
must be paid for. Alternatively, a receiver might not be able to receive
this better quality of service (e.g., because it is mobile and uses a
wireless link), but it may be satisfied with the reduced quality,
instead of getting no content at all.
Additionally, applying the RSVP concept of listening for PATH messages
before sending any RESV message is now possible again. Without using the
proposed solution this would have caused an NRS Problem.
Theoretically, the proposed approach also supports more than two
different services within one multicast group, because the additional
field in the multicast routing table can store any DSCP value. However,
this would work only if PHBs can be partially ordered, so that the
"best" PHB among different required PHBs downstream is chosen to be
forwarded on a specific link. This is mainly a management issue and out
of scope for this document.
3.3 Solution for Arbitrary Sender Change
Every participant would have to initiate an explicit reservation if a
receiver wants to make sure that it is possible to send with a better
service quality to the group, regardless whether other senders within
the group already use the same service class simultaneously. This would
require a separate reservation for each sender-rooted multicast tree.
However, in the specific case of best-effort service (the default PHB),
it is nevertheless possible for participants to send packets anytime to
the group without requiring any additional mechanisms. The reason for
this is that the first-hop router will mark those packets with the DSCP
of the default PHB because of a missing traffic profile for this
particular sender. First hop routers should therefore always classify
multicast packets in dependence of the sender's address and multicast
group address.
Bless & Wehrle Expires: March 2000 [Page 14]
Internet-Draft IP Multicast in DiffServ Networks September 1999
4 Security Considerations
Basically, the security considerations in [1] apply. The proposed
solution does not really imply new security aspects. If it is not wanted
that arbitrary end-systems can join a multicast group anytime (thereby
receiving a lower than best-effort quality) the application has usually
to preclude these participants by using authentication, authorization or
ciphering techniques at application level just as for traditional IP
multicast scenarios.
On the one hand, instructing the router to set the codepoint value to a
specific entry is naturally a powerful function which could be an
objective for theft of service attacks. On the other hand, its security
depends on the management mechanisms which are used to realize this
functionality. This management should generally be protected against
unauthorized use, therefore preventing those attacks.
5 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] F. Baker, J. Heinanen, W. Weiss, and J. Wroclawski. Assured
Forwarding PHB Group. RFC2597, June 1999.
[3] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss.
An Architecture for Differentiated Services. RFC 2475, Dec. 1998.
[4] R. Bless and K. Wehrle. A Lower Than Best-Effort Per-Hop Behavior.
Internet-Draft -- draft-bless-diffserv-lbe-phb-00.txt, Sept. 1999.
[5] R. Braden, S. Berson, S. Herzog, S. Jamin, and L. Zhang. Resource
ReSerVation Protocol (RSVP) -- Version 1. RFC 2205, Sept. 1997.
[6] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, A. Helmy,
D. Meyer, and L. Wei. Protocol independent multicast version 2
dense mode specification. Internet-Draft --
draft-ietf-pim-v2-dm-03.txt, June 1999.
[7] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering,
M. Handley, V. Jacobson, C. gung Liu, P. Sharma, and L. Wei.
Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
Specification. RFC 2362, June 1998.
[8] V. Jacobson, K. Nichols, and K. Poduri. An Expedited Forwarding
PHB. RFC 2598, June 1999.
[9] V. Jacobson, K. Nichols, and L. Zhang. A Two-bit Differentiated
Services Architecture for the Internet. RFC 2638, July 1999.
[10] T. Pusateri. Distance Vector Multicast Routing Protocol.
Internet-Draft -- draft-ietf-idmr-dvmrp-v3-08.txt, Feb. 1999.
Bless & Wehrle Expires: March 2000 [Page 15]
Internet-Draft IP Multicast in DiffServ Networks September 1999
[11] D. Waitzman, C. Partridge, and S. Deering. Distance Vector
Multicast Routing Protocol. RFC 1075, Nov. 1988.
6 Authors' addresses
Comments and questions related to this document 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 6396
bless@telematik.informatik.uni-karlsruhe.de
Klaus Wehrle
Institute of Telematics
Universitaet Karlsruhe (TH)
Zirkel 2
D-76128 Karlsruhe, Germany
Tel.: +49 721 608 6414
wehrle@telematik.informatik.uni-karlsruhe.de
Bless & Wehrle Expires: March 2000 [Page 16]