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
Chair(s):
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
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
- No modifications to the agenda
AGENDA:
Presenter |
Topic |
Time |
E. Kern |
Agenda bashing |
10 |
D. Awduche |
Towards a framework for Internet TE |
20 |
G. Ash |
draft-ash-itu-sg2-routing-guidelines-00.txt |
10 |
G. Swallow |
draft-swallow-rsvp-bypass-label-00.txt |
10 |
D. Fedyk, |
draft-ietf-fedyk-mpls-te-metric.00.txt |
10 |
I. Widjaja |
draft-elwalid-icmp-ext-00.txt |
10 |
H. Hummel |
draft-hummel-oct-te-00.txt |
10 |
Andersson |
draft-andersson-reroute-frmwrk-00.txt |
10 |
K. Owens |
draft-makam-mpls-protection-00.txt |
10 |
W. Wimer |
draft-wimer-ospf-subareas-00.txt |
10 |
Wai Sum |
Report on ITU-T TE Work |
10 |
General Discussions |
20 | |
Awduche/Kern |
Path forward |
10 |
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:
- A design team is working on the TEWG framework document. A preliminary draft is due by the end of Nov 1999.
- Design team consists of two service provider folks: D. Awduche (UUNET) & A. Chiu (AT&T), as well as A. Elwalid of Lucent and I. Widjaja from Fujitsu.
2. The contents of the framework document would encompass the following issues (but not exclusively):
- The framework would cover: principles, techniques, and mechanisms for Internet TE.
- It will catalog and categorize techniques and methodologies in existence or in advanced development. It will also discuss their characteristics and describe scenarios in which they may be useful.
- The focus initially would be on intra-domain routing issues as well as intra-domain resource allocation issues. Inter-domain aspects may also be considered at a later time.
- Technologies in current use for Internet TE include MPLS, ATM, and FR. Of these, MPLS appears to be the most promising for IP networks at this time. These aspects would be covered in the framework doc.
- Constraint based routing (CBR) issues and relevant generic routing requirements for TE will also be considered.
- TE in DiffServ domains is a very important and timely topic. TE considerations in Diffserv contexts will be discussed in the framework draft. A number of additional informational drafts may also be issued on this important topic.
- In Diffserv and multiservice environments, TE will be expected to establish relevant resource sharing parameters so that the network provides a set of performance oriented preferential services as defined by a set of policies and service models.
- Awduche suggested that in general, QoS in large public IP networks may be difficult to attain, perhaps even impracticable without TE.
- The WG may recommend new protocols to use for TE. It may also suggest improvements to existing protocols to support the TE function. The WG may also suggest guidelines for some aspects of TE.
- Why is TE required? Awduche indicated that n inspection of a large scale public IP network with very complex topology (e.g. UUNET's network) provides the necessary motivation. The current impetus for TE is driven mostly by service providers and is a result of the issues they encounter in building and operating the new public networks.
- Traditional IP routing and measurement paradigms are clearly inadequate for such networks.
- A central goal of TE is to apply technology and scientific methods to the measurement, modeling, and control of Internet traffic. The control policy may take into account the network cost structure and revenue model.
- The traffic oriented problems include loss, delay, delay variation, good-put.
- Simply adding bandwidth is necessary, but not always sufficient to address network performance problems.
- A major objective of TE is to minimize congestion. This can be done using predictive &/or reactive techniques.
- To achieve the TE objectives both on line and off line mechanisms and support systems are needed
- Current mechanisms in place use traffic-trunk concepts for traffic aggregation/dis-aggregation, and for distribution of traffic onto the transmission facility.
- TE practices should be automated whenever possible to reduce operational burden
- Support is also needed for the collection of statistics for capacity planning purposes.
- Awduche enumerated some of the current issues with TE in the Internet which include:
o Inadequate measurement and control mechanisms,
o exponential growth of offered traffic,
o asymmetric & dynamic traffic patterns,
o network topology may be orthogonal to the traffic matrix
o Classical teletraffic theories and models have been found not to be applicable
o Internet traffic characteristics is not yet well understood.
o Lack of adequate operational tools and support systems for TE.
3. Next steps:
- Next steps for the WG: Issue the frame-work document by end of Nov, followed by a document on "Generic representation of common objects, functions, and data sets for TE"
- Awduche noted that these two documents will help to define the problem space and clarify the critical issues.
G. Ash, AT&T; Draft-ash-itu-sg2-routing-guidelines-00.txt
Continuation of the talk in mpls working group (see minutes)
- Draft presents algorithm to improve bandwidth efficiency using alternate path routing
- State dependent routing (SDR) widely used already in other networks
- Instability due to poor route selection may lead to loss of 50% of bandwidth
- 1-link followed by 2-link selection is one example of such problem
- Dynamic bandwidth reservation is widely used in non-hierarchical networks
- Algorithm checks for minimum bandwidth on each link in the path before the path is selected
- Example was given with 10% overload, preferred traffic does better showing that technique is effective in preventing instability
- Also see references in the draft for more examples of studies (both simulation and analytic)
- These techniques may also be applied to mpls networks for LSP setup (hence the presentation to mpls WG)
- A 135 node network model showed a scenario which leads to three times as much loss if algorithm not used
- ALB flooding with SDR can be resource intensive
- Event dependent methods (EDM), the alternative does not use flooding
- Slide covered 4 methods of implementation of SDR and EDR, & applications
- Comparison of SDR and EDR shows latter's advantages
- EDR needs search for SP, if search failed then use crank back or explicit feedback to retry
- Conclusions:- dynamic bandwidth reservation should be considered
- SDR without flooding is possible for mpls LSP route selection
- Would like this to be considered in future drafts
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)".
- Ans: The example given in some of the slides was for a network with a low degree of connectivity (about 15-20%) and therefore the instability phenomenon applied to those networks as well. In addition, some of the results given in the draft, which also illustrate network instability, are based on a highly connected network model.
G. Swallow, Cisco; MPLS TE Restoration
Extensions to rsvp to help with protection
- Has been working on how to deal with labels in the face of network link and nodal failures
- Defined terminology: a tunnel is an abstract object, tunnel has source/destination and one or more path associated with it. Latter would change when restoring the tunnel
- A Bypass tunnel is a redundant tunnel which may be used as part of restoration e.g to deal with node failures (as opposed to link failures which may be solved with an alternate path between the two nodes)
- Objective is to reroute in 50 ms or less in a scalable fashion
- Question is how to distribute the relevant labels to do a bypass
- Objectives for signaling these labels are: identify backup tunnels; associate primary and backup tunnels; work with global and non global (per interface) label space
- Solutions to extend the session object and change the sender template (did not elaborate??)
- Merge should be enabled for this purpose
- By pass at every hop is not really scalable or more than you need to do, may be optimized using a route report object
- So have added a sub TLV to report the C-type and some new "flag" values
- A message back to the head end is also included, useful for multi-area case, also explicitly notifies bandwidth reduction, and not just failures
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
- Repeat of presentation in the IS-IS WG
- Path oriented world may benefit from a few metrics such as delay, cost, hop count, bandwidth, others?
- Idea is to allow different metrics on different links of the path in calculating total path cost. May be advantageous
- Currently focus is on bandwidth as the metric; WE like to see five including the IGP metric
- What about resource classes defined in CR-LDP; is a 32 bit vector which defines the resource class membership of a given link
- May need to standardize specially for multi routing domain case
- Logically AND the Resource-Class in the CR-LDP with the links Resource-Class
- The fields of the vector: satellite/terrestrial | highest, high, medium, low | etc....
- IS-IS group asked authors to proceed with TLV encoding for metrics
- No resolution on the resource class concept
Qs: What is a hop count?
Difficult to measure when crossing L2 networks
Widjaja, Fujitsu, ICMP Extn for 1-way performance metrics
draft-elwalid-icmp-ext-00.txt
- Motivation: need to measure the characteristics of a path for TE when faced with asymmetric traffic patterns
- RFC-2679 and 2680 1-way metric already available (IPPM)
- Also look at MATE scheme presented at Oslo
- Load balancing among LSPs is achieved by using MATE features
- MATE has 4 functional blocks: Filtering; TE; measurement and analysis; and LSP mapping
- Use probe packets to measure 1-way delay
- MATE alternates between network monitoring phase; once significant change is detected the TE algorithm is invoked to do load balancing
- Results show stability of load balancing case presented at MPLS conference (UUNet-1999)
- One way packet loss metric: Source sends probe packets (similar to ping to a destination)
- ICMP extn may be used to implement the technique
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
- Ans: the intent is to realize the mechanisms for implementing the one-way delay and one-way loss documented in RFC2679 and RFC2680, and satisfying the probing application for traffic engineering purpose. The proposed protocol should be extensible so that other related applications may be added later.
Qs: How to ensure that payload and probe follow the same path/hops?
Having the same FEC may not be enough?
- Ans: Probe packets are sent down the same LSP as data packets at the ingress, hence payload and probe follow the same path.
Qs: Why is clock sync not an issue?
- Ans: If one wants to measure absolute delay, then clock sync is required. If one only wants to measure relative delay such as in our TE application, then clock sync is not an issue. Clock sync requirement is application dependent, and is beyond the scope of the memo.
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
- Ans: Probe packets with the same FEC and the same DS codepoint as data packets will follow the same path and receive the same treatment at intermediate nodes.
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
draft-hummel-oct-te-00.txt
Traffic should be conducted like an orchestra
- A central maestro is required which sets the limits of behavior for independent customers of resources in a network (German autobahn example)
- Each domain should have a central conductor, helps with load balancing
- Load balancing algorithm; define traffic stream as src/dst/class;
Which LSP to choose
- Conductor collects stats from edges and the network re the load
- Predict the coming traffic patterns
- Compute the likelihood of which LSP leads to load balancing
- Send the decision to the edge which builds a "stage function" to help with selection of the LSP
- Algorithm may allow for aggressive vs. conservative shifting of the load
- Requirements are to be fair, discriminate based on class, and be resource efficient
- Author recommends a framework document for this approach; may also collaborate with policy WG which may re-use the likelihood graphs (the "stage function")
- Bandwidth brokerage may also be linked with the TE conductor
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
- Will also be presenting at MPLS wg (also see the minutes there)
- Restoration steps were enumerated
- Requirements are restoration time and coverage criteria (how many LSP's are protected)
- Authors ask for input from service providers as to the requirements they like to see
Qs: None
K. Owens; Tellabs; Protection/Restoration for TE in IP networks
draft-makam-mpls-protection-00.txt
- Outline: Motivation; what protection is, next steps
- L1 and below have no view of upper layers
- Generic protection frame work may help with TE objectives in multi vendor environments
- Requirements: ability to be granular in selecting the protected traffic; static vs. dynamic algorithms
- How about redundant bandwidth? Is it reserved or preemption may occur
- Revertive and non-revertive PS may be required (similar to SONET PS)
- Impairment detection is required such as link probes, packet loss counts etc.
- Each protection group has a working and a protection path as well as switching and notification points
- Bounds on PS interval is required
- Path protection requires: configuration; detection; propagation of failure discovery to switching point
- Followed by recover phase
- Next steps: Authors request that the draft be included in the frame work document
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
draft-wimer-ospf-subareas-00.txt
- Partition the network to sub-areas
- Minimizes the number of upgrades in a given sub-area
- Applies to IS-IS routing also
- Area Border Routers (ABR) see own full topology and an abstract of neighboring areas
- Inside or outside designation of a link determines area boundaries
- Opaque LSAs (type 10) are used for summary distribution
- ABRs translate the summary into normal LSAsMechanism to negotiate I/O links between two neighboring routers
- This is a hierarchical TE technique; work is in its infancy
- Open issues are: How to represent topology in an abstract way
- ftp://ftp.fore.com/standards/internet-drafts/etc... for up to date copy
Wai Sum AT&T: Report on ITU-T TE Work
Current ITU-T WP 3/2 work:
- Traffic engineering Recommendations for IP access networks
- Two draft Recommendations were produced and to be approved at March 2000 meeting of SG 2:
- E.651: Reference connections for TE of IP access networks
- E.671: Post-selection delay in PSTN/ISDNs using IP telephony for a portion of the connection
- Future workplan for Study Period (2001-2004)
- Recommendations for IP access networks covering HFC, DSL, wireless
- Recommendations for VoIP, measurements, control and dimensioning, and interconnection between operators
- Question: What's the difference between I.380 and your work? Recommendation I.380 was developed by SG 13, which is the lead Study Group in ITU-T on IP issues. In terms of performance objectives, there is some overlap between SG 13 and SG 2. However, the emphases are different. SG 13 defines the protocol mechanisms and their requirements including interface requirements. SG 2 defines traffic engineering methods and algorithms for operation inside the network.
In closing, chairs:
Heads up:
- March 2000 TEWG meeting, the framework document would be the key item on the agenda
- Please read it before the next meeting
- Need input from Service Providers
- Please supply requirements for TE to the mailing list.