2.4.6 Internet Traffic Engineering (tewg)

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Sep-99


Ed Kern <colette@digex.net>
Daniel Awduche <awduche@uu.net>

Operations and Management Area Director(s):

Randy Bush <randy@psg.com>
Bert Wijnen <wijnen@vnet.ibm.com>

Operations and Management Area Advisor:

Randy Bush <randy@psg.com>

Mailing Lists:

General Discussion:te-wg@uu.net
To Subscribe: te-wg-request@uu.net
In Body: subscribe
Archive: ftp://ftpext.eng.us.uu.net/tewg

Description of Working Group:

Note: Rob Coltun (rcoltun@siara.com) is technical advisor

The Internet Traffic Engineering working group is chartered to define, develop, specify, and recommend principles, techniques, and mechanisms for traffic engineering in the Internet. The working group will also serve as a general forum for discussing possible improvements to IETF protocols to advance the Traffic Engineering function.

Internet Traffic Engineering is defined as that aspect of Internet network engineering which is concerned with the performance optimization of operational networks. It encompasses the application of technology and scientific principles to the measurement, modeling, characterization, and control of Internet traffic, and the application of such knowledge and techniques to achieve specific performance objectives, including the reliable and expeditious movement of traffic through the network, the efficient utilization of network resources, and the planning of network capacity.

The primary focus of the TE WG concerns the control aspects of intra-domain Internet traffic engineering. This includes control aspects pertaining to intra-domain routing and control aspects pertaining to intra-domain network resource allocation. Techniques already in use or in advanced development for Internet TE include ATM and Frame Relay overlay models, MPLS based approaches, constraint-based routing, and TE methodologies in Diffserv environments. The WG will describe and characterize these and other techniques, document how they fit together, and identify scenarios in which they are useful.

The working group may also consider solutions to the problem of traffic engineering across autonomous systems boundaries.

As part of its deliverables, the TE WG will produce a comprehensive framework document that articulates the general principles and requirements for Internet traffic engineering, with emphasis on techniques in use or in advanced development. The working group may also produce documents that suggest possible improvements to IETF protocols to support the traffic engineering function. Additionally, the WG may produce specialized requirements documents that focus on specific aspects of Internet traffic engineering. Other informational documents may be produced as necessary.

The TE WG will interact with other areas of IETF activity whose scope intersect with the definition of traffic engineering. These include various working groups in the Routing Area (e.g. MPLS, IS-IS, OSPF, etc), the Transport Area (e.g. Diffserv, IPPM, RAP, RTFM,), and the Operations and Management Area (e.g. POLICY, RMONMIB, DISMAN, etc).

Goals and Milestones:

Oct 99


Submit A Framework For Traffic Engineering in the Internet as an Internet-Draft.

Nov 99


First WG meeting in Washington DC.

Feb 00


Submit specialized requirements documents focused on specific aspects of Internet Traffic Engineering.

Mar 00


Submit Generic Representation of Common Objects, functions, and data-sets for Internet Traffic Engineering as an Internet-Draft.

Apr 00


Submit Internet-drafts describing specific traffic engineering technologies and methodologies (e.g., constraint-based routing etc).

Jun 00


Submit revised drafts as RFCs.

No Current Internet-Drafts
No Request For Comments

Current Meeting Report

IETF-46, Washington D.C.
Traffic Engineering WG (TEWG) meeting minutes
Date: Thursday November 11, 1999
Chairs: Ed. Kern, Digex; Daniel Awduche, UUNet
Minutes reported by: Siamack Ayandeh, Lucent Technologies
Editorial review by D. Awduche

Key Points

1. A preliminary edition of the TEWG framework draft will be issued by the end of November, 1999
2. Need input from service providers, especially on operational experience with TE in live networks and on statements of requirements.
3. Another major work item for the WG is to issue a document on "Generic representation of common objects, functions, and data sets for TE." This should be issued after the framework draft.
4. TE is a very fertile area for theoretical activity. The WG, being operationally oriented, will focus mostly on considerations that have practical merit. It is however anticipated that activity within the TEWG may motivate research activity elsewhere.

Chair: Agenda bashing





E. Kern

Agenda bashing


D. Awduche

Towards a framework for Internet TE


G. Ash



G. Swallow



D. Fedyk,



I. Widjaja



H. Hummel






K. Owens



W. Wimer



Wai Sum

Report on ITU-T TE Work



General Discussions



Path forward


Presenter: D. Awduche, UUNet
Topic: Towards a framework for Internet TE

1. An overview of the TEWG charter was presented by Awduche. The status of the TEWG framework document was also provided. The key points in Awduche's presentation are summarized below:

2. The contents of the framework document would encompass the following issues (but not exclusively):

3. Next steps:

G. Ash, AT&T; Draft-ash-itu-sg2-routing-guidelines-00.txt
Continuation of the talk in mpls working group (see minutes)

Qs: How about networks with a low degree of connectivity (since much of the earlier work on network instability had been done for networks with a high degree of connectivity)".

G. Swallow, Cisco; MPLS TE Restoration
Extensions to rsvp to help with protection

Qs: What is the impact on refresh load?
No significant impact

Does the Head End router need to use a new address?
Yes but can use any IP address (can be from the private space)

Qs: Spatial Reuse Protocol BOF is addressing the same issues, can you compare?
No, not aware of SRP and out of scope of this WG

Qs: What is the recovery algorithm if bandwidth is reserved? This is just for very high priority traffic which in effect preempts other LSPs on the links

Qs: Can recovery of less than 50 [ms] be achieved in multi-hop scenario?
12 [ms] re-route has been achieved in the lab setup with 100 LSPs (did not elaborate on setup)

D. Fedyk, Nortel Networks; Metrics and Resource Classes for TE

Qs: What is a hop count?
Difficult to measure when crossing L2 networks

Widjaja, Fujitsu, ICMP Extn for 1-way performance metrics

Qs/comments: Functionality may be useful for monitoring of SLAs?
Why ICMP extn or at least have a common frame work for ICMP extn given other folks are intending to extend ICMP

Qs: How to ensure that payload and probe follow the same path/hops?
Having the same FEC may not be enough?

Qs: Why is clock sync not an issue?

Qs: ICMP extn should be careful to measure DS aggregagte characteristics, so ensure that the DSCP is stored in the ICMP packet.
Comment: ICMP packets do not go down the same path as DS aggregates?
Need to fix this

Authors question to the WG: If not ICMP then what do the group suggest should be used?

Comment from the floor: Current design of routers may not allow use of ICMP? Perhaps it would be better to trust routers to supply the information? For off line latter may be fine

H. Hummel; Siemens: OCT
Traffic should be conducted like an orchestra

Which LSP to choose

Qs: Concern re the time scale of measurements

Qs: How does it compare to OMP

Leo Anderson, Nortel Networks; Forwarding requirements for MPLS re-route

Qs: None

K. Owens; Tellabs; Protection/Restoration for TE in IP networks

Floor: What is the right place for this work? TE or MPLS? Authors opinion is that it is TE

Floor: TE has enough issues as it is? Perhaps protection should go else where.

Chair's comments: Try to do it in mpls and let the WG know if it does not get done there. This is part of the WG's intent to generate requirements/work for other WGs

W. Wimer; OSPF Sub-areas

Wai Sum AT&T: Report on ITU-T TE Work

Current ITU-T WP 3/2 work:

In closing, chairs:
Heads up:


Protection/Restoration of Traffic Engineered IP Networks