Current Meeting Report

2.6.4 Internet Traffic Engineering (tewg)

NOTE: This charter is a snapshot of the 53rd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date. Last Modified: 06-Mar-02
Ed Kern <>
Jim Boyle <>
Sub-IP Area Director(s):
Scott Bradner <>
Bert Wijnen <>
Sub-IP Area Advisor:
Bert Wijnen <>
Mailing Lists:
To Subscribe:
In Body: subscribe
Description of Working Group:
Internet Traffic Engineering is defined as that aspect of Internet network engineering concerned with the performance optimization of traffic handling in operational networks, with the main focus of the optimization being minimizing over-utilization of capacity when other capacity is available in the network. Traffic Engineering entails that aspect of network engineering which is concerned with the design, provisioning, and tuning of operational internet networks. It applies business goals, 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 service and 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 Internet Traffic Engineering Working Group defines, develops, specifies, and recommends principles, techniques, and mechanisms for traffic engineering in the internet. The working group also serves as a general forum for discussing improvements to IETF protocols to advance the traffic engineering function.

The primary focus of the tewg is the measurement and control aspects of intra-domain internet traffic engineering. This includes provisioning, measurement and control of intra-domain routing, and measurement and control aspects of intra-domain network resource allocation. Techniques already in use or in advanced development for traffic engineering include ATM and Frame Relay overlay models, MPLS based approaches, constraint-based routing, and traffic engineering methodologies in Diffserv environments. The tewg describes and characterizes these and other techniques, documents how they fit together, and identifies scenarios in which they are useful.

The working group may also consider the problems of traffic engineering across autonomous systems boundaries.

The tewg interacts with the common control and measurement plane working group to abstract and define those parameters, measurements, and controls that traffic engineering needs in order to engineer the network.

The tewg also interacts with other groups whose scopes intersect, e.g. mpls, is-is, ospf, diffserv, ippm, rap, rtfm, policy, rmonmib, disman, etc.

The work items to be undertaken by TE WG encompass the following categories:

- BCP documents on ISP uses, requirements, desires (TEBCPs)

- Operational TE MIB (TEMIB)

- Document additional measurements needed for TE (TEM)

- TE interoperability & implementation informational notes (TEIMP)

- Traffic Engineering Applicability Statement (TEAPP)

For the time being, it also is covering the area of verification that diffserv is achievable in traffic engineered SP networks. This will entail verification and review of the Diffserv requirements in the the WG Framework document and initial specification of how these requirements can be met through use and potentially expansion of existing protocols.

Goals and Milestones:
Done   Solicit TEBCP drafts concerning requirements, approaches, lessons learned from use (or non use) of TE techniques in operational provider environments.
Done   Review and comment on operational TEMIB
Done   TEBCPs submitted for WG comment
Done   Comments to TEBCP authors for clarifications
Done   First draft of TEAPP
Done   First draft of TEM
Done   TE Framework Draft to AD/IESG for review.
Done   Drafts available for E-LSP and L-LSP Diffserv TE
Sep 01   Another update of operational TEMIB draft
Sep 01   All comments back on TE Diffserv requirements
Oct 01   Submit revised TEBCPs and REAPP to AD/IESG for review
Oct 01   Progress operational TE MIB to AD review
Oct 01   Submit TEM draft for AD review
Nov 01   Any necessary protocol extensions for Diffserv TE sent to protocol relevant WGs for review.
Dec 01   Recharter
Jan 02   Progress Diffserv TE E-LSP and L-LSP Diffserv TE drafts together to AD/IESG for review
No Request For Comments

Current Meeting Report

Internet Traffic Engineering WG (TEWG)
53nd IETF, Minneapolis
3:30pm Monday, March 18, 2002
Times include discussion

Agenda Review, Milestones, Status Chairs 20 min

TEMIB Last Call Comments, Resolution Kireeti 20 minutes

TEM - Wai Sum 30 minutes

Diffserv TE Requirements Jim 20 minutes

DSTE Proposal Francois 20 minutes


Minutes of TEWG, March 18,2002, 3-530pm
53rd IETF, Minneapolis.

