Current Meeting Report
Jabber Logs

2.7.4 Internet Traffic Engineering (tewg)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 03/25/2002

Ed Kern <>
Jim Boyle <>
Sub-IP Area Director(s):
Scott Bradner <>
Bert Wijnen <>
Sub-IP Area Advisor:
Bert Wijnen <>
Mailing Lists:
General Discussion:
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
Done  Another update of operational TEMIB draft
Done  All comments back on TE Diffserv requirements
Done  Submit revised TEBCPs and REAPP to AD/IESG for review
OCT 01  Submit TEM draft for AD review
OCT 01  Progress operational TE MIB to 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
  • - draft-owens-te-network-survivability-03.txt
  • - draft-ietf-tewg-mib-02.txt
  • - draft-ietf-tewg-qos-routing-04.txt
  • - draft-ietf-tewg-diff-te-reqts-05.txt
  • - draft-srisuresh-ospf-te-02.txt
  • - draft-ietf-tewg-measure-02.txt
  • - draft-ietf-tewg-restore-hierarchy-01.txt
  • - draft-ietf-tewg-diff-te-proto-01.txt
  • - draft-ietf-tewg-te-metric-igp-00.txt
  • Request For Comments:
    RFC3272 I Overview and Principles of Internet Traffic Engineering
    RFC3346 I Applicability Statement for Traffic Engineering with MPLS

    Current Meeting Report

    Internet Traffic Engineering WG - IETF 55
    November 20, 2002
    o) Agenda and WG Update
       Document status since last meeting.
       TE Applicability			RFC3346
       Survivability and Hierarchy		RFC3386
       IGP as second metric			RFC-ED
       CW BCP				RFC-ED
       TEWG MIB				no status
       Diffserv TE Requirements		IESG
       Diffserv TE Protocol			no status
       Diffserv Bandwidth models		no status
       TE Measurement			no status
    o) TEWG MIB - Kireeti
       Issue is how to define a hop (Textual Convention for hops) Going to 
    define TCs for HOPs in MPLS WG TC MIB, reference them in TEWG MIB
       Jerry Ash: It would be prefereable to merge the MPLS WG MIB and the TEWG 
    MIB, service providers would prefer to have one as opposed to two mibs.
       Kireeti: They serve different purposes, so they can stay separate.
       Jim: So TEWG mib will include reference into MPLS WG mib
       Kireeti: Just the MPLS TC MIB, which can proceed independent of LSR MIB, 
    or other MIBS in MPLS WG (Loa confirmed)
    o) Diffserv TE (proto)  - Francois
       Bandwidth constraint models and protocol drafts have been split.
       Really no recent comments on "protocol", most discussion is on BC 
       Drafts define the BC models
       Changes of proto-01 -> proto-02
    	- move RSVP-TE appendix into section of text
    	- CR-LDP appendix removed
    	- cleanup for IESG
       Outstanding issues on 02
    	- mostly clarity issues, seem resolved.
       Next steps?
    	- Most of room feel that the protocol draft is ready to "freeze" so WG 
    last call on list after -03 issued.
    o) BC models - Francois
    	- operates well w/ or w/o preemption
    	- efficient use of bandwidth
            - isolation across CTs
            - protection against QoS degradation
    	- simple
        3 documented models
    	- russian dolls model (RDM) (Francois)
    	- maximum allocation model (MAM) (Lai)
    	- maximum allocation w/ reservation (MAR) (Ash)
    	Comparison of models [see presentation]
        Propose to document not only one model but rather to document two 
    models. Propose that these two documented models be RDM and MAM.
        Noted that there really aren't outstanding issues on Russian Doll 
    o) Maximum allocation with reservation (MAR) - Jerry
        [see presentation]
        Jerry recommended that the MA model be the default BC model and that the 
    RD model be an optional BC model (should be used only when preemption is 
    also used).  Jerry also recommended that we continue to study possible 
    extensions to MA, such as MAR, to improve performance.
    o) Maximum allocation model and comparison - Waisum
        [see presentation]
        Draft is a comparison of MAM and RDM.  At some rates of signaling and 
    load, MAM provides less blocking probability for some classes (e.g. 
    service isolation)
        Proposes to have MAM as default model.
    o) Discussion on BC models - General
       Lots of discussion on this.  It was pointed out that if we do have a 
    normative reference to a BC model, it must be standards track.  Others 
    (modular) might be informational, experimental, or standards track (need to 
    determine track here).  However, we have multiple BC models on the table 
    here, and the requirements document says there must be a default BC model 
    for implementation.  So the question becomes: Is "one" of these the 
    default?  Or both? Or maybe should neither really be required, they 
    proceed non-standard until operational experience shows what people 
    really use (and thus should be required for implementation).  Some 
    discussion and opinions, but breaking up the question:
       Must there be at least one normative reference from the protocol draft to a 
    BC model [show of hands says "yes"]
       Must there be one and only one required bc model?  Or is more than one 
    required bc model ok.  [hands are split]
    o) Discussion on DSTE protocol drafts and how to proceed
       Obviously going to IESG, the proto draft must proceed with any 
    normative referred to bc models. However, we have to first involve other WGs 
    (OSPF, ISIS, MPLS).  Some discussion on whether to hold off until 
    conclusion on bc models prior to involving other WGs.  Bert indicated that 
    since we are going to WG last call on proto, just send some heads up to the 
    other lists.
       So we will send a heads up to other WGs shortly after IETF 55 and again 
    when WG last call starts (on proto).  If any feel the bc model is 
    relevant to how their WG (e.g OSPF, ISIS, MPLS) evaluates the 
    protocol, they can raise that issue.  We will send another reminder when the 
    BC model issue is resolved.
    o) Inter AS requirements
       [see presentation]
       Discussion on if TEWG is right place for these types of 
    requirements, show of hands indicated it was and there was no 
    objection.  Bert confirmed that was his understanding of where these would be 
    too.  Also, show of hands indicated it is about time to take this type of 
    requirements work on.
    o) TE Measurement draft
       Specific measurements
       - Use of node-pair measurements
       - Stats of carried load -v- performance
       - record/detect label-binding changes (e.g. topology changes)
       Next steps?  Propose that it is WG item against charter item and it is 
    ready for WG last call.
       Discussion: Most agree this is an important charter item.  Question is to 
    whether this draft has sufficient review to proceed.
       Merike Kaeo (IPPM WG Chair) stated that the need for consistent 
    measurement methods is obviously important, but after having read the 
    draft, it wasn't clear if that had been achieved [note: this is the 
    original issue w/ -02 discussed in Minneapolis].
       Jerry again stated his support for this moving forward.
       Although there were not many people in room who had read the draft, Bert 
    asked who would read this if WG last call was raised, and most raised 
    there hand.
       So it will go forward for WG last call, if there are folks with issues 
    with it, they will need to raise their concern.  It is also important to 
    make sure it has had thorough WG review, so there will be an attempt by Ed to 
    make sure it's not proceeding to IESG w/o only minimal review.
    o) DSTE link bundle options
       Augments DS-TE protocols, but DS-TE protocols (or requirements) don't 
    depend on it.  There seemed to be folks who indicated in audience that they 
    use link-bundles and want to do DS-TE so this is relevant work.
       As to WG item, Chairs decided to hold off for now.  Issue: If we 
    complete the core work for Diffserv TE, does further work on DSTE 
    protocol happen here or somewhere else?
    o) Wrapup
       Sub-IP lives (for now).  There are question in terms of where TEWG 
    heads as it finishes up its current charter. A dormant period? Or turn into a 
    more long-term concept group (w/o becoming a research group)?


    Protocol Extensions for DS-TE
    Bandwidth Constraints Models for DS-TE
    Max Allocation with Reservation (MAR) BW Constraint Model for MPLS/DiffServ TE
    Bandwidth Constraint Models for Diffserv-aware MPLS Traffic Engineering
    Inter-AS MPLS TE Requirements
    A Framework for Internet Traffic Engineering Measurement
    Link Bundling support for DS-TE