Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4594

Configuration Guidelines for DiffServ Service Classes

Pages: 57
Informational
Errata
Updated by:  58658622
Part 4 of 4 – Pages 49 to 57
First   Prev   None

Top   ToC   RFC4594 - Page 49   prevText

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).
Top   ToC   RFC4594 - Page 50
   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.
Top   ToC   RFC4594 - Page 51
   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
Top   ToC   RFC4594 - Page 52
   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.
Top   ToC   RFC4594 - Page 53

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).
Top   ToC   RFC4594 - Page 54

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.
Top   ToC   RFC4594 - Page 55

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.
Top   ToC   RFC4594 - Page 56
   [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
Top   ToC   RFC4594 - Page 57
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).