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
   classes.

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
   recommended:

   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
      service class).
   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
   differentiation.

   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
   [AUTHMECH].

7.  Acknowledgements

   The authors thank the TSVWG reviewers, David Black, Brian E.
   Carpenter, and Alan O'Neill for their review and input to this
   document.

   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
   be heard.

   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.  References

9.1.  Normative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
              1981.

   [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
              1998.

   [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,
              November 2000.

   [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,
              May 2002.

   [RFC3782]  Floyd, S., Henderson, T., and A. Gurtov, "The NewReno
              Modification to TCP's Fast Recovery Algorithm", RFC 3782,
              April 2004.

Authors' Addresses

   Jozef Babiarz
   Nortel Networks
   3500 Carling Avenue
   Ottawa, Ont.  K2H 8E9
   Canada

   Phone: +1-613-763-6098
   Fax:   +1-613-765-7462
   EMail: babiarz@nortel.com


   Kwok Ho Chan
   Nortel Networks
   600 Technology Park Drive
   Billerica, MA  01821
   US

   Phone: +1-978-288-8175
   Fax:   +1-978-288-8700
   EMail: khchan@nortel.com


   Fred Baker
   Cisco Systems
   1121 Via Del Rey
   Santa Barbara, CA  93117
   US

   Phone: +1-408-526-4257
   Fax:   +1-413-473-2403
   EMail: fred@cisco.com

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.

Intellectual Property

   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
   http://www.ietf.org/ipr.

   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
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).