draft-ietf-tewg-diff-te-mar-03.txt   draft-ietf-tewg-diff-te-mar-04.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-03.txt> <draft-ietf-tewg-diff-te-mar-04.txt>
Expiration Date: July 2004 Expiration Date: July 2004
January, 2004 January, 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-03.txt> <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 This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
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 page 2, line 10 skipping to change at page 2, line 10
applicability, and examples of the operation of the MAR Bandwidth applicability, and examples of the operation of the MAR Bandwidth
Constraints Model are presented. MAR performance is analyzed relative to Constraints Model are presented. MAR performance is analyzed relative to
the criteria for selecting a Bandwidth Constraints Model, in order to the criteria for selecting a Bandwidth Constraints Model, in order to
provide guidance to user implementation of the model in their networks. 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 5 4. Functional Specification of the MAR Bandwidth Constraints Model 6
5. Setting Bandwidth Constraints . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 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 Statement . . . . . . . . . . . . . . . 10
14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10 14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11
Appendix A. MAR Operation & Performance Analysis . . . . . . . . 10 Appendix A. MAR Operation & Performance Analysis . . . . . . . . 11
Appendix B. Bandwidth Prediction for Path Computation . . . . . . 16 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 protocol
skipping to change at page 4, line 55 skipping to change at page 5, line 7
RESERVED_BWck: reserved bandwidth-in-progress on CTc on link k (0 <= c RESERVED_BWck: reserved bandwidth-in-progress on CTc on link k (0 <= c
<= MaxCT-1), RESERVED_BWck = total amount of the bandwidth reserved <= MaxCT-1), RESERVED_BWck = total amount of the bandwidth reserved
by all the established LSPs which belong to CTc. by all the established LSPs which belong to CTc.
UNRESERVED_BWk: unreserved link bandwidth on link k specifies the UNRESERVED_BWk: unreserved link bandwidth on link k specifies the
amount of bandwidth not yet reserved for any CT, UNRESERVED_BWk = amount of bandwidth not yet reserved for any CT, UNRESERVED_BWk =
MAX_RESERVABLE_BWk - sum [RESERVED_BWck (0 <= c <= MaxCT-1)]. MAX_RESERVABLE_BWk - sum [RESERVED_BWck (0 <= c <= MaxCT-1)].
UNRESERVED_BWck: unreserved link bandwidth on CTc on link k specifies UNRESERVED_BWck: unreserved link bandwidth on CTc on link k specifies
the amount of bandwidth not yet reserved for CTc, UNRESERVED_BWck = the amount of bandwidth not yet reserved for CTc, UNRESERVED_BWck =
MAX_RESERVABLE_BWk - UNRESERVED_BWk - delta0/1(CTck) * RBW-THRESk UNRESERVED_BWk - delta0/1(CTck) * RBW-THRESk
where where
delta0/1(CTck) = 0 if RESERVED_BWck < BCck delta0/1(CTck) = 0 if RESERVED_BWck < BCck
delta0/1(CTck) = 1 if RESERVED_BWck >= BCck delta0/1(CTck) = 1 if RESERVED_BWck >= BCck
A number of recovery mechanisms under investigation in the IETF take A number of recovery mechanisms under investigation in the IETF take
advantage of the concept of bandwidth sharing across particular sets of advantage of the concept of bandwidth sharing across particular sets of
LSPs. "Shared Mesh Restoration" in [GMPLS-RECOV] and "Facility-based LSPs. "Shared Mesh Restoration" in [GMPLS-RECOV] and "Facility-based
Computation Model" in [MPLS-BACKUP] are example mechanisms which Computation Model" in [MPLS-BACKUP] are example mechanisms which
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
skipping to change at page 9, line 24 skipping to change at page 9, line 46
</IANA-note> </IANA-note>
11. Normative References 11. Normative References
[DSTE-REQ] Le Faucheur, F., Lai, W., et. al., "Requirements for Support [DSTE-REQ] Le Faucheur, F., Lai, W., et. al., "Requirements for Support
of Diff-Serv-aware MPLS Traffic Engineering," RFC 3564, July 2003. of Diff-Serv-aware MPLS Traffic Engineering," RFC 3564, July 2003.
[DSTE-PROTO] Le Faucheur, F., et. al., "Protocol Extensions for Support [DSTE-PROTO] Le Faucheur, F., et. al., "Protocol Extensions for Support
of Diff-Serv-aware MPLS Traffic Engineering," work in progress. of Diff-Serv-aware MPLS Traffic Engineering," work in progress.
[KEY] Bradner, S., "Key words for Use in RFCs to Indicate Requirement [KEY] Bradner, S., "Key words for Use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997. Levels", RFC 2119, March 1997.
[IANA-CONS] Narten, T., "Guidelines for Writing an IANA Considerations
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 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., "Performance Evaluation of QoS-Routing Methods for [ASH3] Ash, G. R., "Performance Evaluation of QoS-Routing Methods for
skipping to change at page 10, line 4 skipping to change at page 10, line 33
progress. progress.
[MPLS-BACKUP] Vasseur, J. P., et. al., "MPLS Traffic Engineering Fast [MPLS-BACKUP] Vasseur, J. P., et. al., "MPLS Traffic Engineering Fast
Reroute: Bypass Tunnel Path Computation for Bandwidth Protection", work Reroute: Bypass Tunnel Path Computation for Bandwidth Protection", work
in progress. 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.
[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 Statement
AT&T Corporation may own intellectual property applicable to this The IETF takes no position regarding the validity or scope of any
contribution. The IETF has been notified of AT&T's licensing intent intellectual property or other rights that might be claimed to
for the specification contained in this document. See pertain to the implementation or use of the technology described in
http://www.ietf.org/ietf/IPR/ATT-GENERAL.txt for AT&T's IPR statement. this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in RFC 2028. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
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
 End of changes. 

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