2.7.5 Internet Traffic Engineering (tewg)

NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01


Ed Kern <ejk@tech.org>
Jim Boyle <jim.boyle@level3.com>

General Area Director(s):

Fred Baker <chair@ietf.org>

General Area Advisor:

Fred Baker <chair@ietf.org>

Technical Advisor(s):

Rob Coltun <rcoltun@redback.com>
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: this WG is one of a set of WGs that comprise the 'sub-IP' pseudo-area that the IESG recently created. All of the sub-IP WGs are temporarily being housed in the General Area until the IESG decides on a final management structure for managing these groups. The Area Directors for the following areas acting as a group will be the Area Advisors: INT, OPS, RTG and TSV. The name(s) listed above under "Technical Advisor(s)" are the the responsible Area Directors for the 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:

Nov 00


Solicit TEBCP drafts concerning requirements, approaches, lessons learned from use (or non use) of TE techniques in operational provider environments.

Nov 00


Solicit vendor implementation similarities and differences informational draft (TEIMP)

Nov 00


Review and comment on operational TEMIB

Dec 00


Update operational TE MIB draft

Dec 00


TEBCPs submitted for WG comment

Jan 01


Comments to TEBCP authors for clarifications

Jan 01


First draft of TEIMP

Jan 01


First draft of TEAPP

Feb 01


First draft of TEM

Feb 01


TE Framework Draft to AD/IESG for review.

Feb 01


Another update of operational TEMIB draft

Feb 01


All comments back on TE Diffserv requirements

Mar 01


Drafts available for E-LSP and L-LSP Diffserv TE

Mar 01


Submit revised TEBCPs and REAPP to AD/IESG for review

Apr 01


Progress operational TE MIB to AD review

Apr 01


Any necessary protocol extensions for Diffserv TE sent to protocol relevant WGs for review.

May 01


Progress Diffserv TE E-LSP and L-LSP Diffserv TE drafts together to AD/IESG for review

May 01


TEIMP draft to AD review

Jun 01


Submit TEM draft for AD review

Jun 01



No Request For Comments

Current Meeting Report

50th IETF Internet Traffic Engineering WG (tewg) Minutes
TEWG Agenda: 50th IETF 0900-1130 March 22, 2001

0900-0930 AD Slot: Sub IP Intro, New Work (Restoration, Hierarchy Reqs)
0930-0945 Chair Slot: Agenda, Milestones Update
0945-1015 Applicability Statement: Vijay Gill
1015-1045 Diffserv TE
- Technical Update - Francois (10 minutes)
- MIB - Tom (10 minutes)
- Discussion (10 minutes)
1045-1100 TE Measurement
- Wai Sum (10 minutes)
- Discussion (5 minutes)
1110-1130 Other Drafts
- InternetII DiffTE(10 Minutes) (moved up to DiffTE section)
- COPS/TE - Jacquenet (10 minutes)
- QOSR-BCP - Gerry Ash (10 minutes)

0900-0930 AD Slot: Sub-IP Intro, New Work (restoration, hierarchy reqs)

Scott Bradner:
Clarify relationship between TEWG and other groups, particularly CCAMP.
tewg: defines what is needed, providing input to ccamp

What is clear is a couple of efforts need to go on. Work on hierarchy and restoration. Wants volunteers to work on this (design team) - particularly carriers. Please get in touch with Scott, Bert, Randy to say what category you fit in and what you want to work on.

Rob Coltun:
Issue here is what is needed by the community wrt hierarchy/restoration - not what is possible.

Sandra Ballarte: Q: restoration of packet layer or optical layer?
Jim Boyle: A: Intent is these teams are not limited to data layer.

Same Q & A for hierarchy

Jim Boyle:
TEWG Milestones Update

BCP docs - a couple put forward. A couple said they would and never did.
Time to push the ones we have to info RFC.

Operational TE Mib. No new comments for month or two. Need tech spin of the draft and can then move through the queue.

Kireeti - agreed.

Jim - once Kireeti gives next update is probably time for WG last call. Will initiate on list.

TE Measurement conceived in interim meet in Alberquerque. Idea that we should specify what it is that we need to get out of network to do offline number-crunching/config/etc. Number of related drafts now - one will be presented today. Another guy was going to present but can't make it. Need to take a look at these 3 drafts. Authors need to get together and consolidate into one for the next meeting.

Another "great" idea from interim meeting was to specify the implementation nuances between prevailing implementations being used out there for TE. Especially for providers with multi-vendor networks doing multi-vendor TE. nuances on call admission etc. No info gathered yet. As Protocols (LSP tunnel stuff, IGP extensions) move from proposed to draft an implementation note is required. feeling is that this isn't something we need to do right now. What is the feeling of the group? Will move milestone out if nobody objects.

