draft-ietf-teas-rfc3272bis-00.txt   draft-ietf-teas-rfc3272bis-01.txt 
TEAS Working Group A. Farrel, Ed. TEAS Working Group A. Farrel, Ed.
Internet-Draft Old Dog Consulting Internet-Draft Old Dog Consulting
Obsoletes: 3272 (if approved) July 2, 2020 Obsoletes: 3272 (if approved) July 13, 2020
Intended status: Informational Intended status: Informational
Expires: January 3, 2021 Expires: January 14, 2021
Overview and Principles of Internet Traffic Engineering Overview and Principles of Internet Traffic Engineering
draft-ietf-teas-rfc3272bis-00 draft-ietf-teas-rfc3272bis-01
Abstract Abstract
This document describes the principles of Traffic Engineering (TE) in This document describes the principles of Traffic Engineering (TE) in
the Internet. The document is intended to promote better the Internet. The document is intended to promote better
understanding of the issues surrounding traffic engineering in IP understanding of the issues surrounding traffic engineering in IP
networks and the networks that support IP networking, and to provide networks and the networks that support IP networking, and to provide
a common basis for the development of traffic engineering a common basis for the development of traffic engineering
capabilities for the Internet. The principles, architectures, and capabilities for the Internet. The principles, architectures, and
methodologies for performance evaluation and performance optimization methodologies for performance evaluation and performance optimization
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
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 or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2021. This Internet-Draft will expire on January 14, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. What is Internet Traffic Engineering? . . . . . . . . . . 4 1.1. What is Internet Traffic Engineering? . . . . . . . . . . 4
1.2. Components of Traffic Engineering . . . . . . . . . . . . 6 1.2. Components of Traffic Engineering . . . . . . . . . . . . 7
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 11 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1. Context of Internet Traffic Engineering . . . . . . . . . 12 2.1. Context of Internet Traffic Engineering . . . . . . . . . 12
2.2. Network Context . . . . . . . . . . . . . . . . . . . . . 12 2.2. Network Context . . . . . . . . . . . . . . . . . . . . . 13
2.3. Problem Context . . . . . . . . . . . . . . . . . . . . . 15 2.3. Problem Context . . . . . . . . . . . . . . . . . . . . . 15
2.3.1. Congestion and its Ramifications . . . . . . . . . . 16 2.3.1. Congestion and its Ramifications . . . . . . . . . . 16
2.4. Solution Context . . . . . . . . . . . . . . . . . . . . 16 2.4. Solution Context . . . . . . . . . . . . . . . . . . . . 17
2.4.1. Combating the Congestion Problem . . . . . . . . . . 19 2.4.1. Combating the Congestion Problem . . . . . . . . . . 19
2.5. Implementation and Operational Context . . . . . . . . . 22 2.5. Implementation and Operational Context . . . . . . . . . 22
3. Traffic Engineering Process Models . . . . . . . . . . . . . 22 3. Traffic Engineering Process Models . . . . . . . . . . . . . 23
3.1. Components of the Traffic Engineering Process Model . . . 23 3.1. Components of the Traffic Engineering Process Model . . . 23
4. Review of TE Techniques . . . . . . . . . . . . . . . . . . . 24 4. Review of TE Techniques . . . . . . . . . . . . . . . . . . . 24
4.1. Overview of IETF Projects Related to Traffic Engineering 24 4.1. Overview of IETF Projects Related to Traffic Engineering 24
4.1.1. Constraint-Based Routing . . . . . . . . . . . . . . 24 4.1.1. Constraint-Based Routing . . . . . . . . . . . . . . 24
4.1.2. Integrated Services . . . . . . . . . . . . . . . . . 25 4.1.2. Integrated Services . . . . . . . . . . . . . . . . . 25
4.1.3. RSVP . . . . . . . . . . . . . . . . . . . . . . . . 25 4.1.3. RSVP . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.4. Differentiated Services . . . . . . . . . . . . . . . 26 4.1.4. Differentiated Services . . . . . . . . . . . . . . . 27
4.1.5. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 27 4.1.5. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1.6. Generalized MPLS . . . . . . . . . . . . . . . . . . 28 4.1.6. Generalized MPLS . . . . . . . . . . . . . . . . . . 28
4.1.7. IP Performance Metrics . . . . . . . . . . . . . . . 29 4.1.7. IP Performance Metrics . . . . . . . . . . . . . . . 29
4.1.8. Flow Measurement . . . . . . . . . . . . . . . . . . 29 4.1.8. Flow Measurement . . . . . . . . . . . . . . . . . . 29
4.1.9. Endpoint Congestion Management . . . . . . . . . . . 30 4.1.9. Endpoint Congestion Management . . . . . . . . . . . 30
4.1.10. TE Extensions to the IGPs . . . . . . . . . . . . . . 30 4.1.10. TE Extensions to the IGPs . . . . . . . . . . . . . . 30
4.1.11. Link-State BGP . . . . . . . . . . . . . . . . . . . 30 4.1.11. Link-State BGP . . . . . . . . . . . . . . . . . . . 30
4.1.12. Path Computation Element . . . . . . . . . . . . . . 31 4.1.12. Path Computation Element . . . . . . . . . . . . . . 31
4.1.13. Application-Layer Traffic Optimization . . . . . . . 31 4.1.13. Application-Layer Traffic Optimization . . . . . . . 31
4.1.14. Segment Routing with MPLS encapsuation (SR-MPLS) . . 31 4.1.14. Segment Routing with MPLS encapsuation (SR-MPLS) . . 32
4.1.15. Network Virtualization and Abstraction . . . . . . . 32 4.1.15. Network Virtualization and Abstraction . . . . . . . 33
4.1.16. Deterministic Networking . . . . . . . . . . . . . . 33 4.1.16. Deterministic Networking . . . . . . . . . . . . . . 34
4.1.17. Network TE State Definition and Presentation . . . . 33 4.1.17. Network TE State Definition and Presentation . . . . 34
4.1.18. System Management and Control Interfaces . . . . . . 34 4.1.18. System Management and Control Interfaces . . . . . . 34
4.2. Content Distribution . . . . . . . . . . . . . . . . . . 34 4.2. Content Distribution . . . . . . . . . . . . . . . . . . 34
5. Taxonomy of Traffic Engineering Systems . . . . . . . . . . . 35 5. Taxonomy of Traffic Engineering Systems . . . . . . . . . . . 35
5.1. Time-Dependent Versus State-Dependent Versus Event 5.1. Time-Dependent Versus State-Dependent Versus Event
Dependent . . . . . . . . . . . . . . . . . . . . . . . . 35 Dependent . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2. Offline Versus Online . . . . . . . . . . . . . . . . . . 37 5.2. Offline Versus Online . . . . . . . . . . . . . . . . . . 37
5.3. Centralized Versus Distributed . . . . . . . . . . . . . 37 5.3. Centralized Versus Distributed . . . . . . . . . . . . . 37
5.3.1. Hybrid Systems . . . . . . . . . . . . . . . . . . . 38 5.3.1. Hybrid Systems . . . . . . . . . . . . . . . . . . . 38
5.3.2. Considerations for Software Defined Networking . . . 38 5.3.2. Considerations for Software Defined Networking . . . 38
5.4. Local Versus Global . . . . . . . . . . . . . . . . . . . 38 5.4. Local Versus Global . . . . . . . . . . . . . . . . . . . 38
5.5. Prescriptive Versus Descriptive . . . . . . . . . . . . . 38 5.5. Prescriptive Versus Descriptive . . . . . . . . . . . . . 38
5.5.1. Intent-Based Networking . . . . . . . . . . . . . . . 38 5.5.1. Intent-Based Networking . . . . . . . . . . . . . . . 39
5.6. Open-Loop Versus Closed-Loop . . . . . . . . . . . . . . 39 5.6. Open-Loop Versus Closed-Loop . . . . . . . . . . . . . . 39
5.7. Tactical vs Strategic . . . . . . . . . . . . . . . . . . 39 5.7. Tactical vs Strategic . . . . . . . . . . . . . . . . . . 39
6. Recommendations for Internet Traffic Engineering . . . . . . 39 6. Recommendations for Internet Traffic Engineering . . . . . . 39
6.1. Generic Non-functional Recommendations . . . . . . . . . 40 6.1. Generic Non-functional Recommendations . . . . . . . . . 40
6.2. Routing Recommendations . . . . . . . . . . . . . . . . . 42 6.2. Routing Recommendations . . . . . . . . . . . . . . . . . 42
6.3. Traffic Mapping Recommendations . . . . . . . . . . . . . 44 6.3. Traffic Mapping Recommendations . . . . . . . . . . . . . 44
6.4. Measurement Recommendations . . . . . . . . . . . . . . . 45 6.4. Measurement Recommendations . . . . . . . . . . . . . . . 45
6.5. Network Survivability . . . . . . . . . . . . . . . . . . 46 6.5. Network Survivability . . . . . . . . . . . . . . . . . . 46
6.5.1. Survivability in MPLS Based Networks . . . . . . . . 48 6.5.1. Survivability in MPLS Based Networks . . . . . . . . 48
6.5.2. Protection Option . . . . . . . . . . . . . . . . . . 49 6.5.2. Protection Option . . . . . . . . . . . . . . . . . . 49
skipping to change at page 3, line 49 skipping to change at page 3, line 49
A.2.1. Adaptive Routing in the ARPANET . . . . . . . . . . . 73 A.2.1. Adaptive Routing in the ARPANET . . . . . . . . . . . 73
A.2.2. Dynamic Routing in the Internet . . . . . . . . . . . 73 A.2.2. Dynamic Routing in the Internet . . . . . . . . . . . 73
A.2.3. ToS Routing . . . . . . . . . . . . . . . . . . . . . 74 A.2.3. ToS Routing . . . . . . . . . . . . . . . . . . . . . 74
A.2.4. Equal Cost Multi-Path . . . . . . . . . . . . . . . . 74 A.2.4. Equal Cost Multi-Path . . . . . . . . . . . . . . . . 74
A.2.5. Nimrod . . . . . . . . . . . . . . . . . . . . . . . 75 A.2.5. Nimrod . . . . . . . . . . . . . . . . . . . . . . . 75
A.3. Development of Internet Traffic Engineering . . . . . . . 75 A.3. Development of Internet Traffic Engineering . . . . . . . 75
A.3.1. Overlay Model . . . . . . . . . . . . . . . . . . . . 75 A.3.1. Overlay Model . . . . . . . . . . . . . . . . . . . . 75
Appendix B. Overview of Traffic Engineering Related Work in Appendix B. Overview of Traffic Engineering Related Work in
Other SDOs . . . . . . . . . . . . . . . . . . . . . 76 Other SDOs . . . . . . . . . . . . . . . . . . . . . 76
B.1. Overview of ITU Activities Related to Traffic Engineering 76 B.1. Overview of ITU Activities Related to Traffic Engineering 76
Appendix C. Summary of Changes Since RFC 3272 . . . . . . . . . 77
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 77
1. Introduction 1. Introduction
This memo describes the principles of Internet traffic engineering. This memo describes the principles of Internet traffic engineering.
The objective of the document is to articulate the general issues and The objective of the document is to articulate the general issues and
principles for Internet traffic engineering; and where appropriate to principles for Internet traffic engineering; and where appropriate to
provide recommendations, guidelines, and options for the development provide recommendations, guidelines, and options for the development
of online and offline Internet traffic engineering capabilities and of online and offline Internet traffic engineering capabilities and
support systems. support systems.
skipping to change at page 4, line 43 skipping to change at page 4, line 43
because a preponderance of Internet traffic tends to originate in one because a preponderance of Internet traffic tends to originate in one
autonomous system and terminate in another, this document provides an autonomous system and terminate in another, this document provides an
overview of aspects pertaining to inter-domain traffic engineering. overview of aspects pertaining to inter-domain traffic engineering.
This work was first published as [RFC3272] in May 2002. This This work was first published as [RFC3272] in May 2002. This
document obsoletes [RFC3272] by making a complete update to bring the document obsoletes [RFC3272] by making a complete update to bring the
text in line with best current practices for Internet traffic text in line with best current practices for Internet traffic
engineering and to include references to the latest relevant work in engineering and to include references to the latest relevant work in
the IETF. It is worth noting around three fifths of the RFCs the IETF. It is worth noting around three fifths of the RFCs
referenced in this document post-date the publication of RFC 3272. referenced in this document post-date the publication of RFC 3272.
Appendix C provides a summary of changes between RFC 3272 and this
document.
1.1. What is Internet Traffic Engineering? 1.1. What is Internet Traffic Engineering?
The Internet exists in order to transfer information from source The Internet exists in order to transfer information from source
nodes to destination nodes. Accordingly, one of the most significant nodes to destination nodes. Accordingly, one of the most significant
functions performed by the Internet is the routing of traffic from functions performed by the Internet is the routing of traffic from
ingress nodes to egress nodes. Therefore, one of the most ingress nodes to egress nodes. Therefore, one of the most
distinctive functions performed by Internet traffic engineering is distinctive functions performed by Internet traffic engineering is
the control and optimization of the routing function, to steer the control and optimization of the routing function, to steer
traffic through the network. traffic through the network.
skipping to change at page 7, line 5 skipping to change at page 7, line 13
accommodate unforeseen future demands. accommodate unforeseen future demands.
1.2. Components of Traffic Engineering 1.2. Components of Traffic Engineering
As mentioned in Section 1.1, Internet Traffic Engineering provides As mentioned in Section 1.1, Internet Traffic Engineering provides
performance optimization of operational IP networks while utilizing performance optimization of operational IP networks while utilizing
network resources economically and reliably. Such optimization is network resources economically and reliably. Such optimization is
supported at the control/controller level and within the data/ supported at the control/controller level and within the data/
forwarding plane. forwarding plane.
The key elements required in any TE solution are: The key elements required in any TE solution are as follows. Some TE
solutions rely on these elements to a lesser or greater extent.
Debate remains about whether a solution can truly be called Traffic
Engineering that does not include all of these elements. For the
sake of this document we assert that all TE solutions must include
some aspects of all of these elements. Other solutions can be
classed as "partial TE" and also fall in scope of this document.
1. Policy 1. Policy
2. Path steering 2. Path steering
3. Resource management 3. Resource management
Policy allows for the selection of next hops and paths based on Policy allows for the selection of next hops and paths based on
information beyond basic reachability. Early definitions of routing information beyond basic reachability. Early definitions of routing
policy, e.g., [RFC1102] and [RFC1104], discuss routing policy being policy, e.g., [RFC1102] and [RFC1104], discuss routing policy being
skipping to change at page 26, line 42 skipping to change at page 27, line 7
mitigate the scaling problems. As a result, it is becoming a mitigate the scaling problems. As a result, it is becoming a
versatile signaling protocol for the Internet. For example, RSVP has versatile signaling protocol for the Internet. For example, RSVP has
been extended to reserve resources for aggregation of flows, to set been extended to reserve resources for aggregation of flows, to set
up MPLS explicit label switched paths, and to perform other signaling up MPLS explicit label switched paths, and to perform other signaling
functions within the Internet. There are also a number of proposals functions within the Internet. There are also a number of proposals
to reduce the amount of refresh messages required to maintain to reduce the amount of refresh messages required to maintain
established RSVP sessions [RFC2961]. established RSVP sessions [RFC2961].
A number of IETF working groups have been engaged in activities A number of IETF working groups have been engaged in activities
related to the RSVP protocol. These include the original RSVP related to the RSVP protocol. These include the original RSVP
working group, the MPLS working group, the Resource Allocation working group, the MPLS working group, the CCAMP working group, the
Protocol working group, and the Policy Framework working group. TEAS working group, the Resource Allocation Protocol working group,
and the Policy Framework working group.
4.1.4. Differentiated Services 4.1.4. Differentiated Services
The goal of the Differentiated Services (Diffserv) effort within the The goal of the Differentiated Services (Diffserv) effort within the
IETF is to devise scalable mechanisms for categorization of traffic IETF is to devise scalable mechanisms for categorization of traffic
into behavior aggregates, which ultimately allows each behavior into behavior aggregates, which ultimately allows each behavior
aggregate to be treated differently, especially when there is a aggregate to be treated differently, especially when there is a
shortage of resources such as link bandwidth and buffer space shortage of resources such as link bandwidth and buffer space
[RFC2475]. One of the primary motivations for the Diffserv effort [RFC2475]. One of the primary motivations for the Diffserv effort
was to devise alternative mechanisms for service differentiation in was to devise alternative mechanisms for service differentiation in
skipping to change at page 61, line 43 skipping to change at page 61, line 43
Liu Hua Liu Hua
Loa Andersson Loa Andersson
Luis Miguel Contreras Luis Miguel Contreras
Martin Horneffer Martin Horneffer
Tarek Saad Tarek Saad
Xufeng Liu Xufeng Liu
The production of this document includes a fix to the original text The production of this document includes a fix to the original text
resulting from an Errata Report by Jean-Michel Grimaldi. resulting from an Errata Report by Jean-Michel Grimaldi.
The authors of this document would also like to thank TBD. The authors of this document would also like to thank Dhurv Dhody for
review comments.
13. Contributors 13. Contributors
The following people contributed substantive text to this document: The following people contributed substantive text to this document:
Gert Grammel Gert Grammel
EMail: ggrammel@juniper.net EMail: ggrammel@juniper.net
Loa Andersson Loa Andersson
EMail: loa@pi.nu EMail: loa@pi.nu
skipping to change at page 77, line 26 skipping to change at page 77, line 26
Recommendation E.600 stipulates that a set of GoS parameters must be Recommendation E.600 stipulates that a set of GoS parameters must be
selected and defined on an end-to-end basis for each major service selected and defined on an end-to-end basis for each major service
category provided by a network to assist the network provider with category provided by a network to assist the network provider with
improving efficiency and effectiveness of the network. Based on a improving efficiency and effectiveness of the network. Based on a
selected set of reference connections, suitable target values are selected set of reference connections, suitable target values are
assigned to the selected GoS parameters under normal and high load assigned to the selected GoS parameters under normal and high load
conditions. These end-to-end GoS target values are then apportioned conditions. These end-to-end GoS target values are then apportioned
to individual resource components of the reference connections for to individual resource components of the reference connections for
dimensioning purposes. dimensioning purposes.
Appendix C. Summary of Changes Since RFC 3272
This section is a place-holder. It is expected that once work on
this document is nearly complete, this section will be updated to
provide an overview of the structural and substantive changed from
RFC 3272.
Author's Address Author's Address
Adrian Farrel (editor) Adrian Farrel (editor)
Old Dog Consulting Old Dog Consulting
Email: adrian@olddog.co.uk Email: adrian@olddog.co.uk
 End of changes. 19 change blocks. 
23 lines changed or deleted 41 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/