such a manner that they can be recovered at the egress of the
Diffserv network region. The Diffserv network region may, but is not
required to, process these messages. Mechanisms for transparently
carrying RSVP messages across a transit network are described in
[3,6,15,16].
To meet these requirements, additional work is required in the areas
of:
1. Mapping Intserv style service specifications to services that can
be provided by Diffserv network regions.
2. Definition of the functionality required in network elements to
support RSVP signaling with aggregate traffic control (for network
elements residing in the Diffserv network region).
3. Definition of mechanisms to efficiently and dynamically provision
resources in a Diffserv network region (e.g., aggregated RSVP,
tunneling, MPLS, etc.). This might include protocols by which an
"oracle" conveys information about resource availability within a
Diffserv region to border routers. One example of such a mechanism
is the so-called "bandwidth broker" proposed in [19,20,21].
5.2 Protection of Intserv Traffic from Other Traffic
Network administrators must be able to share resources in the
Diffserv network region between three types of traffic:
a. End-to-end Intserv traffic. This is typically traffic associated
with quantitative QoS applications. It requires a specific quantity
of resources with a high degree of assurance.
b. Non-Intserv traffic. The Diffserv region may allocate resources
to traffic that does not make use of Intserv techniques to quantify
its requirements, e.g., through the use of static provisioning and
SLSs enforced at the edges of the region. Such traffic might be
associated with applications whose QoS requirements are not readily
quantifiable but which require a "better than best-effort" level of
service.
c. All other (best-effort) traffic. These three classes of traffic
must be isolated from each other by the appropriate configuration of
policers and classifiers at ingress points to the Diffserv network
region, and by appropriate provisioning within the Diffserv network
region. To provide protection for Intserv traffic in Diffserv
regions of the network, we suggest that the DSCPs assigned to such
traffic not overlap with the DSCPs assigned to other traffic.
6. Multicast
The use of integrated services over Diffserv networks is
significantly more complex for multicast sessions than for unicast
sessions. With respect to a multicast connection, each participating
region has a single ingress router and zero, one or several egress
routers. The difficulties of multicast are associated with Diffserv
regions that contain several egress routers. (Support of multicast
functionality outside the Diffserv region is relatively
straightforward since every Intserv-capable router along the
multicast tree stores state for each flow.)
Consider the following reference network:
Non-Diffserv region 2
________
/ \
| | |---|
________ _____________ | |-|Rx1|
/ \ / |--\ |---| | |---|
/ \ / /|BR2\-----\ER2| /
|---| | |---| |---| |--|/ |---| \--|____/
|Tx |-| |ER1|---|BR1|--|RR| | ________
|---| | |-- | |---| |--|\ |---| /--| \
\ / \ \|BR3/-----|ER3| | |---|
\________/ \__________|--/ |---| |-|Rx2|
| | |---|
Non-Diffserv region 1 Diffserv region \ /
\______/
Non-Diffserv region 3
Figure 2: Sample Multicast Network Configuration
The reference network is similar to that of Figure 1. However, in
Figure 2, copies of the packets sent by Tx are delivered to several
receivers outside of the Diffserv region, namely to Rx1 and Rx2.
Moreover, packets are copied within the Diffserv region in a "branch
point" router RR. In the reference network BR1 is the ingress router
to the Diffserv region whereas BR2 and BR3 are the egress routers.
In the simplest case the receivers, Rx1 and Rx2 in the reference
network, require identical reservations. The Diffserv framework [18]
supports service level specifications (SLS) from an ingress router to
one, some or all of the egress routers. This calls for a "one to
many" SLS within the Diffserv region, from BR1 to BR2 and BR3. Given
that the SLS is granted by the Diffserv region, the ingress router
BR1, or perhaps an upstream node such as ER1, marks packets entering
the Diffserv region with the appropriate DSCP. The packets are
routed to the egresses of the Diffserv domain using the original
multicast address.
The two major problems, explained in the following, are associated
with heterogeneous multicast trees containing branch points within
the Diffserv region, i.e., multicast trees where the level of
resource requirement is not uniform among all receivers. An example
of such a scenario in the network of Figure 2 is the case where both
Rx1 and Rx2 need to receive multicast data from Tx1 but only one of
the receivers has requested a level of service above best effort. We
consider such scenarios in the following paragraphs.
6.1 Remarking of packets in branch point routers
In the above scenario, the packets that arrive at BR1 are marked with
an appropriate DSCP for the requested Intserv service and are sent to
RR. Packets arriving at the branch point must be sent towards BR2
with the same DSCP otherwise the service to Rx1 is degraded.
However, the packets going from RR towards BR3 need not maintain the
high assurance level anymore. They may be demoted to best effort so
that the QoS provided to other packets along this branch of the tree
is not disrupted. Several problems can be observed in the given
scenario:
- In the Diffserv region, DSCP marking is done at edge routers
(ingress), whereas a branch point router might be a core
router, which does not mark packets.
- Being a core Diffserv router, RR classifies based on
aggregate traffic streams (BA), as opposed to per flow (MF)
classification. Hence, it does not necessarily have the
capability to distinguish those packets which belong to a
specific multicast tree and require demotion from the other
packets in the behavior aggregate, which carry the same DSCP.
- Since RR may be RSVP-unaware, it may not participate in the
admission control process, and would thus not store any per-
flow state about the reservations for the multicast tree.
Hence, even if RR were able to perform MF classification and
DSCP remarking, it would not know enough about downstream
reservations to remark the DSCP intelligently.
These problems could be addressed by a variety of mechanisms. We
list some below, while noting that none is ideal in all cases and
that further mechanisms may be developed in the future:
1. If some Intserv-capable routers are placed within the Diffserv
region, it might be possible to administer the network topology and
routing parameters so as to ensure that branch points occur only
within such routers. These routers would support MF classification
and remarking and hold per-flow state for the heterogeneous
reservations for which they are the branch point. Note that in this
case, branch point routers would have essentially the same
functionality as ingress routers of an RSVP-aware Diffserv domain.
2. Packets sent on the "non-reserved" branch (from RR towards BR3)
are marked with the "wrong" DSCP; that is, they are not demoted to
best effort but retain their DSCP. This in turn requires over
reservation of resources along that link or runs the risk of
degrading service to packets that legitimately bear the same DSCP
along this path. However, it allows the Diffserv routers to remain
free of per-flow state.
3. A combination of mechanism 1 and 2 may be an effective compromise.
In this case, there are some Intserv-capable routers in the core of
the network, but the network cannot be administered so that ALL
branch points fall at such routers.
4. Administrators of Diffserv regions may decide not to enable
heterogeneous sub-trees in their domains. In the case of different
downstream reservations, a ResvErr message would be sent according to
the RSVP rules. This is similar to the approach taken for Intserv
over IEEE 802 Networks [2,5].
5. In [3], a scheme was introduced whereby branch point routers in
the interior of the aggregation region (i.e., the Diffserv region)
keep reduced state information regarding the reservations by using
measurement based admission control. Under this scheme, packets are
tagged by the more knowledgeable Intserv edges routers with
scheduling information that is used in place of the detailed Intserv
state. If the Diffserv region and branch point routers are designed
following that framework, demotion of packets becomes possible.
6.2 Multicast SLSs and Heterogeneous Trees
Multicast flows with heterogeneous reservations present some
challenges in the area of SLSs. For example, a common example of an
SLS is one where a certain amount of traffic is allowed to enter a
Diffserv region marked with a certain DSCP, and such traffic may be
destined to any egress router of that region. We call such an SLS a
homogeneous, or uniform, SLS. However, in a multicast environment, a
single packet that is admitted to the Diffserv region may consume
resources along many paths in the region as it is replicated and
forwarded towards many egress routers; alternatively, it may flow
along a single path. This situation is further complicated by the
possibility described above and depicted in Figure 2, in which a
multicast packet might be treated as best effort along some branches
while receiving some higher QOS treatment along others. We simply
note here that the specification of meaningful SLSs which meet the
needs of heterogeneous flows and which can be met be providers is
likely to be challenging.
Dynamic SLSs may help to address these issues. For example, by using
RSVP to signal the resources that are required along different
branches of a multicast tree, it may be possible to more closely
approach the goal of allocating appropriate resources only where they
are needed rather than overprovisioning or underprovisioning along
certain branches of a tree. This is essentially the approach
described in [15].
7. Security Considerations
7.1 General RSVP Security
We are proposing that RSVP signaling be used to obtain resources in
both Diffserv and non-Diffserv regions of a network. Therefore, all
RSVP security considerations apply [9]. In addition, network
administrators are expected to protect network resources by
configuring secure policers at interfaces with untrusted customers.
7.2 Host Marking
Though it does not mandate host marking of the DSCP, our proposal
does allow it. Allowing hosts to set the DSCP directly may alarm
network administrators. The obvious concern is that hosts may
attempt to "steal" resources. In fact, hosts may attempt to exceed
negotiated capacity in Diffserv network regions at a particular
service level regardless of whether they invoke this service level
directly (by setting the DSCP) or indirectly (by submitting traffic
that classifies in an intermediate marking router to a particular
DSCP).
In either case, it will generally be necessary for each Diffserv
network region to protect its resources by policing to assure that
customers do not use more resources than they are entitled to, at
each service level (DSCP). The exception to this rule is when the
host is known to be trusted, e.g., a server that is under the control
of the network administrators. If an untrusted sending host does not
perform DSCP marking, the boundary router (or trusted intermediate
routers) must provide MF classification, mark and police. If an
untrusted sending host does perform marking, the boundary router
needs only to provide BA classification and to police to ensure that
the customer is not exceeding the aggregate capacity negotiated for
the service level.
In summary, there are no additional security concerns raised by
marking the DSCP at the edge of the network since Diffserv providers
will have to police at their boundaries anyway. Furthermore, this
approach reduces the granularity at which border routers must police,
thereby pushing finer grain shaping and policing responsibility to
the edges of the network, where it scales better and provides other
benefits described in Section 3.3.1. The larger Diffserv network
regions are thus focused on the task of protecting their networks,
while the Intserv-capable nodes are focused on the task of shaping
and policing their own traffic to be in compliance with their
negotiated Intserv parameters.
8. Acknowledgments
Authors thank the following individuals for their comments that led
to improvements to the previous version(s) of this document: David
Oran, Andy Veitch, Curtis Villamizer, Walter Weiss, Francois le
Faucheur and Russell White.
Many of the ideas in this document have been previously discussed in
the original Intserv architecture document [10].
9. References
[1] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource Reservation Protocol (RSVP) Version 1 Functional
Specification", RFC2205, September 1997.
[2] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F. and M. Speer,
"SBM (Subnet Bandwidth Manager): A Protocol For RSVP-based
Admission Control Over IEEE 802 Style Networks", RFC2814, May
2000.
[3] Berson, S. and R. Vincent, "Aggregation of Internet Integrated
Services State", Work in Progress.
[4] Nichols, K., Jacobson, V. and L. Zhang, "A Two-bit
Differentiated Services Architecture for the Internet", RFC
2638, July 1999.
[5] Seaman, M., Smith, A., Crawley, E. and J. Wroclawski,
"Integrated Service Mappings on IEEE 802 Networks", RFC2815,
May 2000.
[6] Guerin, R., Blake, S. and Herzog, S., "Aggregating RSVP based
QoS Requests", Work in Progress.
[7] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of
the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers", RFC2474, December 1998.
[8] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W.
Weiss, "An Architecture for Differentiated Services", RFC2475,
December 1998.
[9] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic
Authentication", RFC2747, January 2000.
[10] Braden, R., Clark, D. and S. Shenker, "Integrated Services in
the Internet Architecture: an Overview", RFC1633, June 1994.
[11] Garrett, M. and M. Borden, "Interoperation of Controlled-Load
Service and Guaranteed Service with ATM", RFC2381, August 1998.
[12] Weiss, Walter, Private communication, November 1998.
[13] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC2401, November 1998.
[14] Bernet, Y., "Format of the RSVP DCLASS Object", RFC2996,
November 2000.
[15] Baker, F., Iturralde, C., le Faucheur, F., and Davie, B. "RSVP
Reservation Aggregation", Work in Progress.
[16] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang, "RSVP
Operation Over IP Tunnels", RFC2746, January 2000.
[17] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, D. and A.
Sastry, "COPS Usage for RSVP", RFC2749, January 2000.
[18] Bernet, Y., "A Framework for Differentiated Services", Work in
Progress.
[19] Jacobson Van, "Differentiated Services Architecture", talk in
the Int-Serv WG at the Munich IETF, August 1997.
[20] Jacobson, V., Nichols K. and L. Zhang, "A Two-bit Differentiated
Services Architecture for the Internet", RFC2638, June 1999.
[21] First Internet2 bandwidth broker operability event
http://www.merit.edu/internet/working.groups/i2-qbone-bb/
inter-op/index.htm
10. Authors' Addresses
Yoram Bernet
Microsoft
One Microsoft Way
Redmond, WA 98052
Phone: +1 425-936-9568
EMail: yoramb@microsoft.com
Raj Yavatkar
Intel Corporation
JF3-206 2111 NE 25th. Avenue
Hillsboro, OR 97124
Phone: +1 503-264-9077
EMail: raj.yavatkar@intel.com
Peter Ford
Microsoft
One Microsoft Way
Redmond, WA 98052
Phone: +1 425-703-2032
EMail: peterf@microsoft.com
Fred Baker
Cisco Systems
519 Lado Drive
Santa Barbara, CA 93111
Phone: +1 408-526-4257
EMail: fred@cisco.com
Lixia Zhang
UCLA
4531G Boelter Hall
Los Angeles, CA 90095
Phone: +1 310-825-2695
EMail: lixia@cs.ucla.edu
Michael Speer
Sun Microsystems
901 San Antonio Road, UMPK15-215
Palo Alto, CA 94303
Phone: +1 650-786-6368
EMail: speer@Eng.Sun.COM
Bob Braden
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292-6695
Phone: +1 310-822-1511
EMail: braden@isi.edu
Bruce Davie
Cisco Systems
250 Apollo Drive
Chelmsford, MA 01824
Phone: +1 978-244-8000
EMail: bsd@cisco.com
Eyal Felstaine
SANRAD Inc.
24 Raul Wallenberg st
Tel Aviv, Israel
Phone: +972-50-747672
Email: eyal@sanrad.com
John Wroclawski
MIT Laboratory for Computer Science
545 Technology Sq.
Cambridge, MA 02139
Phone: +1 617-253-7885
EMail: jtw@lcs.mit.edu
11. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.