draft-ietf-tewg-diff-te-mar-04.txt   draft-ietf-tewg-diff-te-mar-05.txt 
Network Working Group Jerry Ash Network Working Group Jerry Ash
Internet Draft AT&T Internet Draft AT&T
Category: Experimental Category: Experimental
<draft-ietf-tewg-diff-te-mar-04.txt> <draft-ietf-tewg-diff-te-mar-05.txt>
Expiration Date: July 2004 Expiration Date: June 2005
January, 2004 December, 2004
Max Allocation with Reservation Bandwidth Constraints Model for Max Allocation with Reservation Bandwidth Constraints Model for
DiffServ-aware MPLS Traffic Engineering & Performance Comparisons DiffServ-aware MPLS Traffic Engineering & Performance Comparisons
<draft-ietf-tewg-diff-te-mar-04.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, each author represents that any
all provisions of Section 10 of RFC 2026. 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 RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are Working documents of the Internet Engineering Task
Task Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other groups
groups may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference material
material or to cite them other than as "work in progress." or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/1id-abstracts.html.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document complements the DiffServ-aware MPLS TE (DS-TE) requirements This document complements the DiffServ-aware MPLS TE (DS-TE)
document by giving a functional specification for the Maximum Allocation requirements document by giving a functional specification for the
with Reservation (MAR) Bandwidth Constraints Model. Assumptions, Maximum Allocation with Reservation (MAR) Bandwidth Constraints Model.
applicability, and examples of the operation of the MAR Bandwidth Assumptions, applicability, and examples of the operation of the MAR
Constraints Model are presented. MAR performance is analyzed relative to Bandwidth Constraints Model are presented. MAR performance is analyzed
the criteria for selecting a Bandwidth Constraints Model, in order to relative to the criteria for selecting a Bandwidth Constraints Model, in
provide guidance to user implementation of the model in their networks. order to provide guidance to user implementation of the model in their
networks.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Assumptions & Applicability . . . . . . . . . . . . . . . . . 5 3. Assumptions & Applicability . . . . . . . . . . . . . . . . . 5
4. Functional Specification of the MAR Bandwidth Constraints Model 6 4. Functional Specification of the MAR Bandwidth Constraints Model 6
5. Setting Bandwidth Constraints . . . . . . . . . . . . . . . . 7 5. Setting Bandwidth Constraints . . . . . . . . . . . . . . . . 7
6. Example of MAR Operation . . . . . . . . . . . . . . . . . . . 7 6. Example of MAR Operation . . . . . . . . . . . . . . . . . . . 7
7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
11. Normative References . . . . . . . . . . . . . . . . . . . . 9 11. Normative References . . . . . . . . . . . . . . . . . . . . 9
12. Informative References . . . . . . . . . . . . . . . . . . . 9 12. Informative References . . . . . . . . . . . . . . . . . . . 9
13. Intellectual Property Statement . . . . . . . . . . . . . . . 10 13. Intellectual Property Considerations . . . . . . . . . . . . 10
14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11 14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11
Appendix A. MAR Operation & Performance Analysis . . . . . . . . 11 Appendix A. MAR Operation & Performance Analysis . . . . . . . . 11
Appendix B. Bandwidth Prediction for Path Computation . . . . . . 17 Appendix B. Bandwidth Prediction for Path Computation . . . . . . 17
Specification of Requirements Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1. Introduction 1. Introduction
DiffServ-aware MPLS traffic engineering (DS-TE) requirements and protocol DiffServ-aware MPLS traffic engineering (DS-TE) requirements and
extensions are specified in [DSTE-REQ, DSTE-PROTO]. A requirement for protocol extensions are specified in [DSTE-REQ, DSTE-PROTO]. A
DS-TE implementation is the specification of Bandwidth Constraints Models requirement for DS-TE implementation is the specification of Bandwidth
for use with DS-TE. The Bandwidth Constraints Model provides the 'rules' Constraints Models for use with DS-TE. The Bandwidth Constraints Model
to support the allocation of bandwidth to individual class types (CTs). provides the 'rules' to support the allocation of bandwidth to
CTs are groupings of service classes in the DS-TE model, which are individual class types (CTs). CTs are groupings of service classes in
provided separate bandwidth allocations, priorities, and QoS objectives. the DS-TE model, which are provided separate bandwidth allocations,
Several CTs can share a common bandwidth pool on an integrated, priorities, and QoS objectives. Several CTs can share a common
multiservice MPLS/DiffServ network. bandwidth pool on an integrated, multiservice MPLS/DiffServ network.
This document is intended to complement the DS-TE requirements document This document is intended to complement the DS-TE requirements document
[DSTE-REQ] by giving a functional specification for the Maximum [DSTE-REQ] by giving a functional specification for the Maximum
Allocation with Reservation (MAR) Bandwidth Constraints Model. Examples Allocation with Reservation (MAR) Bandwidth Constraints Model. Examples
of the operation of the MAR Bandwidth Constraints Model are presented. of the operation of the MAR Bandwidth Constraints Model are presented.
MAR performance is analyzed relative to the criteria for selecting a MAR performance is analyzed relative to the criteria for selecting a
Bandwidth Constraints Model, in order to provide guidance to user Bandwidth Constraints Model, in order to provide guidance to user
implementation of the model in their networks. implementation of the model in their networks.
Two other Bandwidth Constraints Models are being specified for use in Two other Bandwidth Constraints Models are being specified for use in
skipping to change at page 4, line 28 skipping to change at page 4, line 28
Traffic Trunk: an aggregation of traffic flows of the same class (i.e. Traffic Trunk: an aggregation of traffic flows of the same class (i.e.
which are to be treated equivalently from the DS-TE perspective) which which are to be treated equivalently from the DS-TE perspective) which
are placed inside an LSP. are placed inside an LSP.
Class-Type (CT): the set of Traffic Trunks crossing a link that is Class-Type (CT): the set of Traffic Trunks crossing a link that is
governed by a specific set of Bandwidth constraints. CT is used for the governed by a specific set of Bandwidth constraints. CT is used for the
purposes of link bandwidth allocation, constraint based routing and purposes of link bandwidth allocation, constraint based routing and
admission control. A given Traffic Trunk belongs to the same CT on all admission control. A given Traffic Trunk belongs to the same CT on all
links. links.
Up to 8 CTs (MaxCT = 8) are supported. They are referred to as CTc, 0 Up to 8 CTs (MaxCT = 8) are supported. They are referred to as CTc,
<= c <= MaxCT-1 = 7. Each CT is assigned either a Bandwidth 0 <= c <= MaxCT-1 = 7. Each CT is assigned either a Bandwidth
Constraint, or a set of Bandwidth Constraints. Up to 8 Bandwidth Constraint, or a set of Bandwidth Constraints. Up to 8 Bandwidth
Constraints (MaxBC = 8) are supported and they are referred to as BCc, Constraints (MaxBC = 8) are supported and they are referred to as BCc,
0 <= c <= MaxBC-1 = 7. 0 <= c <= MaxBC-1 = 7.
TE-Class: A pair of: i. a CT ii. a preemption priority allowed for that TE-Class: A pair of: a) a CT, and b) a preemption priority allowed for
CT. This means that an LSP transporting a Traffic Trunk from that CT can that CT. This means that an LSP transporting a Traffic Trunk from that
use that preemption priority as the set-up priority, as the holding CT can use that preemption priority as the set-up priority, as the
priority or both. holding priority or both.
MAX_RESERVABLE_BWk: maximum reservable bandwidth on link k specifies the MAX_RESERVABLE_BWk: maximum reservable bandwidth on link k specifies the
maximum bandwidth that may be reserved; this may be greater than the maximum bandwidth that may be reserved; this may be greater than the
maximum link bandwidth in which case the link may be oversubscribed maximum link bandwidth in which case the link may be oversubscribed
[OSPF-TE]. [OSPF-TE].
BCck: bandwidth constraint for CTc on link k = allocated (minimum BCck: bandwidth constraint for CTc on link k = allocated (minimum
guaranteed) bandwidth for CTc on link k (see Section 4). guaranteed) bandwidth for CTc on link k (see Section 4).
RBW_THRESk: reservation bandwidth threshold for link k (see Section 4). RBW_THRESk: reservation bandwidth threshold for link k (see Section 4).
skipping to change at page 5, line 26 skipping to change at page 5, line 29
increase bandwidth efficiency by sharing bandwidth across backup LSPs increase bandwidth efficiency by sharing bandwidth across backup LSPs
protecting against independent failures. To ensure that the notion of protecting against independent failures. To ensure that the notion of
RESERVED_BWck introduced in [DSTE-REQ] is compatible with such a concept RESERVED_BWck introduced in [DSTE-REQ] is compatible with such a concept
of bandwidth sharing across multiple LSPs, the wording of the definition of bandwidth sharing across multiple LSPs, the wording of the definition
provided in [DSTE-REQ] is generalized. With this generalization, the provided in [DSTE-REQ] is generalized. With this generalization, the
definition is compatible with Shared Mesh Restoration defined in definition is compatible with Shared Mesh Restoration defined in
[GMPLS-RECOV], so that DS-TE and Shared Mesh Protection can operate [GMPLS-RECOV], so that DS-TE and Shared Mesh Protection can operate
simultaneously, under the assumption that Shared Mesh Restoration simultaneously, under the assumption that Shared Mesh Restoration
operates independently within each DS-TE Class-Type and does not operate operates independently within each DS-TE Class-Type and does not operate
across Class-Types. For example, backup LSPs protecting primary LSPs of across Class-Types. For example, backup LSPs protecting primary LSPs of
CTc must also belong to CTc; excess traffic LSPs sharing bandwidth with CTc need to also belong to CTc; excess traffic LSPs sharing bandwidth
backup LSPs of CTc must also belong to CTc. with backup LSPs of CTc need to also belong to CTc.
3. Assumptions & Applicability 3. Assumptions & Applicability
In general, DS-TE is a bandwidth allocation mechanism, for different In general, DS-TE is a bandwidth allocation mechanism, for different
classes of traffic allocated to various CTs (e.g., voice, normal data, classes of traffic allocated to various CTs (e.g., voice, normal data,
best-effort data). Network operations functions such as capacity best-effort data). Network operations functions such as capacity
design, bandwidth allocation, routing design, and network planning are design, bandwidth allocation, routing design, and network planning are
normally based on traffic measured load and forecast [ASH1]. normally based on traffic measured load and forecast [ASH1].
As such, the following assumptions are made according to the operation As such, the following assumptions are made according to the operation
skipping to change at page 5, line 58 skipping to change at page 6, line 4
measured/forecast traffic load. No specific time period is assumed for measured/forecast traffic load. No specific time period is assumed for
this adjustment, it could be short term (hours), daily, weekly, monthly, this adjustment, it could be short term (hours), daily, weekly, monthly,
or otherwise. or otherwise.
4. Capacity management and CT bandwidth allocation thresholds (e.g., 4. Capacity management and CT bandwidth allocation thresholds (e.g.,
BCc) are designed according to traffic load, and are based on traffic BCc) are designed according to traffic load, and are based on traffic
measurement and forecast. Again, no specific time period is assumed for measurement and forecast. Again, no specific time period is assumed for
this adjustment, it could be short term (hours), daily, weekly, monthly, this adjustment, it could be short term (hours), daily, weekly, monthly,
or otherwise. or otherwise.
5. No assumption is made on the order in which traffic is allocated to 5. No assumption is made on the order in which traffic is allocated to
various CTs, again traffic allocation is assumed to be based only on various CTs, again traffic allocation is assumed to be based only on
traffic load as it is measured and/or forecast.
traffic load as it is measured and/or forecast.
6. If link bandwidth is exhausted on a given path for a flow/LSP/traffic 6. If link bandwidth is exhausted on a given path for a flow/LSP/traffic
trunk, alternate paths may be attempted to satisfy CT bandwidth trunk, alternate paths may be attempted to satisfy CT bandwidth
allocation. allocation.
Note that the above assumptions are not unique to MAR, but are generic, Note that the above assumptions are not unique to MAR, but are generic,
common assumptions for all BC Models. common assumptions for all BC Models.
4. Functional Specification of the MAR Bandwidth Constraints Model 4. Functional Specification of the MAR Bandwidth Constraints Model
A DS-TE LSR implementing MAR MUST support enforcement of bandwidth A DS-TE LSR implementing MAR MUST support enforcement of bandwidth
skipping to change at page 9, line 55 skipping to change at page 9, line 55
Levels", RFC 2119, March 1997. Levels", RFC 2119, March 1997.
[IANA-CONS] Narten, T., "Guidelines for Writing an IANA Considerations [IANA-CONS] Narten, T., "Guidelines for Writing an IANA Considerations
Section in RFCs," RFC 2434, October 1998. Section in RFCs," RFC 2434, October 1998.
12. Informative References 12. Informative References
[AKI] Akinpelu, J. M., "The Overload Performance of Engineered Networks [AKI] Akinpelu, J. M., "The Overload Performance of Engineered Networks
with Nonhierarchical & Hierarchical Routing," BSTJ, Vol. 63, 1984. with Nonhierarchical & Hierarchical Routing," BSTJ, Vol. 63, 1984.
[ASH1] Ash, G. R., "Dynamic Routing in Telecommunications Networks," [ASH1] Ash, G. R., "Dynamic Routing in Telecommunications Networks,"
McGraw-Hill, 1998. McGraw-Hill, 1998.
[ASH2] Ash, G. R., et. al., "Routing Evolution in Multiservice Integrated [ASH2] Ash, G. R., et. al., "Routing Evolution in Multiservice
Voice/Data Networks," Proceeding of ITC-16, Edinburgh, June 1999. Integrated Voice/Data Networks," Proceeding of ITC-16, Edinburgh, June
1999.
[ASH3] Ash, G. R., "Performance Evaluation of QoS-Routing Methods for [ASH3] Ash, G. R., "Performance Evaluation of QoS-Routing Methods for
IP-Based Multiservice Networks," Computer Communications Magazine, IP-Based Multiservice Networks," Computer Communications Magazine,
May 2003. May 2003.
TDM-Based Multiservice Networks, work in progress.
[BUR] Burke, P. J., Blocking Probabilities Associated with Directional [BUR] Burke, P. J., Blocking Probabilities Associated with Directional
Reservation, unpublished memorandum, 1961. Reservation, unpublished memorandum, 1961.
[DSTE-PERF] Lai, W., "Bandwidth Constraints Models for DiffServ-TE: [DSTE-PERF] Lai, W., "Bandwidth Constraints Models for DiffServ-TE:
Performance Evaluation", work in progress. Performance Evaluation", work in progress.
[E.360.1 --> E.360.7] ITU-T Recommendations, "QoS Routing & Related [E.360.1 --> E.360.7] ITU-T Recommendations, "QoS Routing & Related
Traffic Engineering Methods for Multiservice TDM-, ATM-, & IP-Based Traffic Engineering Methods for Multiservice TDM-, ATM-, & IP-Based
Networks". Networks".
[GMPLS-RECOV] Lang, J., et. al., "Generalized MPLS Recovery Functional [GMPLS-RECOV] Lang, J., et. al., "Generalized MPLS Recovery Functional
Specification", work in progress. Specification", work in progress.
[KRU] Krupp, R. S., "Stabilization of Alternate Routing Networks", [KRU] Krupp, R. S., "Stabilization of Alternate Routing Networks",
skipping to change at page 10, line 40 skipping to change at page 10, line 39
Communication Network, Proceedings of ITC-7, Stockholm, 1973. Communication Network, Proceedings of ITC-7, Stockholm, 1973.
[OSPF-TE] Katz, D., et. al., "Traffic Engineering (TE) Extensions to [OSPF-TE] Katz, D., et. al., "Traffic Engineering (TE) Extensions to
OSPF Version 2," RFC 3630, September 2003. OSPF Version 2," RFC 3630, September 2003.
[RDM] Le Faucheur, F., "Russian Dolls Bandwidth Constraints Model for [RDM] Le Faucheur, F., "Russian Dolls Bandwidth Constraints Model for
Diff-Serv-aware MPLS Traffic Engineering", work in progress. Diff-Serv-aware MPLS Traffic Engineering", work in progress.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996. BCP 9, RFC 2026, October 1996.
[RSVP-TE] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP [RSVP-TE] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
13. Intellectual Property Statement 13. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in this
this document or the extent to which any license under such rights document or the extent to which any license under such rights might or
might or might not be available; neither does it represent that it might not be available; nor does it represent that it has made any
has made any effort to identify any such rights. Information on the independent effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and procedures with respect to rights in RFC documents can be found in BCP
standards-related documentation can be found in RFC 2028. Copies of 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an attempt
proprietary rights by implementors or users of this specification can made to obtain a general license or permission for the use of such
be obtained from the IETF Secretariat. 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 The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary rights
rights which may cover technology that may be required to practice that may cover technology that may be required to implement this
this standard. Please address the information to the IETF Executive standard. Please address the information to the IETF at
Director.
ietf-ipr@ietf.org.
14. Authors' Addresses 14. Authors' Addresses
Jerry Ash Jerry Ash
AT&T AT&T
Room MT D5-2A01 Room MT D5-2A01
200 Laurel Avenue 200 Laurel Avenue
Middletown, NJ 07748, USA Middletown, NJ 07748, USA
Phone: +1 732-420-4578 Phone: +1 732-420-4578
Email: gash@att.com Email: gash@att.com
skipping to change at page 12, line 58 skipping to change at page 12, line 54
capacity uses the link state and the allowed load state threshold to capacity uses the link state and the allowed load state threshold to
determine if a bandwidth allocation request can be accepted on a given determine if a bandwidth allocation request can be accepted on a given
CT. CT.
A.2 Analysis of MAR Performance A.2 Analysis of MAR Performance
In this Appendix, modeling analysis is presented in which MAR bandwidth In this Appendix, modeling analysis is presented in which MAR bandwidth
allocation is shown to provide good network performance relative to full allocation is shown to provide good network performance relative to full
sharing models, under normal and abnormal operating conditions. A sharing models, under normal and abnormal operating conditions. A
large-scale DiffServ-aware MPLS traffic engineering simulation model is large-scale DiffServ-aware MPLS traffic engineering simulation model is
used, in which several CTs with different priority classes share the pool used, in which several CTs with different priority classes share the
of bandwidth on a multiservice, integrated voice/data network. MAR pool of bandwidth on a multiservice, integrated voice/data network. MAR
methods have also been analyzed in practice for TDM-based networks [ASH1], methods have also been analyzed in practice for TDM-based networks
[ASH1], and in modeling studies for IP-based networks [ASH2, ASH3,
and in modeling studies for IP-based networks [ASH2, ASH3, E.360]. E.360].
All Bandwidth Constraints Models should meet these objectives: All Bandwidth Constraints Models should meet these objectives:
1. applies equally when preemption is either enabled or disabled (when 1. applies equally when preemption is either enabled or disabled (when
preemption is disabled, the model still works 'reasonably' well), preemption is disabled, the model still works 'reasonably' well),
2. bandwidth efficiency, i.e., good bandwidth sharing among CTs under 2. bandwidth efficiency, i.e., good bandwidth sharing among CTs under
both normal and overload conditions, both normal and overload conditions,
3. bandwidth isolation, i.e., a CT cannot hog the bandwidth of another 3. bandwidth isolation, i.e., a CT cannot hog the bandwidth of another
CT under overload conditions, CT under overload conditions,
4. protection against QoS degradation, at least of the high-priority CTs 4. protection against QoS degradation, at least of the high-priority CTs
(e.g. high-priority voice, high-priority data, etc.), and (e.g. high-priority voice, high-priority data, etc.), and
5. reasonably simple, i.e., does not require additional IGP extensions 5. reasonably simple, i.e., does not require additional IGP extensions
and minimizes signaling load processing requirements. and minimizes signaling load processing requirements.
The use of any given Bandwidth Constraints Model has significant impacts The use of any given Bandwidth Constraints Model has significant impacts
on the performance of a network, as explained later. Therefore, the on the performance of a network, as explained later. Therefore, the
criteria used to select a model must enable us to evaluate how a criteria used to select a model need to enable us to evaluate how a
particular model delivers its performance, relative to other models. Lai particular model delivers its performance, relative to other models. Lai
[LAI, DSTE-PERF] has analyzed the MAM and RDM Models and provided [LAI, DSTE-PERF] has analyzed the MAM and RDM Models and provided
valuable insights into the relative performance of these models under valuable insights into the relative performance of these models under
various network conditions. various network conditions.
In environments where preemption is not used, MAM is attractive because In environments where preemption is not used, MAM is attractive because
a) it is good at achieving isolation, and b) it achieves reasonable a) it is good at achieving isolation, and b) it achieves reasonable
bandwidth efficiency with some QoS degradation of lower classes. When bandwidth efficiency with some QoS degradation of lower classes. When
preemption is used, RDM is attractive because it can achieve bandwidth preemption is used, RDM is attractive because it can achieve bandwidth
efficiency under normal load. However, RDM cannot provide service efficiency under normal load. However, RDM cannot provide service
isolation under high load or when preemption is not used. isolation under high load or when preemption is not used.
Our performance analysis of MAR bandwidth allocation methods is based on Our performance analysis of MAR bandwidth allocation methods is based on
a full-scale, 135-node simulation model of a national network together a full-scale, 135-node simulation model of a national network together
with a multiservice traffic demand model to study various scenarios and with a multiservice traffic demand model to study various scenarios and
tradeoffs [ASH3, E.360]. Three levels of traffic priority - high, tradeoffs [ASH3, E.360]. Three levels of traffic priority - high,
normal, and best effort -- are given across 5 CTs: normal priority voice, normal, and best effort -- are given across 5 CTs: normal priority
high priority voice, normal priority data, high priority data, and best voice, high priority voice, normal priority data, high priority data,
effort data. and best effort data.
The performance analyses for overloads and failures include a) the MAR The performance analyses for overloads and failures include a) the MAR
Bandwidth Constraints Model, as specified in Section 4, b) the MAM Bandwidth Constraints Model, as specified in Section 4, b) the MAM
Bandwidth Constraints Model, and c) the No-DSTE Bandwidth Constraints Bandwidth Constraints Model, and c) the No-DSTE Bandwidth Constraints
Model. Model.
The allocated bandwidth constraints for MAR are as described in Section The allocated bandwidth constraints for MAR are as described in Section
5: 5:
Normal priority CTs: BCck = PROPORTIONAL_BWk, Normal priority CTs: BCck = PROPORTIONAL_BWk,
skipping to change at page 16, line 14 skipping to change at page 16, line 14
Table 6 illustrates the performance of the MAR, MAM, and No-DSTE Table 6 illustrates the performance of the MAR, MAM, and No-DSTE
Bandwidth Constraints Models for a multiple link failure scenario (3 Bandwidth Constraints Models for a multiple link failure scenario (3
links with 3 OC-48, 3 OC-3, 4 OC-3 capacity, respectively). The numbers links with 3 OC-48, 3 OC-3, 4 OC-3 capacity, respectively). The numbers
given in the table are the total network percent lost (blocked) or given in the table are the total network percent lost (blocked) or
delayed traffic. delayed traffic.
Table 6 Table 6
Performance Comparison for MAR, MAM, & No-DSTE Performance Comparison for MAR, MAM, & No-DSTE
Bandwidth Constraints (BC) Models Bandwidth Constraints (BC) Models
Multiple Link Failure (3 Links with 2 OC-48, 2 OC-12, 1 OC-12, Respectively) Multiple Link Failure
(3 Links with 2 OC-48, 2 OC-12, 1 OC-12, Respectively)
(Total Network % Lost/Delayed Traffic) (Total Network % Lost/Delayed Traffic)
Class Type MAR BC MAM BC No-DSTE BC Class Type MAR BC MAM BC No-DSTE BC
Model Model Model Model Model Model
NORMAL PRIORITY VOICE 0.00 0.91 0.92 NORMAL PRIORITY VOICE 0.00 0.91 0.92
HIGH PRIORITY VOICE 0.00 0.44 0.44 HIGH PRIORITY VOICE 0.00 0.44 0.44
NORMAL PRIORITY DATA 0.00 0.70 0.72 NORMAL PRIORITY DATA 0.00 0.70 0.72
HIGH PRIORITY DATA 0.00 0.44 0.44 HIGH PRIORITY DATA 0.00 0.44 0.44
BEST EFFORT PRIORITY DATA 0.14 1.03 1.04 BEST EFFORT PRIORITY DATA 0.14 1.03 1.04
Again, we can see the performance is always better when MAR bandwidth Again, we can see the performance is always better when MAR bandwidth
allocation and reservation is used. allocation and reservation is used.
Lai's results [LAI, DSTE-PERF] show the trade-off between bandwidth sharing Lai's results [LAI, DSTE-PERF] show the trade-off between bandwidth
and service protection/isolation, using an analytic model of a single sharing and service protection/isolation, using an analytic model of a
link. He shows that RDM has a higher degree of sharing than MAM. single link. He shows that RDM has a higher degree of sharing than MAM.
Furthermore, for a single link, the overall loss probability is the Furthermore, for a single link, the overall loss probability is the
smallest under full sharing and largest under MAM, with RDM being smallest under full sharing and largest under MAM, with RDM being
intermediate. Hence, on a single link, Lai shows that the full sharing intermediate. Hence, on a single link, Lai shows that the full sharing
model yields the highest link efficiency and MAM the lowest, and that model yields the highest link efficiency and MAM the lowest, and that
full sharing has the poorest service protection capability. full sharing has the poorest service protection capability.
The results of the present study show that when considering a network The results of the present study show that when considering a network
context, in which there are many links and multiple-link routing paths context, in which there are many links and multiple-link routing paths
are used, full sharing does not necessarily lead to maximum network-wide are used, full sharing does not necessarily lead to maximum network-wide
bandwidth efficiency. In fact, the results in Table 4 show that the bandwidth efficiency. In fact, the results in Table 4 show that the
skipping to change at page 16, line 56 skipping to change at page 16, line 58
Both Lai's study and this study show that increasing the degree of Both Lai's study and this study show that increasing the degree of
bandwidth sharing among the different CTs leads to a tighter coupling bandwidth sharing among the different CTs leads to a tighter coupling
between CTs. Under normal loading conditions, there is adequate capacity between CTs. Under normal loading conditions, there is adequate capacity
for each CT, which minimizes the effect of such coupling. Under overload for each CT, which minimizes the effect of such coupling. Under overload
conditions, when there is a scarcity of capacity, such coupling can conditions, when there is a scarcity of capacity, such coupling can
cause severe degradation of service, especially for the lower priority cause severe degradation of service, especially for the lower priority
CTs. CTs.
Thus, the objective of maximizing efficient bandwidth usage, as stated Thus, the objective of maximizing efficient bandwidth usage, as stated
in Bandwidth Constraints Model objectives, must be exercised with care. in Bandwidth Constraints Model objectives, needs to be exercised with
Due consideration needs to be given also to achieving bandwidth care. Due consideration needs to be given also to achieving bandwidth
isolation under overload, in order to minimize the effect of isolation under overload, in order to minimize the effect of
interactions among the different CTs. The proper tradeoff of bandwidth interactions among the different CTs. The proper tradeoff of bandwidth
sharing and bandwidth isolation needs to be achieved in the selection of sharing and bandwidth isolation needs to be achieved in the selection of
a Bandwidth Constraints Model. Bandwidth reservation supports greater a Bandwidth Constraints Model. Bandwidth reservation supports greater
efficiency in bandwidth sharing while still providing bandwidth efficiency in bandwidth sharing while still providing bandwidth
isolation and protection against QoS degradation. isolation and protection against QoS degradation.
In summary, the proposed MAR Bandwidth Constraints Model includes the In summary, the proposed MAR Bandwidth Constraints Model includes the
following: a) allocate bandwidth to individual CTs, b) protect allocated following: a) allocate bandwidth to individual CTs, b) protect allocated
bandwidth by bandwidth reservation methods, as needed, but otherwise bandwidth by bandwidth reservation methods, as needed, but otherwise
fully share bandwidth, c) differentiate high-priority, normal-priority, fully share bandwidth, c) differentiate high-priority, normal-priority,
and best-effort priority services, and d) provide admission control to and best-effort priority services, and d) provide admission control to
reject connection requests when needed to meet performance objectives. reject connection requests when needed to meet performance objectives.
skipping to change at page 18, line 24 skipping to change at page 18, line 27
two head-ends H1 and H2. If only H1 or only H2 is establishing LSPs two head-ends H1 and H2. If only H1 or only H2 is establishing LSPs
through L, then the prediction is accurate. But, if both H1 and H2 are through L, then the prediction is accurate. But, if both H1 and H2 are
establishing LSPs through L at the same time, then the prediction establishing LSPs through L at the same time, then the prediction
would not work perfectly. That is, the CAC will occasionally run into a would not work perfectly. That is, the CAC will occasionally run into a
rejected LSP on a link with such 'race' conditions. Also, as mentioned rejected LSP on a link with such 'race' conditions. Also, as mentioned
in Appendix A, such prediction is optional and outside the scope of the in Appendix A, such prediction is optional and outside the scope of the
document. document.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). This document is subject to
the rights, licenses and restrictions contained in BCP 78 and except as
This document and translations of it may be copied and furnished to set forth therein, the authors retain all their rights.
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works.
However, this document itself may not be modified in any way, such as by This document and the information contained herein are provided on an
removing the copyright notice or references to the Internet Society or "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
other Internet organizations, except as needed for the purpose of IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
developing Internet standards in which case the procedures for ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
copyrights defined in the Internet Standards process must be followed, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
or as required to translate it into languages other than English. INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The limited permissions granted above are perpetual and will not be Disclaimer of Validity
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS This document and the information contained herein are provided on an
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
FITNESS FOR A PARTICULAR PURPOSE. INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/