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