TE applicability statement. Here - and have presentation on the agenda.

TE framework document. Did last call on list in Nov/Dec. No more heard since. Need to revive the doc and make sure that it is still what we want to push forward and move through queue if so. Efforts in near future to do this, and reissue last call (or open up for someone else to do a TE framework.) Got one or two volunteers for new editors.

Diffserv-TE. requirements and protocol specs being fleshed out in this WG.
There is need to revisit application requirements. (see mail by jboyle to list).


Curtis Villamizar:
- MIB does not compile, need more than a technical spin
- GMU & UNH for Interoperability & implementation informational notes
(TEIMP) -- Ed asked Curtis to contact GMU & UNH on providing input.


Vijay Gill:
applicability draft (30 min)

- TE and Its applicability
- draft-many-tewg-te-applicability-00.txt
- TE: unless absolutely needed, don't do it
- 5-8 service providers may have use for it, the rest don't (as opined by this presenter)
- Optimize for delivering IP transit at the lowest cost possible

Q: When do you use TE?
A: TE does not create capacity, only allows you to make use of unused capacity while capacity is being added. It's a short term fix! The other is reacting to failures.

- Watch out for the mailing list. It's been moved to te-wg@ops.ietf.org, the old list will be decommisioned in April
- no need to subscribe, the subscription list was migrated

Extensions to RSVP-TE and CR-LDP for support of Diff-Serv-aware MPLS
Traffic Engineering (protocol and requirement updates)

- Diffserv-aware TE , 4 drafts
- home for this work is in tewg; see updated tewg charter to the extent that the protocol work is ready for another WG.
- Minimal Changes/updates: don't need DS-TE in all networks; don't need TE in all networks.

Open items?

1. how many CTs should we allow?

current proposal is up to 4.

2 is the burning requirement.
4 is comfortable.
remember that one CT can comprise multiple classes.

examples - SP1 uses only existing TE (single CT.)
SP2 uses 2 CTs (Data, Voice)
SP3 uses 3 CTs (Voice, low loss data, BE)

should we allow more?, should the number be fixed?

2. how should preemption work across CTs.

Current proposal is that CTs are orthogonal to preemption levels.

3. Relationship between BW reservation and scheduler? Static scheduler risks mismatch between weight of queue and reservation; Is dynamic programming of scheduler a desirable option for SPs?

4. How to minimize impact on IGP scalability? For each CT, can have up to 8 preemption levels; TE Database size is impacted even with compression of info advertised; More configuration would be required to get a balance between advertised info & TE size.

- Plan:
1. Produce a application requirements document, requirements document was originally written as a protocol requirements document. Need SP requirements: problem statement; requirements on number of CTs, preemption; configuration parameters; alignment with scheduler; etc. review solution against requirements.

2. Pick a solution that matches requirements. How? Several items are interrelated.

3. Align protocol extensions (MPLS crldp/rsvp-te, ISIS, OSPF)

- shouldn't state that can't do dynamic control of sched. Should just decide if static is enough for some. Dynamic might be good for others.
- bandwidth backup consideration vs backup with bandwidth reservation needs to be flushed out

Ben Black Q: This seems to be a solution in search for a problem. How much requirements are there from SP?
Francois: A: That's why we are looking for service providers
Ed: so, it a solution in search of a problem.
Jim: if you are an SP and using TE and have need for this work, please get involved with this work
Curtis: it's a chicken and egg problem. We need to get people interested in this problem by proposing a solution. We do see some interest but not sure if SP will actually deploy it if it's built.
Jim - if this is build it and they will come then take that to ADs "this is the problem we think people will have".


Tom Nadeau:
10 tom nadeau (mib specifics)
15 discussion

- Motivation: expose DS-aware TE; MIB is based on implementation
- Overview of tables
- Open items: currently 4 CTs. Any more? Should we include overbooking in the tunnel entries?
- Conclusion: useful; based on real implementation, adopt as WG document?
Jim: We need to get application requirements before focussing on technical specifications.


Ben Teitelbaum (ben@advanced.org)
Internet2 experiences w/ cisco DS-TE

- Abilene backbone trying to implement a Qbone Premium Service domain
- aim is edge to edge EF "virtual trunk"
- Cisco & Internet 2 agreed to a trial
- 185 participants in the target network
- Early hopes for DS-TE: hoped for resource accounting and admission control; hoped for up-calls under failures by use of a tunnel; delay constraints; trunk-style classification and policing; mechanism to protect PQ resources from non-policed connectors
- After briefing, understood that DS-TE only addressed first item!
- Implementation vs draft: only 2 CTs: CT1 bounded by Max Reservable CT1; CT0 bounded ; only on OSPF not ISIS.
- Test networks: 3 GSRs; verification of basic/aggregate MPLS TE with global pool (CT0); route selection based on AW; re-routing under failure; series of test on sub-pool mechanisms.
- Results: verified that sub-pool route selection based on BW availability works; separate CAC; preemption orthogonal to BW pool
- Conclusion: DS-TE worked as advertised; potentially useful tool in kit (if TE needed for non-premium traffic); complete test report to be made public.

