draft-ietf-tewg-measure-01.txt   draft-ietf-tewg-measure-02.txt 
Traffic Engineering Working Group Wai Sum Lai Traffic Engineering Working Group Wai Sum Lai
Internet Draft AT&T Labs Internet Draft AT&T Labs
Document: <draft-ietf-tewg-measure-01.txt> Document: <draft-ietf-tewg-measure-02.txt>
Category: Informational Blaine Christian Category: Informational Blaine Christian
UUNET UUNET
Richard W. Tibbs Richard W. Tibbs
Oak City Networks & Oak City Networks &
Solutions Solutions
Steven Van den Berghe Steven Van den Berghe
Ghent University/IMEC Ghent University/IMEC
November 2001 March 2002
A Framework for Internet Traffic Engineering Measurement A Framework for Internet Traffic Engineering Measurement
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 50 skipping to change at page 1, line 50
1. Abstract 1. Abstract
In this document, a measurement framework for supporting the traffic In this document, a measurement framework for supporting the traffic
engineering of IP-based networks is presented. Uses of traffic engineering of IP-based networks is presented. Uses of traffic
measurement in service provider environments are described, and measurement in service provider environments are described, and
issues related to time scale and read-out period are discussed. issues related to time scale and read-out period are discussed.
Different measurement types are classified, with each being Different measurement types are classified, with each being
specified as a meaningful combination of a measurement entity and a specified as a meaningful combination of a measurement entity and a
measurement basis. measurement basis.
For interoperable compatibility, uniform definitions across vendors
and operators must be ensured, e.g., in the distinction between
offered load and achieved throughput. To aid network dimensioning,
mechanisms to collect node-pair-based traffic data should be
developed to facilitate the derivation of per-service-class traffic
matrix statistics. For service assurance, there is a need for the
use of higher-order statistics. To preserve representative traffic
detail at manageable sample volumes, there is a need for packet
sampled measurements.
Table of Contents Table of Contents
Status of this Memo................................................1 Status of this Memo................................................1
1. Abstract........................................................1 1. Abstract........................................................1
2. Conventions used in this document...............................2 2. Conventions used in this document...............................2
3. Introduction....................................................2 3. Introduction....................................................2
4. Terminology.....................................................4 4. Terminology.....................................................4
4.1 Route, path....................................................4 4.1 Route, path....................................................4
4.2 Throughput, traffic volume.....................................4 4.2 Throughput, traffic volume.....................................4
5. Uses of Traffic Measurement.....................................5 5. Uses of Traffic Measurement.....................................5
5.1 Traffic characterization.......................................5 5.1 Traffic characterization.......................................5
5.2 Network monitoring.............................................5 5.2 Network monitoring.............................................5
5.3 Traffic control................................................6 5.3 Traffic control................................................6
6. Time Scales for Network Operations..............................6 6. Time Scales for Network Operations..............................6
7. Read-Out Periods................................................7 7. Read-Out Periods................................................7
8. Measurement Bases...............................................8 8. Measurement Bases...............................................8
8.1 Flow-based.....................................................8 8.1 Flow-based.....................................................9
8.2 Interface-based, link-based, node-based........................9 8.2 Interface-based, link-based, node-based........................9
8.3 Node-pair-based................................................9 8.3 Node-pair-based...............................................10
8.4 Path-based....................................................10 8.4 Path-based....................................................10
9. Measurement Entities...........................................10 9. Measurement Entities...........................................10
9.1 Entities related to traffic and performance...................10 9.1 Entities related to traffic and performance...................11
9.2 Entities related to establishment of connection or path.......13 9.2 Entities related to establishment of connection or path.......13
10. Measurement Types.............................................13 10. Measurement Types.............................................13
10.1 Measurement types related to traffic or performance..........13 10.1 Measurement types related to traffic or performance..........13
10.2 Measurement types related to resource usage..................14 10.2 Measurement types related to resource usage..................14
11. Traffic Matrix Statistics.....................................14 11. Traffic Matrix Statistics.....................................15
12. Performance Monitoring........................................15 12. Performance Monitoring........................................16
13. Security Considerations.......................................16 13. Packet Sampling...............................................16
14. References....................................................16 14. Statistical Estimation and Information Modeling...............17
15. Acknowledgments...............................................18 14.1 Engineering methods for statistical estimation of measures...17
16. Author's Addresses............................................18 14.2 TE Measure Information Modeling..............................18
Full Copyright Statement..........................................18 15. Conclusions and Recommendations...............................20
16. Security Considerations.......................................20
17. References....................................................20
18. Acknowledgments...............................................22
19. Author's Addresses............................................22
Full Copyright Statement..........................................23
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119. this document are to be interpreted as described in RFC-2119.
3. Introduction 3. Introduction
This document describes a framework for Internet traffic engineering This document describes a framework for Internet traffic engineering
measurement, with the objective of providing principles for the measurement, with the objective of providing principles for the
development of a set of measurement systems to support the traffic development of a set of measurement systems to support the traffic
engineering of IP-based networks [1]. A major goal is to provide engineering of IP-based networks [1]. A major goal is to provide
guidance for establishing protocol-independent and platform-neutral guidance for establishing protocol-independent and platform-neutral
traffic measurement standards to achieve multi-vendor inter- traffic measurement standards to achieve multi-vendor inter-
operability. It is critical to minimize the possibilities of operability. It is critical to minimize the possibilities of
inconsistencies arising from, e.g., differing statistical inconsistencies arising from, e.g., differing statistical
definitions, overlapping data collection, processing at different definitions, overlapping data collection, processing at different
protocol levels, and similar inconsistencies by different vendors or protocol levels, and similar inconsistencies by different vendors or
skipping to change at page 16, line 31 skipping to change at page 16, line 49
Internet utilities such as ping and traceroute have been useful to Internet utilities such as ping and traceroute have been useful to
help diagnose network problems and performance debugging. Utilities help diagnose network problems and performance debugging. Utilities
with similar functions would be essential for path-oriented with similar functions would be essential for path-oriented
operations like in MPLS. This would include the capability to list, operations like in MPLS. This would include the capability to list,
at any time, (1) for a given path, all the nodes traversed by it, at any time, (1) for a given path, all the nodes traversed by it,
and (2) for a given node, all the paths originating from it, and (2) for a given node, all the paths originating from it,
transiting through it, and/or terminating on it. A proposal for transiting through it, and/or terminating on it. A proposal for
route tracing is described in [26]. route tracing is described in [26].
13. Security Considerations 13. Packet Sampling
A wide spectrum of operational applications can be built on traffic
measurement. However, different applications usually require
traffic measurements at different levels of temporal and spatial
granularity. To achieve an effective tradeoff between
implementation complexity and the range of operational tasks to be
enabled, a passive measurement framework based on packet sampling is
proposed in [27].
The use of packet sampling has two motivations. First, the enormous
volumes of traffic require that some form of data reduction to be
used. Second, simple data reduction by aggregation at the
measurement point will not provide sufficiently detailed views for
all network management applications or exploratory studies. For
this reason, packet sampling is proposed as a means to reduce data
volume while still retaining representative detail.
The primary aim of the proposal [27] is to define a minimal set of
primitive packet selection operations out of which all sampling
operations that are necessary to support measurement-based
applications can be composed. Operations currently under
consideration include filtering and statistical sampling, and also
hash-based packet selection, a method that can be used to support
the determination of spatial traffic flows across a domain.
Whichever method is used, the interpretation of the stream of
measurements arising from sampled packets must be both transparent
and standard. Other goals are to specify a means to format and
export measurements, and a means to manage the configuration of the
sampling and export operations.
The proposal positions these function to provide a basic packet
sampled measurement service to higher level "consumers." A typical
consumer is a network management application that sits behind a
remote measurement collector. Such measurements can support
applications for a number of tasks: troubleshooting, demand
characterization, scenario evaluation and what-ifs. Another type of
consumer is a higher level on-router measurement application.
One potential class of examples is composite measurements (e.g.,
interpacket delay statistics) formed from a number of individual
packet measurements. Another class is network security
applications, e.g., IP traceback [28]. For some applications, the
ability to have low latency between packet measurement and reporting
will be particularly useful.
14. Statistical Estimation and Information Modeling
This section deals with engineering methods in statistical
estimation, as well as the need for an information model and
associated repository schema for the measurements.
14.1 Engineering methods for statistical estimation of measures
The use of the well-established methods of optimal estimation [29,
30, 31, 32] to obtain estimates of the measures for TE is
recommended. This draws upon several facts:
. Internet traffic is inherently band-limited, but non-stationary;
. Internet traffic may be heavy-tailed and possess strong short-term
correlations;
. A stationary, band-limited process can be approximated arbitrarily
closely by optimal estimation methods based on a finite number of
past samples.
Standard procedures for de-trending the raw data to provide "trend +
stationary" decompositions should be adopted. An example is the use
of Autoregressive Integrated Moving Average (ARIMA) models, where
first differences are applied to the raw (non-stationary) data,
yielding a stationary derived process. Then, the methods of optimal
estimation can be applied in a practical setting (e.g., finite
sample counts) to the derived stationary process to produce quality
estimates of the measures defined herein. As the original raw
process may be any of the measurements discussed in this document,
the above procedure may be applied without loss of generality to
measures of delay, loss, or complex measures of network state such
as path characteristics, etc.
In addition, these methods need to be applied across multiple time-
scales, so that TE applications can work with measures related to:
. long-term trends over days, weeks, and months;
. busy-hour characterizations; and
. statistics and correlation properties on the order of seconds
[33].
The above estimation procedures apply equally to traffic workload,
traffic performance, or other estimates of network state, such as
the state of routes.
14.2 TE Measure Information Modeling
An information model is valuable for organizing data generated
through the estimation process. An information model is needed for
TE measures because a complete model does not exist for these
measures. Measures must be associated with a large, and sometimes
complicated set of attributes (e.g., as simple as an IP address of a
measurement point, or as complex as the path of a round-trip
measurement).
Information models exist that richly describe network elements and
their configuration [34]. These models have been extended to
include policy mechanisms [35]. Specifications for flows have been
developed for network resource allocation purposes [36]. No
centralized information model exists that can completely describe
many of the TE measures defined herein. Therefore, necessary
integrating information models that make maximal reuse of pre-
existing work may need to be developed for TE measures.
As a brief example of the limitations of existing information
models, consider RFC 1363 [36] as a model for a traffic flow. It
can be described as collection of attributes defining traffic
offered load, performance to be delivered (a goal), and the
assurance level (risk) associated with the actual performance
obtained. The traffic offered load is specified via an envelope
described by a token bucket concept (token bucket rate, bucket size)
and a maximum transmission rate.
This model, while clearly intended for description of what a network
will tolerate of a flow, could also be used to describe a flow in a
TE measure sense, e.g., "a flow that lives within the token rate x
and size y with probability 0.999." Note that a probability
statement must be added to complete the characterization. This type
of specification is known as (sigma, rho) in the literature. Also,
note that adopting such an information model for flows lacks any
flexibility to specify time scale, or more detailed second-order
statistics.
Similar limitations exist with respect to delivered performance
specification in RFC1363, and the text of the RFC is quick to point
out, for example, that the "loss model is crude." For these
reasons, and others, an appropriate information model is needed for
TE measures that can support uniformity of data definition in
subsequent TE applications.
Several approaches and options for repository technology are now
broadly discussed. Relationships between TE measure information
models on other information models (e.g., COPS) that drive network
outcomes are of particular importance.
Linkages may need to be considered between policy mechanisms and TE
measures. This is useful because, while policy-driven networking is
well-developed between the policy repositories, policy control
points and policy enforcement, policy content is very likely the
output of TE applications. Since TE applications are dependent upon
TE measures, it is advantageous to provide traceability between the
measures and the engineering changes made as a consequence of them.
Measures (represented by their estimates) should be centrally stored
and collected. Two methods are: (1) extend MIBs with new
definitions for TE measure estimates, and (2) create data
depositories through more centralized facilities, such as LDAP
repositories. Both methods have merits as collection processes for
TE measures.
Using MIBs allows well-established SNMP protocol and related
applications to retrieve data from the network elements being
measured. This is inherently "vendor-neutral," allowing commonly
defined TE measurements to be stored for retrieval in a common MIB
definition, regardless of network element vendor, technology or
other differences. Measurements from individual network elements
(interfaces, routers, etc.) can be obtained "locally," if measures
from a single network element are sufficient for a given TE
application. However, if a network-wide view of the measurements is
desired, the drawback of a MIB-based approach is that the data must
be retrieved from each element over the network. As experience
attests, this approach sometimes generates significant SNMP traffic,
and during periods of high congestion (when measurements may be
quite important) SNMP may not reliably fetch the measurement data.
Finally, a MIB-based approach may be difficult to implement for
various two-point measurements, such as end-to-end, or round-trip
delay and delay variation. Such measurements are not related to a
single network element, and somewhat heuristic practices (e.g.,
storing end-to-end delay measurements in MIBs located on source
address elements, etc.) are required.
An LDAP repository approach centralizes the data storage. This has
the advantage that TE applications (such as offline and online TE,
or measurement-based admission control) can be performed, and policy
database content can be updated without invasive retrieval of data
from network-wide MIBs. Further, traceability can be established
between the TE measurements in an LDAP repository, and the
associated policy content derived from them.
It is possible that both the MIB-based and LDAP-based (or another
approach altogether) should be considered jointly.
15. Conclusions and Recommendations
This document is intended as a framework for traffic metrics needed
for successful TE. Principles of best practice in traffic
characterization and performance characterization are described.
For interoperable compatibility, basic areas of traffic measurement
recommended for standardization include:
. Need for uniform definitions across vendors and operators
. Distinction between traffic offered load versus achieved
throughput
. Use of node-pair-based traffic data to derive per-service-class
traffic matrix statistics
. Statistics of carried load versus performance
. Need for higher-order statistics for service assurance
. Need for packet sampled measurements that preserve representative
traffic detail at manageable sample volumes
16. Security Considerations
The principles and concepts related to Internet traffic measurement The principles and concepts related to Internet traffic measurement
as discussed in this document do not by themselves affect the as discussed in this document do not by themselves affect the
security of the Internet. However, it is assumed that any security of the Internet. However, it is assumed that any
measurement systems that are developed or deployed by a service measurement systems that are developed or deployed by a service
provider are responsible for providing sufficient data integrity and provider are responsible for providing sufficient data integrity and
confidentiality. It is also assumed that a service provider will confidentiality. It is also assumed that a service provider will
take proper precautions to ensure that access to its measurement take proper precautions to ensure that access to its measurement
systems and all associated data is secure. Methods to achieve these systems and all associated data is secure. Methods to achieve these
security considerations are not addressed in this document. security considerations are not addressed in this document.
14. References 17. References
1 D.O. Awduche, A. Chiu, A. Elwalid, I. Widjaja, and X. Xiao, 1 D.O. Awduche, A. Chiu, A. Elwalid, I. Widjaja, and X. Xiao,
"Overview and Principles of Internet Traffic Engineering," "Overview and Principles of Internet Traffic Engineering,"
Internet-Draft, Work in Progress, October 2001. Internet-Draft, Work in Progress, October 2001.
2 V. Paxson, G. Almes, J. Mahdavi, and M. Mathis, "Framework for IP 2 V. Paxson, G. Almes, J. Mahdavi, and M. Mathis, "Framework for IP
Performance Metrics," RFC 2330, May 1998. Performance Metrics," RFC 2330, May 1998.
3 J. Mahdavi and V. Paxson, "IPPM Metrics for Measuring 3 J. Mahdavi and V. Paxson, "IPPM Metrics for Measuring
Connectivity," RFC 2678, September 1999. Connectivity," RFC 2678, September 1999.
4 G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Delay Metric 4 G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Delay Metric
for IPPM," RFC 2679, September 1999. for IPPM," RFC 2679, September 1999.
5 G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Packet Loss 5 G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Packet Loss
skipping to change at page 17, line 4 skipping to change at page 21, line 15
"Overview and Principles of Internet Traffic Engineering," "Overview and Principles of Internet Traffic Engineering,"
Internet-Draft, Work in Progress, October 2001. Internet-Draft, Work in Progress, October 2001.
2 V. Paxson, G. Almes, J. Mahdavi, and M. Mathis, "Framework for IP 2 V. Paxson, G. Almes, J. Mahdavi, and M. Mathis, "Framework for IP
Performance Metrics," RFC 2330, May 1998. Performance Metrics," RFC 2330, May 1998.
3 J. Mahdavi and V. Paxson, "IPPM Metrics for Measuring 3 J. Mahdavi and V. Paxson, "IPPM Metrics for Measuring
Connectivity," RFC 2678, September 1999. Connectivity," RFC 2678, September 1999.
4 G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Delay Metric 4 G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Delay Metric
for IPPM," RFC 2679, September 1999. for IPPM," RFC 2679, September 1999.
5 G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Packet Loss 5 G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Packet Loss
Metric for IPPM," RFC 2680, September 1999. Metric for IPPM," RFC 2680, September 1999.
6 G. Almes, S. Kalidindi, and M. Zekauskas, "A Round-trip Delay 6 G. Almes, S. Kalidindi, and M. Zekauskas, "A Round-trip Delay
Metric for IPPM," RFC 2681, September 1999. Metric for IPPM," RFC 2681, September 1999.
7 M. Mathis and M. Allman, "A Framework for Defining Empirical Bulk 7 M. Mathis and M. Allman, "A Framework for Defining Empirical Bulk
Transfer Capacity Metrics," RFC 3148, July 2001. Transfer Capacity Metrics," RFC 3148, July 2001.
8 C. Demichelis and P. Chimento, "IP Packet Delay Variation Metric 8 C. Demichelis and P. Chimento, "IP Packet Delay Variation Metric
for IPPM," Internet-Draft, Work in Progress, February 2001. for IPPM," Internet-Draft, Work in Progress, February 2001.
9 V. Raisanen and G. Grotefeld, "Network performance measurement 9 V. Raisanen, G. Grotefeld, and A. Morton, "Network performance
for periodic streams," Internet-Draft, Work in Progress, January measurement for periodic streams," Internet-Draft, Work in
2001. Progress, February 2002.
10 ITU-T Recommendation I.380/Y.1540, "Internet Protocol Data 10 ITU-T Recommendation I.380/Y.1540, "Internet Protocol Data
Communication Service -- IP Packet Transfer and Availability Communication Service -- IP Packet Transfer and Availability
Performance Parameters," February 1999. Performance Parameters," February 1999.
11 ITU-T Draft Recommendation Y.1541, "Network Performance 11 ITU-T Draft Recommendation Y.1541, "Network Performance
Objectives for IP-Based Services," October 2001. Objectives for IP-Based Services," October 2001.
12 E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol Label 12 E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol Label
Switching Architecture," RFC 3031, January 2001. Switching Architecture," RFC 3031, January 2001.
13 S. Bradner (Editor), "Benchmarking Terminology for Network 13 S. Bradner (Editor), "Benchmarking Terminology for Network
Interconnection Devices," RFC 1242, July 1991. Interconnection Devices," RFC 1242, July 1991.
14 G. Ash, "Traffic Engineering & QoS Methods for IP-, ATM-, & TDM- 14 G. Ash, "Traffic Engineering & QoS Methods for IP-, ATM-, & TDM-
skipping to change at page 18, line 4 skipping to change at page 22, line 16
"NetScope: Traffic Engineering for IP Networks," IEEE Network, "NetScope: Traffic Engineering for IP Networks," IEEE Network,
March/April 2000. March/April 2000.
22 N. Harrison, P. Willis, S. Davari, E. Cuevas, B. Mack-Crane, E. 22 N. Harrison, P. Willis, S. Davari, E. Cuevas, B. Mack-Crane, E.
Franze, H. Ohta, T. So, S. Goldfless, and F. Chen, "Requirements Franze, H. Ohta, T. So, S. Goldfless, and F. Chen, "Requirements
for OAM in MPLS Networks," Internet-Draft, Work in Progress, May for OAM in MPLS Networks," Internet-Draft, Work in Progress, May
2001. 2001.
23 ITU-T Draft Recommendation Y.1710, "Requirements for OAM 23 ITU-T Draft Recommendation Y.1710, "Requirements for OAM
Functionality for MPLS Networks," May 2001. Functionality for MPLS Networks," May 2001.
24 ITU-T Draft Recommendation Y.1711, "OAM Mechanisms for MPLS 24 ITU-T Draft Recommendation Y.1711, "OAM Mechanisms for MPLS
Networks," May 2001. Networks," May 2001.
25 R.G. Cole, R. Dietz, C. Kalbfleisch, and D. Romascanu, "A 25 R.G. Cole, R. Dietz, C. Kalbfleisch, and D. Romascanu, "A
Framework for Synthetic Sources for Performance Monitoring," Framework for Synthetic Sources for Performance Monitoring,"
Internet-Draft, Work in Progress, May 2001. Internet-Draft, Work in Progress, May 2001.
26 R. Bonica, K. Kompella, and D. Meyer, "Tracing Requirements for 26 R. Bonica, K. Kompella, and D. Meyer, "Tracing Requirements for
Generic Tunnels," Internet-Draft, Work in Progress, February Generic Tunnels," Internet-Draft, Work in Progress, February
2001. 2001.
27 R. Bush, N.G. Duffield, A. Greenberg, M. Grossglauser, J.
Rexford, "A Framework for Passive Packet Measurement," Internet-
Draft, Work in Progress, November 2001.
28 C. Partridge, C. Jones, D. Waitzman, and A. Snoeren, "New
Protocols to Support Internet Traceback," Internet-Draft, Work in
Progress, November 2001.
29 S. Haykin, Ed., "Kalman Filtering and Neural Networks," Wiley
Interscience, 2001.
30 A. Papoulis, "Probability, Random Variables and Stochastic
Processes," 3rd Ed., McGraw-Hill, 1991.
31 A. Gelb, Ed., "Applied Optimal Estimation," MIT Press, 1974.
32 I. R. Petersen, V. A. Ugrinovskii, A. V. Savkin, "Robust Control
Design Using H<\infinity> Methods," Springer, 2000.
33 V. Bolotin, J. Coombs-Reyes, D. Heyman, Y. Levy, and D. Liu, "IP
Traffic Characterization for Planning and Control," Proc. ITC16,
Edinburgh, Scotland, June 1999.
34 Distributed Management Task Force (DMTF) Common Information Model
(CIM), www.dmtf.org
35 B. Moore, E. Ellesson, and J. Strassner, "Policy Core Information
Model -- Version 1 Specification," RFC 3060, February 2001.
36 C. Partridge, "A Proposed Flow Specification," RFC 1363,
September 1992.
15. Acknowledgments 18. Acknowledgments
The support of Gerald Ash on this work and his comments are much The support of Gerald Ash on this work and his comments are much
appreciated. Also, thanks to the inputs from Robert Cole, Enrique appreciated. Also, thanks to the inputs from Robert Cole, Enrique
Cuevas, Alfred Morton, Moshe Segal, and the Tequila project. Cuevas, Alfred Morton, Moshe Segal, and the Tequila project. Nick
Duffield contributed section 13 on packet sampling.
16. Author's Addresses 19. Author's Addresses
Wai Sum Lai Wai Sum Lai
AT&T Labs AT&T Labs
Room D5-3D18 Room D5-3D18
200 Laurel Avenue 200 Laurel Avenue
Middletown, NJ 07748, USA Middletown, NJ 07748, USA
Phone: +1 732-420-3712 Phone: +1 732-420-3712
Email: wlai@att.com Email: wlai@att.com
Blaine Christian Blaine Christian
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/