Minutes compiled by Ananth Nagarajan and Josh Broch.
Reviewed and Edited by Chairs


Quick recap of issues:

TE implementations - No volunteers to work on drafts, will be pulled from work list.

TE applicability: soon to make its way from IESG to RFC editor

Restoration hierarchy: with IESG

TE measurements: paper still needs work and reviewers

Diffserv TE requirements: still needs work.

IGP as second TE method: Francois draft will be reissued as a wg document, then through last call and out to the IESG

TE MIB: Comments made during last call are being made into revision, will then redo last call.

ATT, C&W draft being discussed within IESG

Discussion section

TE Measurements: Wai Sum Lai

Discussed draft status. Results of IETF 52 - add specific recommendations to the draft so as to achieve wg charter's objective and goals. Document additional measurements needed for TE. This work has been incorporated into the 02 version of the draft. Recent comments on list, yet to be accounted for, but will be added after the meeting.

Wants comments to incorporate into draft for last call on draft.

Proposed items for inclusions:

1 Use of node-pair based traffic data to derive per service class traffic matrix statistics,statistics of carried load versus performance. Possible MIB extensions needed.

2. Traffic data collection methods: need for uniform definitions across vendors and SPs, distinction between traffic offered load versus achieved thruput, need for higher order statistics for service assurance, need for packet sampled measurements to preserve detail, statistical estimation and information modeling.

3.requirements for different storage and archive solutions, use of offline bulk file transfer to reduce processing overhead, use of data correlation/suppression/filtering to prune down volume of TE data, use of TE data to engineer LSPs for VPNs.


Q: Shahram Davari: are you suggesting end-to-end user traffic versus, probe kind of traffic.

A: Wai Sum: if you view network as a collection of nodes, traffic between any two pairs of nodes will be measured.

Shahram: time difference/delay between time packet is injected to when it is received, packets in transit may lead to error.

A: Wai Sum:traffic volume-based measurements (measurement interval defined) will help. three types of timeframes defined.

Q: recommend standard evaluations and measurements. is this a follow up activity?
A: after framework, MIB extensions, etc. will be done to carry out these recommendations.

Chris: comment on shahram's comment on accuracy, depends on architecture of network and infrastructure. A Layer 2 solution can give accurate numbers throughout the mesh.

Ed Kern: we need more discussion on this draft both before and if necessary during last call.

TEMIB Kireeti Kompella:

Revision of draft (rev2) reports all paths as opposed to just the active path
Now three tables: tunnel info, path info, and path hop info.

Version 03 of the draft is completed and will be published after the meeting Changed indexing and added conformance statement. Also added storagetype to each table and added basic security considerations

To do: Adress Textual Conventions for v4,v6, AS numbers, unnumbered interfaces, and LSP id's. (ways to implement involve writing, reuse bits, or reuse mpls tc mib)


Tom Nadeau: Prefer that you use mpls TC.

Kireeti: if no objections, that is what we will do.

Diffserv TE requirements: Jim Boyle

Things added to draft since last revision:

Mapping diffserv traffic to lsps - one OA to one LSP - both E-lsp and l-lsp. Also multiple OAs to one LSP with ONE bandwidth value

TE Class concept added: TE class is a pairing of CT and preemption priority. EAch CT has one or more active TE classes, 2 TE classes in different CTS can have same preemption priority, up to 8 TE classes supported.

Added example in Section 3.2 (EF class types),

Minor editorial changes.

Comments that were rejected:
Mapping multiple OAs to multiple LSPs.

Authors feel requirements are fully developed, very few open issues, propose going to WG last call. Comments solicited.


Dave McDysan: regarding preemption. Might be helpful to state that one might not want to really preempt traffic, rather make sure that higher priority classes have sufficient bandwidth. Low priority classes can be retried with lower bw or be routed over longer paths.

Jim: Should basically add verbiage that describes what happens as the result of preemption?

Dave: yes - want happens after preemption.

Francois: preemption inherited from existing mpls/te work. Did not redefine these things. Seems like these issues are basic TE and should not have a lengthy discussion in this document.

Jim: Can add this without a problem.