Ed: This was tested in a small test network, of a test network, any plans to roll it out on the real test network (Abilene)?
Ben: Abilene is production environment, so no time soon (w/o need)

Trici: why do you say works as advertised when your first slide indicated you hoped for several features but only got one?

Ben: mean the implementation matches the only one problem that was addressed (signalling cac)

Francois: Just a clarification DS-TE is not trying to solve all QoS problems

There was some discussion about how much traffic on a link can be EF before the service degrades, and the relationship to packet size, etc.. It was clarified that we are addressing the signalling aspect, and PHBs are addressed in other groups.


Framework for Internet Traffic Measurement
Wai Sum Lai:
- related drafts by B. Christian et. al,
- related drafts by S. Van den Berghe.
- http://www.itu.int/ITU-T/com2/index.html
- Q 9/2: TE for networks supporting IP services
- Invite to join work in this area between ITU and IETF
- Uses of Traffic Measurements: Traffic characterization; network monitoring; traffic control
- Traffic Matrix statistics is primary topic to be able to engineer network properly.
- Schedule: first draft in Feb 01 and submit TEM in Jun 01 for AD review. Propose to include this as a WG item.

Jim: need to get together with Stephen and Blaine to see where you have commonality and other authors from vendors to produce a set that is usable by service provider, this isn't necessarily the super-set.

Trici: Is measurement limited to user data traffic? We need control traffic measurement as well.
Wai: Signaling control traffic; routing control traffic;

Q: mentioned you can do cap plan and all that stuff. Know we can create a lot of LSPs in a trunk and keep on building it. Sometimes routing decisions based on reserved b/w not that good. Based on traffic better. But instant load decisions can lead to oscillation. Perhaps we could advertise statistical loads and make routing decisions based on that. Vendors say very hard to do. But reserved bandwidth isn't an accurate picture. Historical or statistical load is better. Want that sort of thinking to go on.

George Swallow - experience on ArpaNet where things were dynamic is that stats are good for offline planning, but allowing routing protocols to get involved leads to very strange things.

Jim - you can accomplish a lot with sub-perfection.


COPS Usage for IP TE policy enforcement
Christian Jacquenet: draft-jacquenet-ip-te-cops-01.txt

- Motivation: high level of automation; honor commitments to customers; efficient management of resources.
- next steps: submission of Ip TE PIB
- finalize prototype development
- some extensions on the horizon
- set up an experiment in April 2001 and submit applicability statement
- Issues & questions: need to finalize semantics & content of the IP TE policy provisioning data; Scalability;

Q: This is good work and There is complimentary work in RAP- may be should get together with other working on this.

Curtis - TE WG usually tries to establish requirement before doing any work.
COPS has been presented in the past and there has been no consensus that we have a requirement.
Ed - issue is not if it is interesting. Grey area is "is it going to be here". Won't do this work in a vacuum (e.g. w/o need).


Jerry Ash: draft-ash-ccamp-multi-area-te-reqmts-00.txt

Goals & Outline: requirement of multi-area TE merged work from several drafts.
Requirements: minimize routing overhead; support various multi-area TE routing methods; multi-area information exchange;
- Extend to inter-domain TE requirements

- Propose to adopt as WG document

Jim: we are not accepting any WG documents in this area until we have requirements
Jerry: This is a requirement document
Jim: We need to assure that we have sufficient operator input
Jerry: you have operator input: AT&T
Vijay: don't understand what this draft is trying to do?
Jerry: relevant for any network with multi-area topology
Q: many vendors on the author's list but not enough operators; it's just a long list of various vendors input.
Jerry: dis-agree, the various requirements do not match specific solutions; the fact we reference drafts does not mean we imply those specific solutions
McDyson: need coordination between these requirements and those for restoration
Q: do you see a need for multi-area?
Jim: Many of the largest ISPs are running a single area IGP today

Updates & changes from version 00:
- next step to propose to go to last call
Jim: don't see a WG last call need, will just push it forward.

Cutris: BCP or Informational? Are these really common practices?

Jim: Although we are referring to these as BCPs, they will be pushed forward as Informational.


Agenda / Applicability of MPLS TE
Diff-Serv-aware Traffic Engineering
Cisco DS-TE Lab Trial
A Framework for Internet Traffic Measurement
A COPS client-type for IP Traffic Engineering Policy Enforcement
Requirements for Multi-Area TE
Traffic Engineering & QoS Methods for IP-, ATM-, & TDM-Based Multiservice Networks