5. Additional Information on Service Class Usage
In this section, we provide additional information on how some
specific applications should be configured to use the defined service
5.1. Mapping for Signaling
There are many different signaling protocols, ways that signaling is
used and performance requirements from applications that are
controlled by these protocols. We believe that different signaling
protocols should use the service class that best meets the objectives
of application or service they control. The following mapping is
o Peer-to-peer signaling using SIP/H.323 is marked with CS5 DSCP
(use Signaling service class).
o Client-server signaling as used in many implementation for IP
telephony using H.248, MEGACO, MGCP, IP encapsulated ISDN, or
proprietary protocols is marked with CS5 DSCP (use Signaling
o Signaling between call servers or soft-switches in carrier's
network using SIP, SIP-T, or IP encapsulated ISUP is marked with
CS5 DSCP (use Signaling service class).
o RSVP signaling depends on the application. If RSVP signaling is
"on-path" as used in IntServ, then it needs to be forwarded from
the same queue (service class) and marked with the same DSCP value
as application data that it is controlling. This may also apply
to the "on-path" Next Steps in Signaling (NSIS) protocol.
o If IGMP is used for multicast session control such as channel
changing in IPTV systems, then IGMP packets should be marked with
CS5 DSCP (use Signaling service class). When IGMP is used only
for the normal multicast routing purpose, it should be marked with
CS6 DSCP (use Network Control service class).
5.2. Mapping for NTP
From tests that were performed, indications are that precise time
distribution requires a very low packet delay variation (jitter)
transport. Therefore, we suggest that the following guidelines for
Network Time Protocol (NTP) be used:
o When NTP is used for providing high-accuracy timing within an
administrator's (carrier's) network or to end users/clients, the
Telephony service class should be used, and NTP packets should be
marked with EF DSCP value.
o For applications that require "wall clock" timing accuracy, the
Standard service class should be used, and packets should be
marked with DF DSCP.
5.3. VPN Service Mapping
"Differentiated Services and Tunnels" [RFC2983] considers the
interaction of DiffServ architecture with IP tunnels of various
forms. Further to guidelines provided in RFC 2983, below are
additional guidelines for mapping service classes that are supported
in one part of the network into a VPN connection. This discussion is
limited to VPNs that use DiffServ technology for traffic
o The DSCP value(s) that is/are used to represent a PHB or a PHB
group should be the same for the networks at both ends of the VPN
tunnel, unless remarking of DSCP is done as ingress/egress
processing function of the tunnel. DSCP marking needs to be
preserved end to end.
o The VPN may be configured to support one or more service classes.
It is left up to the administrators of the two networks to agree
on the level of traffic differentiation that will be provided in
the network that supports VPN service. Service classes are then
mapped into the supported VPN traffic forwarding behaviors that
meet the traffic characteristics and performance requirements of
the encapsulated service classes.
o The traffic treatment in the network that is providing the VPN
service needs to be such that the encapsulated service class or
classes receive comparable behavior and performance in terms of
delay, jitter, and packet loss and that they are within the limits
of the service specified.
o The DSCP value in the external header of the packet forwarded
through the network providing the VPN service may be different
from the DSCP value that is used end to end for service
differentiation in the end network.
o The guidelines for aggregation of two or more service classes into
a single traffic forwarding treatment in the network that is
providing the VPN service is for further study.
6. Security Considerations
This document discusses policy and describes a common policy
configuration, for the use of a Differentiated Services Code Point by
transports and applications. If implemented as described, it should
require that the network do nothing that the network has not already
allowed. If that is the case, no new security issues should arise
from the use of such a policy.
It is possible for the policy to be applied incorrectly, or for a
wrong policy to be applied in the network for the defined service
class. In that case, a policy issue exists that the network SHOULD
detect, assess, and deal with. This is a known security issue in any
network dependent on policy-directed behavior.
A well-known flaw appears when bandwidth is reserved or enabled for a
service (for example, voice transport) and another service or an
attacking traffic stream uses it. This possibility is inherent in
DiffServ technology, which depends on appropriate packet markings.
When bandwidth reservation or a priority queuing system is used in a
vulnerable network, the use of authentication and flow admission is
recommended. To the author's knowledge, there is no known technical
way to respond to an unauthenticated data stream using service that
it is not intended to use, and such is the nature of the Internet.
The use of a service class by a user is not an issue when the SLA
between the user and the network permits him to use it, or to use it
up to a stated rate. In such cases, simple policing is used in the
Differentiated Services Architecture. Some service classes, such as
Network Control, are not permitted to be used by users at all; such
traffic should be dropped or remarked by ingress filters. Where
service classes are available under the SLA only to an authenticated
user rather than to the entire population of users, authentication
and authorization services are required, such as those surveyed in
The authors thank the TSVWG reviewers, David Black, Brian E.
Carpenter, and Alan O'Neill for their review and input to this
The authors acknowledge a great many inputs, most notably from Bruce
Davie, Dave Oran, Ralph Santitoro, Gary Kenward, Francois Audet,
Morgan Littlewood, Robert Milne, John Shuler, Nalin Mistry, Al
Morton, Mike Pierce, Ed Koehler Jr., Tim Rahrer, Fil Dickinson, Mike
Fidler, and Shane Amante. Kimberly King, Joe Zebarth, and Alistair
Munroe each did a thorough proofreading, and the document is better
for their contributions.
8. Appendix A
8.1. Explanation of Ring Clipping
The term "ring clipping" refers to those instances where the front
end of a ringing signal is altered because the bearer channel is not
made available in time to carry all the audible ringing signal. This
condition may occur due to a race condition between when the tone
generator located in the circuit switch Exchange is turned on and
when the bearer path through the IP network is enabled. To reduce
ring clipping from occurring, delay of signaling path needs to be
minimized. Below is a more detailed explanation.
The bearer path setup delay target is defined as the ISUP Initial
Address Message (IAM) / Address Complete Message (ACM) round-trip
delay. ISUP refers to ISDN User Part of Signaling System No. 7
(SS7), as defined by ITU-T. This consists of the amount of time it
takes for the ISUP Initial Address Message (IAM) to leave the Transit
Exchange, travel through the SS7 network (including any applicable
STPs, or Signaling Transfer Points), and be processed by the End
Exchange thus generating the Address Complete Message (ACM) and for
the ACM to travel back through the SS7 network and return to the
Transit Exchange. If the bearer path has not been set up within the
soft-switch media gateway and the IP network that is performing the
Transit Exchange function by the time the ACM is forwarded to the
originating End Exchange, the phenomenon known as ring clipping may
occur. If ACM processing within the soft-switch media gateway and
delay through the IP network is excessive, it will delay the setup of
the bearer path, and therefore may cause clipping of the ring tone to
The intra-exchange ISUP IAM signaling delay value should not exceed
240ms. This may include soft-switch, media gateway, router, and
propagation delay on the inter-exchange data path. This value
represents the threshold where ring clipping theoretically commences.
It is important to note that the 240ms delay objective as presented
is a maximum value. Service administrators are free to choose
specific IAM delay values according to their own preferences (i.e.,
they may wish to set a very low mean delay objective for strategic
reasons to differentiate themselves from other providers). In
summary, out of the 240-ms delay budget, 200ms is allocated as
cross-Exchange delay (soft-switch and media gateway) and 40ms for
network delay (queuing and distance).
9.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC1349] Almquist, P., "Type of Service in the Internet Protocol
Suite", RFC 1349, July 1992.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
S., Wroclawski, J., and L. Zhang, "Recommendations on
Queue Management and Congestion Avoidance in the
Internet", RFC 2309, April 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Service", RFC 2475, December 1998.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC3246] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le
Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002.
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
Per-Domain Behavior (PDB) for Differentiated Services",
RFC 3662, December 2003.
9.2. Informative References
[AUTHMECH] Rescorla, E., "A Survey of Authentication Mechanisms",
Work in Progress, September 2005.
[QBSS] "QBone Scavenger Service (QBSS) Definition", Internet2
Technical Report Proposed Service Definition, March 2001.
[RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview", RFC
1633, June 1994.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color
Marker", RFC 2697, September 1999.
[RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color
Marker", RFC 2698, September 1999.
[RFC2963] Bonaventure, O. and S. De Cnodder, "A Rate Adaptive Shaper
for Differentiated Services", RFC 2963, October 2000.
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC
2983, October 2000.
[RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996,
[RFC3086] Nichols, K. and B. Carpenter, "Definition of
Differentiated Services Per Domain Behaviors and Rules for
their Specification", RFC 3086, April 2001.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC
3168, September 2001.
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC
3175, September 2001.
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An
Informal Management Model for Diffserv Routers", RFC 3290,
[RFC3782] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno
Modification to TCP's Fast Recovery Algorithm", RFC 3782,
3500 Carling Avenue
Ottawa, Ont. K2H 8E9
Kwok Ho Chan
600 Technology Park Drive
Billerica, MA 01821
1121 Via Del Rey
Santa Barbara, CA 93117
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).