Francois: to address dave's comment, we inhibited preemption from existing TE work, not redefined, just focused on how this affects DS-TE. what Dave said is more applicable to general TE.

Jim: one or two sentences does not affect the draft.
Comment (?) : a couple of sections don't have requirements. A "default" model may be a good idea.

Shahram: is preemption now decoupled from CT?
Jim: yes.

Sudhakar: how to make sure configuration is correct on each LSR?
Jim: diligence.

Sudhakar: misconfiguration may cause problems.

Jim: this is a common problem with many protocols. Adding info in protocol to reduce this, doesn't always solve the problem.

Sudhakar: Could be a multi-area problem too.

Jim: OK

Francois: this misconfiguration issue has come up many times. A fundamental property of diffserv is to be flexible, but entirely relies on correct configuration. A clear decision in the MPLS WG is to stay with the principle of correct configuration, and not add signaling mechanisms to correct misconfiguration. Same principle is recommended here - rely on correct configuration of diffserv.

Francois: previous comment clarification sought (default model)

Jim: reqts draft is loose on bandwidth constraints. but DSTE draft has a "MUST" on bandwidth constraints.

Francois: Reqts draft has a statement on default model

Jim: make this a MUST

Francois - Diffserv TE protocol

Updates to draft:

Now will allow preemption across CTs to be disabled (allows different CTs to use same preemption, or any preemption level indpt of CTs.

IGP now allows 8 BW values can now be each used to advertise arbirtry pair <CT, preemption>.

Allows explicit RSVP signaling of CT.

Set up priority versus holding priority (possible to be different)

Provided TE-class mapping examples.

CT object for signaling, routing, neither (email thread):

Conclusion: agreed on desirable behavior - should be possible to allow establishement of CTO lsps, across non DS-TE support LSRs, and new DS-TE supporting LSRs, and CT1,2,3... across old (non-dS-TE) lsrs should be disallowed. Also, kept current text in draft, because it matched this desirable behavior (signal CTO LSP without CT object). Appropriate class num format also chosen for this.

bandwidth model: protocols specification separated from bandwidth constraint model. i.e., protocols specified independently of model.

Added formulas in Appendix for Russian Dolls model.

Live Demonstration of Russian Doll model. (nested CTs) :-)

RSVP-TE/CR-LDP protocol changes: added CT object (TLV for LDP), and associated error handling.

IGP changes:
Bandwidth constraint model Id added inside BC sub-TLV.

Added BC0 in BC sub-TLV so that a single sub-TLV can be used for all bandwidth constraints.

Aligned to terminology changes in requirements draft.

Added section for full backwards compatible with non-DS (traditional) TE.

Next steps: issue next revision with editorial changes, and issue last call to all relevant WGs (TEWG, MPLS, CCAMP, ISIS).


Sudhakar: why do we have to advertise bandwidth constraint model via signaling?

Francois: this is optional, you do not have to.

Sudhakar: if not necessary, why are signaling extensions necessary?

Francois: this is an optional sub-TLV.

Ganti: Why are we doing this extension?

Jim: Can you restate the question?

Ganti: Is it necessary to signal bw constraints model?

Francois: it is optional.

Jim: Are you talking IGP or signaling? There is a CT object in the signaling protocol.

Ganti: But there is a sub-tlv.

[insert confusion and then understanding that discussion is about IGP extensions notRSVP-TE signalling]

Jim: The whole concept of having optional tlvs in the igp is to help the head end predict what will happen when it signals a path. The reason that it is optional is because not everyone agrees that you want this in the IGP.

Francois: There are no new *required* TLVs for the IGP.

?- could we not signal complicated models?

Francois: can do it, but not desirable, therefore optional. bottomline - none of these extensions to IGP are REALLY mandatory, all optional. IT enables you to do accurate head-end prediction.

?- When traffic is mapped on LSPs, you did DS-TE. What is future work planned on interworking of DS-TE with policing units on network (example), for multivendor interoperability?

Francois: IETF builds blocks, but shouldn't standardize these functions. could have BCPs.

---End of session----


TEWG Update
TE MIB v. 02/03
Diffserv TE Requirements
Protocol Extensions for DS-TE