2.7.4 Internet Traffic Engineering (tewg)

Last Modified: 2003-05-28

Ed Kern <ejk@tech.org>
Jim Boyle <jboyle@pdnets.com>
Sub-IP Area Director(s):
Bert Wijnen <bwijnen@lucent.com>
Alex Zinin <zinin@psg.com>
Sub-IP Area Advisor:
Bert Wijnen <bwijnen@lucent.com>
Mailing Lists:
General Discussion: te-wg@ops.ietf.org
To Subscribe: te-wg-request@ops.ietf.org
In Body: subscribe
Archive: http://ops.ietf.org/lists/te-wg
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
modeling, characterization, and control of internet traffic, and the
application of such knowledge and techniques to achieve specific
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
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
group to abstract and define those parameters, measurements, and
controls that traffic engineering needs in order to engineer the

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

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

- 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  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
  • - draft-ietf-tewg-mib-05.txt
  • - draft-srisuresh-ospf-te-05.txt
  • - draft-ietf-tewg-measure-06.txt
  • - draft-ietf-tewg-diff-te-proto-04.txt
  • - draft-ietf-tewg-te-metric-igp-02.txt
  • - draft-ietf-tewg-diff-te-russian-03.txt
  • - draft-ietf-tewg-diff-te-mar-01.txt
  • - draft-ietf-tewg-interas-mpls-te-req-00.txt
  • - draft-ietf-tewg-diff-te-mam-00.txt
  • Request For Comments:
    Overview and Principles of Internet Traffic Engineering (RFC 3272) (190384 bytes)
    Applicability Statement for Traffic Engineering with MPLS (RFC 3346) (33754 bytes)
    Network Hierarchy and Multilayer Survivability (RFC 3386) (65345 bytes)
    Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering (RFC 3564) (50808 bytes)

    Current Meeting Report

    list.   Internet Traffic Engineering WG at IETF 57
       Vienna, Austria 14 July 1300-1500
       Chairs:  Jim Boyle, Ed Kern
       ADs:	    Bert Wijnen, Alex Zinin
       Minutes: Jim Boyle and Dave McDysan
    o) Went over agenda and WG update 
       - DSTE protos and BC model drafts to go to WG last call after the
      - TE Measurement draft (-06) has been revised.  It missed cutoff so
        it should post after meeting.
       - draft-ietf-tewg-mib-04.txt
            - Bert pointed out MIB syntax errors
            - Revision should be done by end of July
    o) DSTE
    +  Francois Lefaucher
       - draft-ietf-tewg-diff-te-proto-04.txt
       - "Max Reservable Bandwidth" is to be interpreted as an aggregate
         constraint across all CTs
       - "Link Bandwidth" does not play a role in CAC
       - Overbooking
         - Core specification for DSTE will cover use of LSP size or Link
           Size methods
         - Local overbooking method will be progressed separately
       - Changes to drafts
         - Took out references to LOM
         - updated CAC formulas (e.g. no use of link bw)
         - updated MAM definition (to account for aggregate constraint)
         - added section of DSTE scenarios in MAM
       Yakov: work in CCAMP related to shared-mesh restoration.  In
       this there are separate BW pools, but in RDM, the pools are
       subsets, so how do these work together?
       Francois: Will look into and say if there is or is not an issue
       and if it needs to be addressed or not. (w/in 2 weeks)
    +  Jerry Ash
       - draft-ietf-tewg-diff-te-mar-01.txt
       - MAR similar to MAM, but allows CTs to exceed their BC (w/o 
       - builds on methods in use for 10 years
       - Changes to draft
         - notation in line with Diffserv TE
         - added section on applicability (scenarios)
         - added section on setting BCs for MAR and MAM
         - moved simulation analysis to an annex
       - Next step is ready for WG last call for experimental with other
         BC model drafts
       Yakov: raised that same issue for RDM and shared mesh restoration
       also an issue for MAR
       Jerry: Agrees that this is an issue to look into and understand.
    +  Waisum Lai
      - draft-wlai-tewg-bcmodel-02.txt
       Purpose is to provide a relative BC model comparison
       - Changes to draft
         - More explanatory text for performance measures
           - LSP blocking and QoS degradation
           - BC model design considerations
         - New results
           - performance under partial preemption, blocking
       - General trade-off (RDM, MAM)
         - major difference is BW sharing (RDM) -v- isolation (MAM)
       - Next step to submit as individual submission with review by TEWG
       Waisum: Procedure for progression is still individual but would
       like TEWG review.
       Chairs: Suggesting that it has been reviewed by TEWG means maybe it
       should be a TEWG document (which would necessitate another level of
       document review and feedback).  Suggest that for now it should stay
       as individual contribution.
       Francois: Comment that the BC chose for RDM seem to to be not very
       in-line with how RDM should be used, which skews the results
       towards MAM.  Suggested parameters have previously been sent to the
    +  Waisum Lai
       - draft-wlai-tewg-overbook-00.txt
       - per-domain per-CT overbooking is defined in core specs (e.g. PROTO)
       - this draft discusses per-link, per-CT overbooking
         - two approaches, component based or integrated (this draft)
       - Component
         - Unreserved BWs still effected by the LOM
         - use of new concepts, new formulas required based on 
         - proposes to put max reserv BW to the link BW to simplify
       - Integrated
         - single formula for all overbooking approaches
       - Next steps?  This (as with BC models) is experimental, author's
         view is that it should move forward when the work on it is
         reviewed by the WG.
       Francois: indicated that this work is an alternative to the
       overbooking approach which had been progressed and agreed so far by
       the WG (ie Link Size Overbooking + LSP Size Overbooking +
       LOM). Therefore, at this stage, the approach described by Waisum
       should be considered as a "contending" approach for the
       Experimental Spec but not as the agreed/default approach .
       Jim: Question as to what throttles an experimental document
       Francois: WG consensus can and should be the throttle
       (this also seemed to be consistent with view of Bert Wijnen and Ed
       Kern and many in the room - comments to the list appreciated)
    +  Francois
       - clarification of MPLS semantics for DSTE over bundles
       - says it is not quite obvious how to do this, thus the draft
       - since this is DSTE, it is in the charter
       - no new protocol specification, but modifies semantic
         of existing protocol elements, e.g. p -> TE Class := [p, CT]
       - probably obvious to those that are up to date, but nonetheless it
         should be written down.
       Jim: So is this the only MPLS derivative technology (e.g. FA-LSPs,
       restoration), etc... where there is a semantics issue?
       Kireeti: This is true (e.g. FA draft) , so better to address all of
       them at one time.
       Jim: maybe address in proto draft
       Francois: Will look into doing this in proto draft if possible,
       however if the issue of how to address generically all MPLS
       derivative technologies (FA-LSP, restoration...) can not be easily
       documented within next couple of weeks, then we should do this
       outside of proto so as not to hold-off -proto.
       Yakov:  Points out that again we need to make sure how generally
       mapping "priority" to "te-class" may impact "bw-pools"
       e.g. shared-mesh restorations.
       Kireeti: Suggest maybe to use general concept of bw-pools, and map
       DSTE on top of that, and BC models, then say how to map "priority"
       to "bw-pools"
       Jim: suggest that DSTE TE-classes may be general enough.
       Kireeti: Three cases need to be considered: classic TE, DS-TE,
       shared-mesh restoration. As long as parameters in IGP-TE, RSVP-TE
       don't change, the semantics (may) only need to be re-defined.
       Francois: Agrees that priority values are an index into something,
       however that can be mapped into different things (e.g. DSTE).
       Would like to address this outside of proto drafts (so as to not
       cause any delay on them), perhaps in a separate document to show
       how semantics should be dealt with in the context of DSTE.
       Jim: Let's specify the issues to the WG list and agree on them and
       which need to clear to proceed proto, RDM, etc...
       Francois: will try to include this in the two weeks before proto
       draft last call.
       Jim: summarized two snags
            1. Shared mesh restoration interaction with RDM, MAR, MAM
            2. Issue of mapping of semantic p to TE Class or something 
    	   for DSTE, and where to capture this.
    o) Multi Area / Multi-AS TE
       [Unfortunately, only 25-30 minutes was left in the meeting after
       the DSTE discussion]
    +  Raymond Zhang
       - Changes
         - organized to 3 objectives
    		(1) bw guarantee
    		(2) optimization
    		(3) restoration
         - also distinguished between multi-AS w/in and across
           administrative domains.
       - Section 5.2, added confidentiality and controls across
         administrative domains.
         - policy control at boundaries
         - re-writes (e.g. reroute objects, DS-TE, etc..)
         - Next steps for -01 document:
                - include explicit nodes in transit AS (ISP w/ multi-AS)
                - Add accounting requirements
                - Consolidate section on communicating integrity to HE LSP
       Rudiger (?) (DT) - Inter-domain DSTE should be possible, thinks
       this should be a MUST.  Next comment is OAM should be a MUST.
       Raymond:  Some of these might have previously been MUST, but
       changed due to comment, but this comment will be considered.
    +  Jim Boyle
       - Need to cover multi-area, as there is interest but multi-as
         doesn't cover it.
       - secondary point is to show that it's not hard to address both
         multi-as and multi-area
       - To show similarities, broke out some functional areas and
         compared and contrasted recommendations for multi-area /
       - Next steps- recommend one of the following:
            1. develop/refine this draft or else have someone step forward.
            2. merge into the inter-AS requirements draft
       - JPV:  Thought we already decided to progress multi-area and
         multi-as as seperate documents?
       - Jim:  Yes, just thought it was pretty easy to show how these can
         be addressed at the same time.  But doesn't mind either
         incorporating inter-area into inter-as WG item, or progressing
         this (or someone else's inter-area req's) separately.  Main point
         was to not let inter-area be passed over.
       - JPV: But multi-AS requirements are very different than
         multi-area, is that not agreed?  E.g there is need for policy
         control.  How is that relevant to multi-area
       - Jim It is not, multi-area does not need policy, the 
         are not the same, they are only similar.
       - Yakov: There is no need for policy control in some multi-AS
         either, only when AS boundary is same as administrative domain
         (e.g. company) boundary.
    +  Kireeti Kompella
       - draft-ayyangar-inter-region-te-00.txt
       - Region== IGP area | AS | sub-AS | routing realm (overlay) |
         domain (optical)
       - Multiple LSP pieces in each region
       - LSP "pieces" or "segments" per region which are stitched or
         nested together.
       - Scheme is inherently recursive
       - Nesting provides good scalability
       - Each region retains autonomy, can decide to stitch or nest
       - Crankback stays within region (when possible)
       - Each region can have its own protection/restoration
       - Email comments solicited on the tewg list.
       Dmitri P: What's new here is the rules for crossing a region as
       opposed to (as specified in the LSP hierarchy draft using the
       switching capability field of the ISC descriptor sub-TLV) the
       crossing of a technology boundary to form forwarding adjacencies It
       would be worth to be expand on this.
       <Name?>: concern on local optimization, what happens during
       Kireeti: with topology hiding, global optimization cannot be done
       unless the end-to-end LSP is re-optimized by the
       head-end. Alternatively, each region can perform local
       JP Vasseur: Flag in LSP attributes object can prevent local
    + Jean-Phillipe Vasseur
      - draft-vasseur-inter-as-te-01.txt
      - Summarized two scenarios
          1. Sequence of loose hops expanded in each AS
          2. Request passed to one or more Path Computation Servers
            - PCS can compute end-to-end optimal (i.e., shortest path)
    	  since it has global knowledge.
            - Summarized the two scenarios in a chart
            - Summarized many changes to rev-00
            - Added new LSP attribute with flags (crankback allowed,
    	  contiguous LSP required (to prevent mid-point
    	  reoptimization), stitching required)
            - Ongoing implementations and several planned deployments
            - Next steps: continue discussion in tewg, ccamp, where?
            - WG chairs and ADs will work on where this draft (and loose path)
    	  should be addressed.
            - Presented to mpls wg in SF.
            - Summary of changes


    DS-TE protocol Extensions
    Max Allocation with Reservation (MAR) BW Constraint Model for MPLS/DiffServ TE & Performance Comparisons
    Bandwidth Constraints Models for Diffserv-aware MPLS TE: Performance Evaluation
    Use of Overbooking in Diffserv-aware MPLS Traffic Engineering
    Link Bundling support for DS-TE
    Inter-AS MPLS TE Requirements
    Inter Area / Inter AS TE
    Inter-Region TE
    Inter-AS MPLS Traffic Engineering
    Reoptimization of explicit loosely routed MPLS TE LSP paths