One document matched: draft-karagiannis-ru-pdb-02.txt
Differences from draft-karagiannis-ru-pdb-01.txt
INTERNET-DRAFT Georgios Karagiannis
University of Twente / Ericsson
L. Westberg
A. Bader
Ericsson
Hannes Tschofenig
Siemens
June 23, 2006
Resource Unavailability (RU) Per Domain Behavior
draft-karagiannis-ru-pdb-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 23, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Karagiannis, et al. [Page 1]
INTERNET-DRAFT RU-PDB
Abstract
This draft specifies a Per Domain Behavior that provides the ability
to Diffserv nodes located outside Diffserv domain(s), e.g., receiver
or other Diffserv enabled router to detect when the resources
provided by the Diffserv domain(s) are not available. This PDB is
used when the negotiated SLS is associated to throughput (or
bandwidth) and when the SLS agreed throughput bound is not
statically but loosely defined in order to allow a more efficient
utilization of the Diffserv domain(s) and a simpler network
management operation. This PDB can be applied in association with
either a single Diffserv domain or multiple neighboring Diffserv
domains. This specification is denoted as Resource Unavailability
(RU) PDB and it follows the guidelines given in RFC 3086.
Table of Contents
1. Introduction. . . . .. . . . . . . . . . . . . . . . . . . . . .3
1.1 Applicability. . . . .. . . . . . . . . . . . . . . . . . . . .3
2. Terminology . . . . .. . . . . . . . . . . . . . . . . . . . . .3
3. TCS and PHB configurations . . . . .. . . . . . . . . . . . . . 3
4. Attributes of this PDB . . . . .. . . . . . . . . . . . . . . . 6
5. Parameters . . . . .. . . . . . . . . . . . . . . . . . . . . . 6
6. Assumptions . . . . .. . . . . . . . . . . . . . . . . . . . . .6
7. Example uses . . . . .. . . . . . . . . . . . . . . . . . . . ..7
8. Envinronmental concerns . . . . .. . . . . . . . . . . . . . . 10
9. Security considerations . . . . .. . . . . . . . . . . . . . .10
10 IANA considerations. . .. . . . . . . . . . . . . . . . . . . .10
11.Acknowledgments . . . . .. . . . . . . . . . . . . . . . . . . 10
12.Normative References . . . . .. . . . . . . . . . . . . . . . .11
13.Informative References . . . . .. . . . . . . . . . . . . . . .11
Karagiannis, et al. [Page 2]
INTERNET-DRAFT RU-PDB
1. Introduction
1.1 Applicability
The RU PDB can be applied in the situation where Diffserv nodes
located outside Diffserv domain(s) must detect when
the resources provided by the Diffserv domain(s) are not available.
This PDB is used when the negotiated SLS is associated to throughput
(or bandwidth) and when the SLS agreed throughput bound is not
statically but loosely defined. The main purpose of loosely defining
the SLS throughput bound is to allow a more efficient utilization of
the Diffserv domain(s) and a more simple network management
operation. This PDB can be applied in association with either a
single Diffserv domain or multiple neighboring Diffserv domains,
when SLA agreements exist between the operator(s) of these Diffserv
domains.
The resource unavailability on the Diffserv nodes within the
Diffserv domain(s) can be detected using a DSCP remarking approach
where the remarking is proportional to the amount of unavailable
resources.
The Diffserv nodes located outside the Diffserv
domain(s) can use the remarked DSCP packets to calculate the
percentage of throughput (or bandwidth) that does exceed the loosely
agreed SLS throughput bound.
These nodes can then, in combination with the sender of the traffic
and the support of the Diffserv domain(s), reduce the generated
throughput until the loosely agreed SLS throughput bound is
satisfied. Possible applicability areas on using the remarked DSCP
packets/bytes are related to the support of final handling
decisions on the admission control and/or rate control of ongoing
calls/flows.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119].
3. TCS and PHB Configuration
Packets using any PHB can receive the RU PDB treatment. Furthermore,
the RU PDB can be used in combination with any other defined PDB.
Karagiannis, et al. [Page 3]
INTERNET-DRAFT RU-PDB
3.1. Diffserv Source End System Configuration
The Diffserv source end systems, which support
the RU PDB, ensure that the packets are being marked with the right
PHB. Note that the process of marking can be specified by another
PDB. In this text, for simplicity reasons, the PDB that is defining
the PHB marking is denoted as another_PDB. For each of the chosen
PHB, the TCS and PHB configurations associated with the RU PDB are
following the rules defined by another_PDB, which MAY use the
specifications provided in [RFC2474], [RFC2475], [RFC3246],
[RFC2597] and [RFC3290].
3.2 Common Diffserv node configurations
The Diffserv nodes, which are supporting the RU-PDB, must perform
the following functionalities:
Meter + Policing Action: the Diffserv nodes must be configured with
a policing function that remarks bytes that are out of a configured
traffic profile (e.g., bandwidth threshold) for a corresponding PHB
traffic class, to provide and indication of a potential resource
limitation to a Diffserv node outside the domain. The traffic profile
can be set according to an engineered bandwidth limitation based SLA
or based on a capacity limitation of specific links. By using an
algorithm that calculates the rate of bytes that are out of profile,
say rate_out_profile_bytes, a number of bytes, i.e.,
rate_out_profile_bytes/N, are remarked to a second DSCP, denoted in
this example as local_DSCP, that receives the same PHB as the
original DSCP. "N" is a pre-configured parameter used to indicate the
proportionality between the measured out of profile bytes and the
remarked bytes. If "N" is used in the algorithm, then it must have
the same value in all Diffserv nodes that use this mechanism.
Classify: The Diffserv node SHOULD be configured to consider that
the packets marked either with the original_DSCP or with the
local_DSCP SHOULD receive the same per hop behavior treatment.
However, packets that are marked with the local_DSCP, may be
classified to enter a different and larger virtual queue than the
packets marked with original_DSCP. This can ensure that the dropping
probability of local_DSCP remarked packets is lower than the
dropping probability of original_DSCP remarked packets. This
classification can be accomplished by the Classify function.
Karagiannis, et al. [Page 4]
INTERNET-DRAFT RU-PDB
The classification of packets SHOULD be based on either the DSCP or
on a combination of IP header fields including the DSCP.
When a packet is received by the edge router of another domain (new
Diffserv domain, that might be managed by another operator),
remarking of the original_DSCP and local_DSCP to other DSCPs, say
original_new_DSCP and local_new_DSCP might be necessary. This is
because the neighbor DSCP operator may use different Diffserv mapping
schemes. It is however, considered that SLA agreements exist between
the operator(s) of these Diffserv domains, thus also the remarking
rules followed in each Diffserv domain are known. Note that the
Diffserv nodes used in the neigbouring Diffserv domains should use
the same classification, meter and policing actions as described
above.
3.3. Configuration of nodes outside the Diffserv domain(s)
When the Diffserv nodes located outside Diffserv domain(s), e.g.,
receiver Diffserv enabled end systems, receive the remarked packets,
the rate of the receiving marked bytes, per each flow aggregate, is
measured. Note that the calculated rate has to be corrected and
multiplied with the parameter "N", see above, in order to calculate
the real rate of overload, say real_rate_overload. This rate can be
use to provide handling decisions on the resource unavailability
functionality. Two types of handling decisions could be supported.
When only one pre-configured bandwidth threshold is maintained by
this Diffserv node, say Threshold1, then if the calculated rate of
remarked bytes is higher than Threshold1, i.e., real_rate_overload >
Threshold1, then the Diffserv node can use this information to
provide the basis of call admission decisions for new flows. Note
that how the admission decision process on call level operates is
out of the scope of this draft.
When two pre-configured bandwidth thresholds are used, i.e.,
Threshold1 and Threshold2, with Threshold2 > Threshold1, then the
Diffserv node should operate in the following way. When the
calculated rate, real_rate_overload > Threshold1 then the same
procedure as described above is used (situation that only one
threshold is used). When the calculated rate is higher than
Threshold 2, then the Diffserv node can use procedures that are out
the scope of this draft, to send notifications to ongoing sessions to
enforce rate control. Note that Threshold2 is used in the case that
a persistent congestion situation occurs and ongoing calls have to be
notified about it.
Note that the flow aggregates are defined by source IP addres ranges
The size of the aggregates should be large enough to ensure that new
calls belong to aggregates where ongoing calls provide feedback for
admission control decisions.
Karagiannis, et al. [Page 5]
INTERNET-DRAFT RU-PDB
4. Attributes of this PDB
The new attributes that are related to this PDB are related to the
agreed SLS traffic profiles, e.g., bandwidth thresholds.
Different agreed SLS throughput thresholds, see Section 3, might be
used. Each of these throughput (bandwidth) thresholds are compared
to the calculated rate of remarked packets/bytes..
5. Parameters
The used parameters are the SLS traffic profiles and bandwidth
thresholds.
6. Assumptions
The negotiated SLA may include either one pre-configured loosely
agreed SLS throughput (bandwidth) threshold or two pre-configured
loosely agreed SLS throughput (bandwidth) thresholds (bound). It is
assumed that the network operator communicates these throughput
(bandwidth) thresholds from the location of where the SLS
parameters are maintained up to the Diffserv nodes within the
Diffserv domain(s).
The RU PDB can be applied on more than one neighboring Diffserv
Domains, when SLA agreements exist between the operator(s) of these
Diffserv domains. Therefore, it is possible that that a marked packet
can be received by the edge router of a new neighboring Diffserv
domain (and thus new domain operator). The new Diffserv domain may
use another type of Diffserv remarking scheme. Thus the original_DSCP
and local_DSCP, may be remarked to other DSCP. However, the network
operator MUST configure the Diffserv remarking scheme such that the
semantics and relations between the original_DSCP and local_DSCP
remain even when packets using the RU PDB are passing via multiple
neighboring Diffserv domains.
Furthermore, a network operator may configure Diffserv nodes located
outside Diffserv domain(s) to provide final handling decisions on
the resource unavailability and/or overload situation process, see
Section 3.3.
If the parameter "N"" is used in the algorithm, then it must have the
same value in all Diffserv nodes that use this mechanism. "N" is a
pre-configured parameter used to indicate the proportionality between
the measured out of profile bytes and the remarked bytes.
A domain that does not support the remarking procedures described in
this document should convey DSCP information without any
modification.
Karagiannis, et al. [Page 6]
INTERNET-DRAFT RU-PDB
A domain that applies tunneling techniques (MPLS or IP) and does not
support the remarking procedures described in this document, should
use the Diffserv marking of the inner header when the header of the
tunnel is removed. Furthermore, the domain should set the outer
header at the entry of the tunnel based on the DS field of the IP
packet and map the outer header to the DS field of the IP packet at
the end of the tunnel. In MPLS the original_DSCP or local_DSCP should
be mapped to different EXP codepoint (Experimental field of MPLS
header). In IP, original_DSCP or local_DSCP should be written to the
DS field of outer header.
7. Example uses
This section gives an example of how the RU-PDB can be used in a
mobile system, and in particular in the wired parts of cellular
systems, such as the IP Diffserv based backbone.
Note however, that this example can be applied in any IP based
Diffserv scenario that supports real-time applications, which use
media codecs, and that do not have the benefit of being totally free
in selecting/producing bit-rates. Many media codecs are only able to
produce certain steps in bit-rate. They are also commonly looked to
certain packet rates or transmission intervals to achieve good
performance. There is also the issue that the actually change of
bit-rate, and thus quality level, is noticeable and disturbing to the
consumer of the media. Which combined results in that bit-rate
changes usually needs to be done as seldom as possible and may only
be done in steps, sometimes quite large steps. In this situation, in
order to achieve the best possible behavior it would be very
beneficial if the sending application would know with a relatively
high probability that the higher bit-rate would be supported before
even trying to utilize it. The real time application can then make
use of two mechanisms.
First, during admission control, the real time application claims a
high percentage, say 70%, of the bandwidth required to operate at a
minimum acceptable level from the point of view of the end user.
This mechanism can be accomplished by using the described in this
document RU-PDB.
Karagiannis, et al. [Page 7]
INTERNET-DRAFT RU-PDB
Second, for the rest of the bandwidth, say 30%, required by the
application, the sending application could increase the bit-rate and
thus the quality level, when it will know with a high probability
that the higher bit-rate would be end to end supported. This
mechanism can be accomplished by using ECN response specified in
[RFC3168], which will provide real-time media applications with a
basic tool for adaptation. If the receiver detects packets marked
with Congestion Experienced (CE), it can use that in its adaptation
mechanism to reduce bandwidth, by reporting the event to the sender.
This is accomplished in the same way as a packet loss would have been
notified. However with the benefit that the payload carried by the
packet was not lost, which improves the media quality by reducing
the number of lost payloads.
A possible way of achieving this is that the sender will increase the
transmitted rate, step-by step. For example, during each step the
bandwidth could be increased by 5%. If during each step the receiver
detects packets marked with Congestion Experienced (CE), it can then
use the information in its adaptation mechanism to reduce the
increased bandwidth, by reporting the event to the sender.
In the remaining part of this section, more details are given on how
the RU-PDB can perform the first mechanism described above, which
can be used in a mobile system, and in particular in the IP Diffserv
based backbone of cellular systems. It is considered however, that
also the second mechanism, which uses the ECN response is also
applied, but it will not be explained in this example.
Usually in such a system, a Media Gateway is used between a sender
and a receiver of a real time media application, see Figure 1. Note
that such an entity can usually perform media transcoding functions.
(SLA) (SLA) Media
| | Gateway
Source Edge V Edge Interior Edge V Edge (CAC) Receiver
| | | | | | | |
| C | data | data | | | |
| data C#marked | | | | | |
|------>C------->|------->|--------|------->|------->| |
| #unmarked| | | | | |
| |------->|------->|------->|------->|------->|------->|
Figure: 1 Admission control (CAC) using RU-PDB
It is considered in this example that the assumptions described in
Section 6 are valid. In particular, it is assumed that the
negotiated SLA includes one pre configured loosely agreed SLS
throughput (bandwidth) threshold required by the real time
application to operate at a minimum acceptable level from the
point of view of the end user.
Karagiannis, et al. [Page 8]
INTERNET-DRAFT RU-PDB
In order to provide admission control, a Call Admission Control (CAC)
function has to be supported by a node outside the Diffserv domain,
that in this example is the Media Gateway, see Figure 1. Note that
the way of how the CAC function is applied to admit or reject a flow
is out of the scope of this example.
The example will be described in steps:
(1) An IP packet is sent from the source towards the receiver. Note
that all packets will pass through the Media Gateway. The packets
are Diffserv marked to receive a relative high level of QoS, e.g.,
with Expedited Forwarding (EF). The packet is received by the first
edge router. The edge router monitors to see if this packet is
out-of-profile. If the edge, see Figure 1, realizes that a packet
is out-of-profile, then the packet is marked to a second (local)
DSCP, say local_EF DSCP. Note that the traffic profile of the
policing function available in each node should be lower than the
bandwidth agreed in the SLA or the bandwidth available for EF
traffic on links. The bandwidth between profiles provides an
interval where feedback on the resource availability is already
sent but the actual resource limitation is not reached, which allows
the Media Gateway CAC function to interpret the resource
unavailability notification and block new calls before reaching
congestion. Furthermore, note that the Diffserv scheduling in
routers is configured to use the same physical queue for packets
marked with the original DSCP (EF) and with the local DSCP (local_EF
DSCP). Note however, that different virtual queues might be used, see
Section 3. The packet is then forwarded further.
(2) The packet is received by the ingress edge router of the next
domain. This domain may be new Diffserv domain, which is
administrated by a new backbone operator. The new Diffserv domain
may use a different Diffserv mapping scheme, so remarking local_EF
DSCP packets to another DSCP may be necessary. However, due to the
SLA agreements that exist between the two backbone operators, the
semantics of interpreting the new value of the local_EF DSCP will
remain. Furthermore, the same policing function that was explained
in step 1 will also be applied. The packet is then forwarded further.
(3) The packet is processed by the interior node(s) in the domain
in a similar way as described in step (1).
(4) The packet is received by the egress of the same domain. It is
processed as described in step (1).
(5) The packet is received by an ingress. It is processed as
described in step (2).
Karagiannis, et al. [Page 9]
INTERNET-DRAFT RU-PDB
(6) Marked and remarked packets are received by the CAC function of
the Media Gateway. The amount of remarked packets (local_EF DSCP)
is counted in this node to provide the basis of call admission
decisions for new flows, see Section 3.3. Note that the amount of
remarked packets is counted separately for flow aggregates, which
are defined by source IP address ranges, see Section 3.3.
(7) The packet is marked back to the original DSCP (EF) and
forwarded towards its destination.
8. Environmental concerns
There are no environmental concerns specific to this PDB. However,
depending on the the area wherein the RU PDB is applied (one
Diffserv domain or multiple neigboring domains), different
requirements have to be fulfilled by the network operators, see
Section 6.
9. Security considerations for RU PDB
There are no specific security exposures for this PDB. See the
general security considerations in [RFC2474] and [RFC2475]. Note
that when multiple Diffserv domains are using the RU-PDB, SLA
agreements should exist between the operator(s) of these multiple
neighboring Diffserv domains and therefore, it is considered that a
trust relationship exist between these domains.
10. IANA Considerations
[Editor's Note: A future version of this document will provide
instructions to IANA.]
11. Acknowledgements
We thank Kathie Nichols for reviewing this draft and providing
Useful comments.
Karagiannis, et al. [Page 10]
INTERNET-DRAFT RU-PDB
12. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[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,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC3086] Nichols, K. and B. Carpenter, "Definition of
Differentiated Services Per Domain Behaviors and Rules
For their Specification", RFC 3086, April 2001.
13 Informative References
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, A., Jamin,
S., "Resource ReSerVation Protocol (RSVP)-- Version 1
Functional Specification", IETF RFC 2205, 1997.
[RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC3290] Bernet, Y., Blake, S., Grossman, D., Smith, A., "An
Informal Management Model for Diffserv Routers", RFC 3290,
May 2002.
[RFC3246] B. Davie, et al., "An Expedited Forwarding PHB (Per-
Hop Behavior) ", RFC 3246, March 2002.
[RFC4080] Hancock, R., "Next Steps in Signaling: Framework", RFC
4080, December 2004.
Karagiannis, et al. [Page 11]
INTERNET-DRAFT RU-PDB
Authors' Addresses
Georgios Karagiannis
University of Twente
P.O. BOX 217
7500 AE Enschede, The Netherlands
EMail: g.karagiannis@ewi.utwente.nl
Lars Westberg
Ericsson Research
Kistagangen 26
SE-164 80 Stockholm
Sweden
EMail: Lars.Westberg@ericsson.com
Attila Bader
Ericsson Research
Ericsson Hungary Ltd.
Laborc 1, Budapest, H-1037
Hungary
EMail: Attila.Bader@ericsson.com
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
EMail: Hannes.Tschofenig@siemens.com
Intellectual Property Statement
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.
Karagiannis, et al. [Page 12]
INTERNET-DRAFT RU-PDB
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.
Disclaimer of Validity
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.
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.
| PAFTECH AB 2003-2026 | 2026-04-24 05:53:33 |