draft-ietf-tewg-diff-te-mar-01.txt   draft-ietf-tewg-diff-te-mar-02.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-01.txt> <draft-ietf-tewg-diff-te-mar-02.txt>
Expiration Date: December 2003 Expiration Date: March 2004
June, 2003 October, 2003
Max Allocation with Reservation Bandwidth Constraint Model for Max Allocation with Reservation Bandwidth Constraint Model for
MPLS/DiffServ TE & Performance Comparisons MPLS/DiffServ TE & Performance Comparisons
<draft-ietf-tewg-diff-te-mar-01.txt> <draft-ietf-tewg-diff-te-mar-02.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at line 55 skipping to change at line 55
1. Introduction 1. Introduction
2. Definitions 2. Definitions
3. Assumptions & Applicability 3. Assumptions & Applicability
4. Functional Specification of the MAR Bandwidth Constraint Model 4. Functional Specification of the MAR Bandwidth Constraint Model
5. Setting Bandwidth Constraints 5. Setting Bandwidth Constraints
6. Example of MAR Operation 6. Example of MAR Operation
7. Summary 7. Summary
8. Security Considerations 8. Security Considerations
9. Acknowledgments 9. Acknowledgments
10. References 10. Normative References
11. Authors' Addresses 11. Informative References
12. Authors' Addresses
ANNEX A. MAR Operation & Performance Analysis ANNEX A. MAR Operation & Performance Analysis
Specification of Requirements
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].
1. Introduction 1. Introduction
DiffServ-aware MPLS traffic engineering (DSTE) requirements and protocol DiffServ-aware MPLS traffic engineering (DSTE) requirements and protocol
extensions are specified in [DSTE-REQ, DSTE-PROTO]. A requirement for extensions are specified in [DSTE-REQ, DSTE-PROTO]. A requirement for
DSTE implementation is the specification of bandwidth constraint models DSTE implementation is the specification of bandwidth constraint models
for use with DSTE. The bandwidth constraint model provides the 'rules' for use with DSTE. The bandwidth constraint model provides the 'rules'
to support the allocation of bandwidth to individual class types (CTs). to support the allocation of bandwidth to individual class types (CTs).
CTs are groupings of service classes in the DSTE model, which are CTs are groupings of service classes in the DSTE model, which are
provided separate bandwidth allocations, priorities, and QoS objectives. provided separate bandwidth allocations, priorities, and QoS objectives.
Several CTs can share a common bandwidth pool on an integrated, Several CTs can share a common bandwidth pool on an integrated,
skipping to change at line 82 skipping to change at line 89
[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 constraint model. Examples Allocation with Reservation (MAR) bandwidth constraint model. Examples
of the operation of the MAR bandwidth constraint model are presented. of the operation of the MAR bandwidth constraint 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 constraint model, in order to provide guidance to user bandwidth constraint 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 constraint models are being specified for use in Two other bandwidth constraint models are being specified for use in
DSTE: DSTE:
1. maximum allocation model (MAM) [MAM1, MAM2] - the maximum allowable 1. maximum allocation model (MAM) [MAM] - the maximum allowable
bandwidth usage of each CT is explicitly specified. bandwidth usage of each CT is explicitly specified.
2. Russian doll model (RDM) [RDM] - the maximum allowable bandwidth 2. Russian doll model (RDM) [RDM] - the maximum allowable bandwidth
usage is done cumulatively by grouping successive CTs according to usage is done cumulatively by grouping successive CTs according to
priority classes. priority classes.
MAR is similar to MAM in that a maximum bandwidth allocation is given to MAR is similar to MAM in that a maximum bandwidth allocation is given to
each CT. However, through the use of bandwidth reservation and each CT. However, through the use of bandwidth reservation and
protection mechanisms, CTs are allowed to exceed their bandwidth protection mechanisms, CTs are allowed to exceed their bandwidth
allocations under conditions of no congestion but revert to their allocations under conditions of no congestion but revert to their
allocated bandwidths when overload and congestion occurs. allocated bandwidths when overload and congestion occurs.
skipping to change at line 152 skipping to change at line 159
TE-Class: A pair of: i. a CT ii. a preemption priority allowed for that TE-Class: A pair of: i. a CT ii. a preemption priority allowed for that
CT. This means that an LSP transporting a Traffic Trunk from that CT can CT. This means that an LSP transporting a Traffic Trunk from that CT can
use that preemption priority as the set-up priority, as the holding use that preemption priority as the set-up priority, as the holding
priority or both. 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
[KATZ-YEUNG]. [KATZ-YEUNG].
RESERVED_BWck: reserved bandwidth-in-progress on CTc on link k (0 <= c
<= MaxCT-1), RESERVED_BWck = sum of the bandwidth reserved by all
established LSPs which belong to CTc.
UNRESERVED_BWck: unreserved link bandwidth on CTc on link k specifies
the amount of bandwidth not yet reserved for CTc, UNRESERVED_BWck =
MAX_RESERVABLE_BWk - sum [RESERVED_BWck (0 <= c <= MaxCT-1)].
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).
RESERVED_BWck: reserved bandwidth-in-progress on CTc on link k (0 <3D c
<3D MaxCT-1), RESERVED_BWck 3D total amount of the bandwidth reserved
by all the established LSPs which belong to CTc.
UNRESERVED_BWck: unreserved link bandwidth on CTc on link k specifies
the amount of bandwidth not yet reserved for CTc, UNRESERVED_BWck 3D
MAX_RESERVABLE_BWk - sum [RESERVED_BWck (0 <3D c <3D MaxCT-1)].
A number of recovery mechanisms under investigation in the IETF take
advantage of the concept of bandwidth sharing across particular sets of
LSPs. "Shared Mesh Restoration" in [GMPLS-RECOV] and "Facility-based
Computation Model" in [MPLS-BACKUP] are example mechanisms which
increase bandwidth efficiency by sharing bandwidth across backup LSPs
protecting against independent failures. To ensure that the notion of
RESERVED_BWck introduced in [DSTE-REQ] is compatible with such a concept
of bandwidth sharing across multiple LSPs, the wording of the definition
provided in [DSTE-REQ] is generalized. With this generalization, the
definition is compatible with Shared Mesh Restoration defined in
[GMPLS-RECOV], so that DSTE and Shared Mesh Protection can operate
simultaneously, under the assumption that Shared Mesh Restoration
operates independently within each DSTE Class-Type and does not operate
across Class-Types. For example, backup LSPs protecting primary LSPs of
CTc must also belong to CTc; excess traffic LSPs sharing bandwidth with
backup LSPs of CTc must also belong to CTc.
3. Assumptions & Applicability 3. Assumptions & Applicability
In general, DSTE is a bandwidth allocation mechanism, for different In general, DSTE 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
of MAR: of MAR:
skipping to change at line 204 skipping to change at line 228
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 Constraint Model 4. Functional Specification of the MAR Bandwidth Constraint Model
A DSTE LSR implementing MAR MUST support enforcement of bandwidth
constraints in compliance with the specifications in this Section.
In the MAR bandwidth constraint model, the bandwidth allocation control In the MAR bandwidth constraint model, the bandwidth allocation control
for each CT is based on estimated bandwidth needs, bandwidth use, and for each CT is based on estimated bandwidth needs, bandwidth use, and
status of links. The LER makes needed bandwidth allocation changes, and status of links. The LER makes needed bandwidth allocation changes, and
uses [RSVP-TE], for example, to determine if link bandwidth can be uses [RSVP-TE], for example, to determine if link bandwidth can be
allocated to a CT. Bandwidth allocated to individual CTs is protected as allocated to a CT. Bandwidth allocated to individual CTs is protected as
needed but otherwise shared. Under normal non-congested network needed but otherwise shared. Under normal non-congested network
conditions, all CTs/services fully share all available bandwidth. When conditions, all CTs/services fully share all available bandwidth. When
congestion occurs for a particular CTc, bandwidth reservation acts to congestion occurs for a particular CTc, bandwidth reservation acts to
prohibit traffic from other CTs from seizing the allocated capacity for prohibit traffic from other CTs from seizing the allocated capacity for
CTc. CTc.
skipping to change at line 373 skipping to change at line 400
No new security considerations are raised by this document, they are the No new security considerations are raised by this document, they are the
same as in the DSTE requirements document [DSTE-REQ]. same as in the DSTE requirements document [DSTE-REQ].
9. Acknowledgements 9. Acknowledgements
DSTE and bandwidth constraint models have been an active area of DSTE and bandwidth constraint models have been an active area of
discussion in the TEWG. I would like to thank Wai Sum Lai for his discussion in the TEWG. I would like to thank Wai Sum Lai for his
support and review of this draft. I also appreciate helpful discussions support and review of this draft. I also appreciate helpful discussions
with Francois Le Faucheur. with Francois Le Faucheur.
10. References 10. Normative References
[DSTE-REQ] Le Faucheur, F., Lai, W., et. al., "Requirements for Support
of Diff-Serv-aware MPLS Traffic Engineering," RFC 3564, July 2003.
[DSTE-PROTO] Le Faucheur, F., et. al., "Protocol Extensions for Support
of Diff-Serv-aware MPLS Traffic Engineering," work in progress.
[KEY] Bradner, S., "Key words for Use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
11. 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 Integrated
Voice/Data Networks, Proceeding of ITC-16, Edinburgh, June 1999. Voice/Data Networks, Proceeding of ITC-16, Edinburgh, June 1999.
[ASH3] Ash, G. R., Traffic Engineering & QoS Methods for IP-, ATM-, & [ASH3] Ash, G. R., Traffic Engineering & QoS Methods for IP-, ATM-, &
TDM-Based Multiservice Networks, work in progress. 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.
[DIFF-MPLS] Le Faucheur, F., et. al., "MPLS Support of Diff-Serv", RFC [DIFF-MPLS] Le Faucheur, F., et. al., "MPLS Support of Diff-Serv", RFC
3270, May 2002. 3270, May 2002.
[DSTE-REQ] Le Faucheur, F., et. al., "Requirements for Support of
Diff-Serv-aware MPLS Traffic Engineering," work in progress.
[DSTE-PROTO] Le Faucheur, F., et. al., "Protocol Extensions for Support
of Diff-Serv-aware MPLS Traffic Engineering," work in progress.
[DIFFSERV] Blake, S., et. al., "An Architecture for Differentiated [DIFFSERV] Blake, S., et. al., "An Architecture for Differentiated
Services", RFC 2475, December 1998. Services", RFC 2475, December 1998.
[DSTE-PERF] Lai, W., "Bandwidth Constraints Models for Diffserv-TE:
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
Specification", work in progress.
[KATZ-YEUNG] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering [KATZ-YEUNG] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
Extensions to OSPF Version 2," work in progress. Extensions to OSPF Version 2," work in progress.
[KEY] Bradner, S., "Key words for Use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[KRU] Krupp, R. S., "Stabilization of Alternate Routing Networks", [KRU] Krupp, R. S., "Stabilization of Alternate Routing Networks",
Proceedings of ICC, Philadelphia, 1982. Proceedings of ICC, Philadelphia, 1982.
[LAI] Lai, W., "Traffic Engineering for MPLS, Internet Performance and [LAI] Lai, W., "Traffic Engineering for MPLS, Internet Performance and
Control of Network Systems III Conference", SPIE Proceedings Vol. 4865, Control of Network Systems III Conference", SPIE Proceedings Vol. 4865,
pp. 256-267, Boston, Massachusetts, USA, 29 July-1 August 2002 pp. 256-267, Boston, Massachusetts, USA, 29 July-1 August 2002
(http://www.columbia.edu/~ffl5/waisum/bcmodel.pdf). (http://www.columbia.edu/~ffl5/waisum/bcmodel.pdf).
[MAM1] Lai, W., "Maximum Allocation Bandwidth Constraints Model for [MAM] Le Faucheur, F., Lai, W., "Maximum Allocation Bandwidth
Diffserv-TE & Performance Comparisons", work in progress.
[MAM2] Lai, W., Le Faucheur, F., "Maximum Allocations Bandwidth
Constraints Model for Diff-Serv-aware MPLS Traffic Engineering", work in Constraints Model for Diff-Serv-aware MPLS Traffic Engineering", work in
progress. progress.
[MPLS-BACKUP] Vasseur, J. P., et. al., "MPLS Traffic Engineering Fast
Reroute: Bypass Tunnel Path Computation for Bandwidth Protection", work
in progress.
[MUM] Mummert, V. S., "Network Management and Its Implementation on the [MUM] Mummert, V. S., "Network Management and Its Implementation on the
No. 4ESS, International Switching Symposium", Japan, 1976. No. 4ESS, International Switching Symposium", Japan, 1976.
[NAK] Nakagome, Y., Mori, H., Flexible Routing in the Global [NAK] Nakagome, Y., Mori, H., Flexible Routing in the Global
Communication Network, Proceedings of ITC-7, Stockholm, 1973. Communication Network, Proceedings of ITC-7, Stockholm, 1973.
[MPLS-ARCH] Rosen, E., et. al., "Multiprotocol Label Switching [MPLS-ARCH] Rosen, E., et. al., "Multiprotocol Label Switching
Architecture," RFC 3031, January 2001. Architecture," RFC 3031, January 2001.
[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.
skipping to change at line 549 skipping to change at line 584
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 constraint model has significant impacts The use of any given bandwidth constraint 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 must 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, MAM1] has analyzed the MA and RD models and provided valuable [LAI, DSTE-PERF] has analyzed the MA and RD models and provided valuable
insights into the relative performance of these models under various insights into the relative performance of these models under various
network conditions. 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.
skipping to change at line 718 skipping to change at line 753
Model Model Model Model Model Model
NORMAL PRIORITY VOICE 0.00 0.91 0.8609 NORMAL PRIORITY VOICE 0.00 0.91 0.8609
HIGH PRIORITY VOICE 0.00 0.44 0.4209 HIGH PRIORITY VOICE 0.00 0.44 0.4209
NORMAL PRIORITY DATA 0.00 0.70 0.6409 NORMAL PRIORITY DATA 0.00 0.70 0.6409
HIGH PRIORITY DATA 0.00 0.44 0.4209 HIGH PRIORITY DATA 0.00 0.44 0.4209
BEST EFFORT PRIORITY DATA 0.14 1.03 0.9809 BEST EFFORT PRIORITY DATA 0.14 1.03 0.9809
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, MAM1] show the trade-off between bandwidth sharing Lai's results [LAI, DSTE-PERF] show the trade-off between bandwidth sharing
and service protection/isolation, using an analytic model of a single and service protection/isolation, using an analytic model of a single
link. He shows that RDM has a higher degree of sharing than MAM. 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
 End of changes. 

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