| < draft-ietf-ippm-framework-compagg-08.txt | draft-ietf-ippm-framework-compagg-09.txt > | |||
|---|---|---|---|---|
| Network Working Group A. Morton, Ed. | Network Working Group A. Morton, Ed. | |||
| Internet-Draft AT&T Labs | Internet-Draft AT&T Labs | |||
| Intended status: Informational S. Van den Berghe, Ed. | Intended status: Informational S. Van den Berghe, Ed. | |||
| Expires: December 23, 2009 Ghent University - IBBT | Expires: June 23, 2010 Alcatel-Lucent | |||
| June 21, 2009 | December 20, 2009 | |||
| Framework for Metric Composition | Framework for Metric Composition | |||
| draft-ietf-ippm-framework-compagg-08 | draft-ietf-ippm-framework-compagg-09 | |||
| Abstract | ||||
| This memo describes a detailed framework for composing and | ||||
| aggregating metrics (both in time and in space) originally defined by | ||||
| the IP Performance Metrics (IPPM) RFC 2330 and developed by the IETF. | ||||
| This new framework memo describes the generic composition and | ||||
| aggregation mechanisms. The memo provides a basis for additional | ||||
| documents that implement the framework to define detailed | ||||
| compositions and aggregations of metrics which are useful in | ||||
| practice. | ||||
| Requirements Language | ||||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ||||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | ||||
| document are to be interpreted as described in RFC 2119 [RFC2119]. | ||||
| Status of this Memo | Status of this Memo | |||
| This Internet-Draft is submitted to IETF in full conformance with the | This Internet-Draft is submitted to IETF in full conformance with the | |||
| provisions of BCP 78 and BCP 79. This document may contain material | provisions of BCP 78 and BCP 79. | |||
| from IETF Documents or IETF Contributions published or made publicly | ||||
| available before November 10, 2008. The person(s) controlling the | ||||
| copyright in some of this material may not have granted the IETF | ||||
| Trust the right to allow modifications of such material outside the | ||||
| IETF Standards Process. Without obtaining an adequate license from | ||||
| the person(s) controlling the copyright in such materials, this | ||||
| document may not be modified outside the IETF Standards Process, and | ||||
| derivative works of it may not be created outside the IETF Standards | ||||
| Process, except to format it for publication as an RFC or to | ||||
| translate it into languages other than English. | ||||
| 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 | |||
| other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
| Drafts. | Drafts. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| This Internet-Draft will expire on December 23, 2009. | This Internet-Draft will expire on June 23, 2010. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2009 IETF Trust and the persons identified as the | Copyright (c) 2009 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents in effect on the date of | Provisions Relating to IETF Documents | |||
| publication of this document (http://trustee.ietf.org/license-info). | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
| and restrictions with respect to this document. | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | ||||
| Abstract | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | ||||
| This memo describes a detailed framework for composing and | described in the BSD License. | |||
| aggregating metrics (both in time and in space) originally defined by | ||||
| the IP Performance Metrics (IPPM) RFC 2330 and developed by the IETF. | ||||
| This new framework memo describes the generic composition and | ||||
| aggregation mechanisms. The memo provides a basis for additional | ||||
| documents that implement the framework to define detailed | ||||
| compositions and aggregations of metrics which are useful in | ||||
| practice. | ||||
| Requirements Language | ||||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | This document may contain material from IETF Documents or IETF | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | Contributions published or made publicly available before November | |||
| document are to be interpreted as described in RFC 2119 [RFC2119]. | 10, 2008. The person(s) controlling the copyright in some of this | |||
| material may not have granted the IETF Trust the right to allow | ||||
| modifications of such material outside the IETF Standards Process. | ||||
| Without obtaining an adequate license from the person(s) controlling | ||||
| the copyright in such materials, this document may not be modified | ||||
| outside the IETF Standards Process, and derivative works of it may | ||||
| not be created outside the IETF Standards Process, except to format | ||||
| it for publication as an RFC or to translate it into languages other | ||||
| than English. | ||||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 1.1.1. Reducing Measurement Overhead . . . . . . . . . . . . 4 | 1.1.1. Reducing Measurement Overhead . . . . . . . . . . . . 4 | |||
| 1.1.2. Measurement Re-use . . . . . . . . . . . . . . . . . . 5 | 1.1.2. Measurement Re-use . . . . . . . . . . . . . . . . . . 5 | |||
| 1.1.3. Data Reduction and Consolidation . . . . . . . . . . . 5 | 1.1.3. Data Reduction and Consolidation . . . . . . . . . . . 5 | |||
| 1.1.4. Implications on Measurement Design and Reporting . . . 6 | 1.1.4. Implications on Measurement Design and Reporting . . . 6 | |||
| 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 6 | 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| skipping to change at page 3, line 47 ¶ | skipping to change at page 3, line 47 ¶ | |||
| 6.1.2. Ground Truth for Spatial Aggregation . . . . . . . . . 15 | 6.1.2. Ground Truth for Spatial Aggregation . . . . . . . . . 15 | |||
| 6.2. Deviation from the Ground Truth . . . . . . . . . . . . . 15 | 6.2. Deviation from the Ground Truth . . . . . . . . . . . . . 15 | |||
| 6.3. Incomplete Information . . . . . . . . . . . . . . . . . . 15 | 6.3. Incomplete Information . . . . . . . . . . . . . . . . . . 15 | |||
| 6.4. Time Varying Metrics . . . . . . . . . . . . . . . . . . . 15 | 6.4. Time Varying Metrics . . . . . . . . . . . . . . . . . . . 15 | |||
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | |||
| 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 | |||
| 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 | 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
| 1. Introduction | 1. Introduction | |||
| The IPPM framework [RFC2330] describes two forms of metric | The IPPM framework [RFC2330] describes two forms of metric | |||
| composition, spatial and temporal. The text also suggests that the | composition, spatial and temporal. The text also suggests that the | |||
| concepts of the analytical framework (or A-frame) would help to | concepts of the analytical framework (or A-frame) would help to | |||
| develop useful relationships to derive the composed metrics from real | develop useful relationships to derive the composed metrics from real | |||
| metrics. The effectiveness of composed metrics is dependent on their | metrics. The effectiveness of composed metrics is dependent on their | |||
| usefulness in analysis and applicability to practical measurement | usefulness in analysis and applicability to practical measurement | |||
| circumstances. | circumstances. | |||
| skipping to change at page 6, line 26 ¶ | skipping to change at page 6, line 26 ¶ | |||
| The purpose of this memo is provide a common framework for the | The purpose of this memo is provide a common framework for the | |||
| various classes of metrics that are composed from primary metrics. | various classes of metrics that are composed from primary metrics. | |||
| The scope is limited to the definitions of metrics that are composed | The scope is limited to the definitions of metrics that are composed | |||
| from primary metrics using a deterministic function. Key information | from primary metrics using a deterministic function. Key information | |||
| about each composed metric, such as the assumptions under which the | about each composed metric, such as the assumptions under which the | |||
| relationship holds and possible sources of error/circumstances where | relationship holds and possible sources of error/circumstances where | |||
| the composition may fail, are included. | the composition may fail, are included. | |||
| At this time, the scope of effort is limited to composed metrics for | At this time, the scope of effort is limited to composed metrics for | |||
| packet loss, delay, and delay variation. Composition of packet | packet loss, delay, and delay variation, as defined in [RFC2679], | |||
| reordering metrics is considered a research topic at the time this | [RFC2680], [RFC2681], [RFC3393], [RFC5481], and the comparable | |||
| memo was prepared, and beyond its scope. | metrics in [Y.1540] . Composition of packet reordering metrics | |||
| [RFC4737] and duplication metrics [RFC5560] are considered research | ||||
| topics at the time this memo was prepared, and beyond its scope. | ||||
| This memo will retain the terminology of the IPPM Framework | This memo will retain the terminology of the IPPM Framework | |||
| [RFC2330]as much as possible, but will extend the terminology when | [RFC2330]as much as possible, but will extend the terminology when | |||
| necessary. It is assumed that the reader is familiar with the | necessary. It is assumed that the reader is familiar with the | |||
| concepts introduced in [RFC2330], as they will not be repeated here. | concepts introduced in [RFC2330], as they will not be repeated here. | |||
| 3. Terminology | 3. Terminology | |||
| This section defines the terminology applicable to the processes of | This section defines the terminology applicable to the processes of | |||
| Metric Composition and Aggregation. | Metric Composition and Aggregation. | |||
| skipping to change at page 8, line 19 ¶ | skipping to change at page 8, line 19 ¶ | |||
| 3.10. Sub-path | 3.10. Sub-path | |||
| A Sub-path is a portion of the complete path where at least the Sub- | A Sub-path is a portion of the complete path where at least the Sub- | |||
| path Source and Destination hosts are constituents of the complete | path Source and Destination hosts are constituents of the complete | |||
| path. We say that such a sub-path is "involved" in the complete | path. We say that such a sub-path is "involved" in the complete | |||
| path. | path. | |||
| Since sub-paths terminate on hosts, it is important to describe how | Since sub-paths terminate on hosts, it is important to describe how | |||
| sub-paths are considered to be joined. In practice, the Source and | sub-paths are considered to be joined. In practice, the Source and | |||
| Desitination hosts may perform the funtion of measurement points. | Destination hosts may perform the function of measurement points. | |||
| If the Destination and Source hosts of two adjoining paths are co- | If the Destination and Source hosts of two adjoining paths are co- | |||
| located and the link between them would contribute negligible | located and the link between them would contribute negligible | |||
| performance, then these hosts can be considered equivalent (even if | performance, then these hosts can be considered equivalent (even if | |||
| there is no physical link between them, this is a practical | there is no physical link between them, this is a practical | |||
| consession). | concession). | |||
| If the Destination and Source hosts of two adjoining paths have a | If the Destination and Source hosts of two adjoining paths have a | |||
| link between them that contributes to the complete path performance, | link between them that contributes to the complete path performance, | |||
| then the link and hosts constitutes another sub-path that is involved | then the link and hosts constitutes another sub-path that is involved | |||
| in the complete path, and should be characterized and included in the | in the complete path, and should be characterized and included in the | |||
| composed metric. | composed metric. | |||
| 3.11. Sub-path Metrics | 3.11. Sub-path Metrics | |||
| A sub-path path metric is an element of the process to derive a | A sub-path path metric is an element of the process to derive a | |||
| skipping to change at page 9, line 5 ¶ | skipping to change at page 9, line 5 ¶ | |||
| space, and the third involves concatenation in space. | space, and the third involves concatenation in space. | |||
| 4.1. Temporal Aggregation Description | 4.1. Temporal Aggregation Description | |||
| Aggregation in time is defined as the composition of metrics with the | Aggregation in time is defined as the composition of metrics with the | |||
| same type and scope obtained in different time instants or time | same type and scope obtained in different time instants or time | |||
| windows. For example, starting from a time series of the | windows. For example, starting from a time series of the | |||
| measurements of maximum and minimum One-Way Delay on a certain | measurements of maximum and minimum One-Way Delay on a certain | |||
| network path obtained over 5-minute intervals, we obtain a time | network path obtained over 5-minute intervals, we obtain a time | |||
| series measurement with a coarser resolution (60 minutes) by taking | series measurement with a coarser resolution (60 minutes) by taking | |||
| the max of 12 consecutive 5-minute maxima and the min of 12 | the maximum of 12 consecutive 5-minute maxima and the minimum of 12 | |||
| consecutive 5-minute minima. | consecutive 5-minute minima. | |||
| The main reason for doing time aggregation is to reduce the amount of | The main reason for doing time aggregation is to reduce the amount of | |||
| data that has to be stored, and make the visualization/spotting of | data that has to be stored, and make the visualization/spotting of | |||
| regular cycles and/or growing or decreasing trends easier. Another | regular cycles and/or growing or decreasing trends easier. Another | |||
| useful application is to detect anomalies or abnormal changes in the | useful application is to detect anomalies or abnormal changes in the | |||
| network characteristics. | network characteristics. | |||
| In RFC 2330, the term "temporal composition" is introduced and | In RFC 2330, the term "temporal composition" is introduced and | |||
| differs from temporal aggregation in that it refers to methodologies | differs from temporal aggregation in that it refers to methodologies | |||
| to predict future metrics on the basis of past observations (of the | to predict future metrics on the basis of past observations (of the | |||
| same metrics), exploiting the time correlation that certain metrics | same metrics), exploiting the time correlation that certain metrics | |||
| can exhibit. We do not consider this type of composition here. | can exhibit. We do not consider this type of composition here. | |||
| >>>>>>>>Comment: Why no forecasting? This was apparently a limit on | ||||
| the Geant2 project, but may not apply here. | ||||
| 4.2. Spatial Aggregation Description | 4.2. Spatial Aggregation Description | |||
| Aggregation in space is defined as the combination of metrics of the | Aggregation in space is defined as the combination of metrics of the | |||
| same type and different scope, in order to estimate the overall | same type and different scope, in order to estimate the overall | |||
| performance of a larger network. This combination may involve | performance of a larger network. This combination may involve | |||
| weighing the contributions of the input metrics. | weighing the contributions of the input metrics. | |||
| Suppose we want to compose the average One-Way-Delay (OWD) | Suppose we want to compose the average One-Way-Delay (OWD) | |||
| experienced by flows traversing all the Origin-Destination (OD) pairs | experienced by flows traversing all the Origin-Destination (OD) pairs | |||
| of a network (where the inputs are already metric "statistics"). | of a network (where the inputs are already metric "statistics"). | |||
| skipping to change at page 13, line 39 ¶ | skipping to change at page 13, line 39 ¶ | |||
| ++ ++ ++ ++ | ++ ++ ++ ++ | |||
| Figure 1: Comparison with other IPPM metrics | Figure 1: Comparison with other IPPM metrics | |||
| The Composed Metric is an estimate of an actual metric collected over | The Composed Metric is an estimate of an actual metric collected over | |||
| the complete Source to Destination path. We say that the Complete | the complete Source to Destination path. We say that the Complete | |||
| Path Metric represents the "Ground Truth" for the Composed Metric. | Path Metric represents the "Ground Truth" for the Composed Metric. | |||
| In other words, Composed Metrics seek to minimize error w.r.t. the | In other words, Composed Metrics seek to minimize error w.r.t. the | |||
| Complete Path Metric. | Complete Path Metric. | |||
| Further, we observe that a Spatial Metric | Further, we observe that a Spatial Metric [RFC5644] collected for | |||
| [I-D.ietf-ippm-multimetrics] collected for packets traveling over the | packets traveling over the same set of sub-paths provide a basis for | |||
| same set of sub-paths provide a basis for the Ground Truth of the | the Ground Truth of the individual Sub-Path metrics. We note that | |||
| individual Sub-Path metrics. We note that mathematical operations | mathematical operations may be necessary to isolate the performance | |||
| may be necessary to isolate the performance of each sub-path. | of each sub-path. | |||
| Next, we consider multiparty metrics as defined in [I-D.ietf-ippm- | Next, we consider multiparty metrics as defined in [RFC5644], and | |||
| multimetrics], and their spatial composition. Measurements to each | their spatial composition. Measurements to each of the Receivers | |||
| of the Receivers produce an element of the one-to-group metric. | produce an element of the one-to-group metric. These elements can be | |||
| These elements can be composed from sub-path metrics and the composed | composed from sub-path metrics and the composed metrics can be | |||
| metrics can be combined to create a composed one-to-group metric. | combined to create a composed one-to-group metric. Figure 2 | |||
| Figure 2 illustrates this process. | illustrates this process. | |||
| Sub-Path Metrics | Sub-Path Metrics | |||
| ++ M1 ++ ++ M2 ++ ++ M3 ++ | ++ M1 ++ ++ M2 ++ ++ M3 ++ | |||
| Src ||.......|| ||.......|| ||.......||Rcvr1 | Src ||.......|| ||.......|| ||.......||Rcvr1 | |||
| ++ ++ ++`. ++ ++ ++ | ++ ++ ++`. ++ ++ ++ | |||
| `-. | `-. | |||
| M4`.++ ++ M5 ++ | M4`.++ ++ M5 ++ | |||
| || ||.......||Rcvr2 | || ||.......||Rcvr2 | |||
| ++ ++`. ++ | ++ ++`. ++ | |||
| `-. | `-. | |||
| skipping to change at page 16, line 43 ¶ | skipping to change at page 16, line 43 ¶ | |||
| Andreas Haneman, Igor Velimirovic, Andreas Solberg, Athanassios | Andreas Haneman, Igor Velimirovic, Andreas Solberg, Athanassios | |||
| Liakopulos, David Schitz, Nicolas Simar and the Geant2 Project. We | Liakopulos, David Schitz, Nicolas Simar and the Geant2 Project. We | |||
| also acknowledge comments and suggestions from Phil Chimento, Emile | also acknowledge comments and suggestions from Phil Chimento, Emile | |||
| Stephan, Lei Liang, Stephen Wolff, Reza Fardid, Loki Jorgenson, and | Stephan, Lei Liang, Stephen Wolff, Reza Fardid, Loki Jorgenson, and | |||
| Alan Clark. | Alan Clark. | |||
| 10. References | 10. References | |||
| 10.1. Normative References | 10.1. Normative References | |||
| [I-D.ietf-ippm-multimetrics] | ||||
| Stephan, E., Liang, L., and A. Morton, "IP Performance | ||||
| Metrics (IPPM) for spatial and multicast", | ||||
| draft-ietf-ippm-multimetrics-11 (work in progress), | ||||
| April 2009. | ||||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
| [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, | [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, | |||
| "Framework for IP Performance Metrics", RFC 2330, | "Framework for IP Performance Metrics", RFC 2330, | |||
| May 1998. | May 1998. | |||
| [RFC3979] Bradner, S., "Intellectual Property Rights in IETF | [RFC3979] Bradner, S., "Intellectual Property Rights in IETF | |||
| Technology", BCP 79, RFC 3979, March 2005. | Technology", BCP 79, RFC 3979, March 2005. | |||
| [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. | [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. | |||
| Zekauskas, "A One-way Active Measurement Protocol | Zekauskas, "A One-way Active Measurement Protocol | |||
| (OWAMP)", RFC 4656, September 2006. | (OWAMP)", RFC 4656, September 2006. | |||
| [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. | [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. | |||
| Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", | Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", | |||
| RFC 5357, October 2008. | RFC 5357, October 2008. | |||
| 10.2. Informative References | 10.2. Informative References | |||
| [G.107] ITU-T Recommendation G.107, ""The E-model, a computational | [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way | |||
| model for use in transmission planning"", March 2005. | Delay Metric for IPPM", RFC 2679, September 1999. | |||
| [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way | ||||
| Packet Loss Metric for IPPM", RFC 2680, September 1999. | ||||
| [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip | ||||
| Delay Metric for IPPM", RFC 2681, September 1999. | ||||
| [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation | ||||
| Metric for IP Performance Metrics (IPPM)", RFC 3393, | ||||
| November 2002. | ||||
| [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, | ||||
| S., and J. Perser, "Packet Reordering Metrics", RFC 4737, | ||||
| November 2006. | ||||
| [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation | ||||
| Applicability Statement", RFC 5481, March 2009. | ||||
| [RFC5560] Uijterwaal, H., "A One-Way Packet Duplication Metric", | ||||
| RFC 5560, May 2009. | ||||
| [RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance | ||||
| Metrics (IPPM): Spatial and Multicast", RFC 5644, | ||||
| October 2009. | ||||
| [Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data | ||||
| communication service - IP packet transfer and | ||||
| availability performance parameters", December 2007. | ||||
| Authors' Addresses | Authors' Addresses | |||
| Al Morton (editor) | Al Morton (editor) | |||
| AT&T Labs | AT&T Labs | |||
| 200 Laurel Avenue South | 200 Laurel Avenue South | |||
| Middletown,, NJ 07748 | Middletown,, NJ 07748 | |||
| USA | USA | |||
| Phone: +1 732 420 1571 | Phone: +1 732 420 1571 | |||
| Fax: +1 732 368 1192 | Fax: +1 732 368 1192 | |||
| Email: acmorton@att.com | Email: acmorton@att.com | |||
| URI: http://home.comcast.net/~acmacm/ | URI: http://home.comcast.net/~acmacm/ | |||
| Steven Van den Berghe (editor) | Steven Van den Berghe (editor) | |||
| Ghent University - IBBT | Alcatel-Lucent | |||
| G. Crommenlaan 8 bus 201 | Copernicuslaan 50 | |||
| Gent 9050 | Antwerp 2018 | |||
| Belgium | Belgium | |||
| Phone: +32 9 331 49 73 | Phone: +32 3 240 3983 | |||
| Email: steven.vandenberghe@intec.ugent.be | Email: steven.van_den_berghe@alcatel-lucent.com | |||
| URI: http://www.ibcn.intec.ugent.be | URI: | |||
| End of changes. 18 change blocks. | ||||
| 67 lines changed or deleted | 94 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||