| < draft-ietf-ippm-rfc8321bis-00.txt | draft-ietf-ippm-rfc8321bis-01.txt > | |||
|---|---|---|---|---|
| Network Working Group G. Fioccola, Ed. | Network Working Group G. Fioccola, Ed. | |||
| Internet-Draft Huawei Technologies | Internet-Draft Huawei Technologies | |||
| Obsoletes: 8321 (if approved) M. Cociglio | Obsoletes: 8321 (if approved) M. Cociglio | |||
| Intended status: Standards Track Telecom Italia | Intended status: Standards Track Telecom Italia | |||
| Expires: October 28, 2022 G. Mirsky | Expires: October 30, 2022 G. Mirsky | |||
| Ericsson | Ericsson | |||
| T. Mizrahi | T. Mizrahi | |||
| T. Zhou | T. Zhou | |||
| Huawei Technologies | Huawei Technologies | |||
| April 26, 2022 | April 28, 2022 | |||
| Alternate-Marking Method | Alternate-Marking Method | |||
| draft-ietf-ippm-rfc8321bis-00 | draft-ietf-ippm-rfc8321bis-01 | |||
| Abstract | Abstract | |||
| This document describes the Alternate-Marking technique to perform | This document describes the Alternate-Marking technique to perform | |||
| packet loss, delay, and jitter measurements on live traffic. This | packet loss, delay, and jitter measurements on live traffic. This | |||
| technology can be applied in various situations and for different | technology can be applied in various situations and for different | |||
| protocols. It could be considered Passive or Hybrid depending on the | protocols. It could be considered Passive or Hybrid depending on the | |||
| application. This document obsoletes [RFC8321]. | application. This document obsoletes [RFC8321]. | |||
| Status of This Memo | Status of This Memo | |||
| skipping to change at page 1, line 40 ¶ | skipping to change at page 1, line 40 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| 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." | |||
| This Internet-Draft will expire on October 28, 2022. | This Internet-Draft will expire on October 30, 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 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 | Provisions Relating to IETF Documents | |||
| (https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | described in the Simplified BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | 1.1. Summary of Changes from RFC 8321 . . . . . . . . . . . . 3 | |||
| 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 | ||||
| 2. Overview of the Method . . . . . . . . . . . . . . . . . . . 4 | 2. Overview of the Method . . . . . . . . . . . . . . . . . . . 4 | |||
| 3. Detailed Description of the Method . . . . . . . . . . . . . 5 | 3. Detailed Description of the Method . . . . . . . . . . . . . 5 | |||
| 3.1. Packet Loss Measurement . . . . . . . . . . . . . . . . . 5 | 3.1. Packet Loss Measurement . . . . . . . . . . . . . . . . . 6 | |||
| 3.2. One-Way Delay Measurement . . . . . . . . . . . . . . . . 9 | 3.2. One-Way Delay Measurement . . . . . . . . . . . . . . . . 9 | |||
| 3.2.1. Single-Marking Methodology . . . . . . . . . . . . . 9 | 3.2.1. Single-Marking Methodology . . . . . . . . . . . . . 9 | |||
| 3.2.2. Double-Marking Methodology . . . . . . . . . . . . . 10 | 3.2.2. Double-Marking Methodology . . . . . . . . . . . . . 10 | |||
| 3.3. Delay Variation Measurement . . . . . . . . . . . . . . . 11 | 3.3. Delay Variation Measurement . . . . . . . . . . . . . . . 11 | |||
| 4. Alternate Marking Functions . . . . . . . . . . . . . . . . . 12 | 4. Alternate Marking Functions . . . . . . . . . . . . . . . . . 12 | |||
| 4.1. Marking the Packets . . . . . . . . . . . . . . . . . . . 12 | 4.1. Marking the Packets . . . . . . . . . . . . . . . . . . . 12 | |||
| 4.2. Counting and Timestamping Packets . . . . . . . . . . . . 12 | 4.2. Counting and Timestamping Packets . . . . . . . . . . . . 13 | |||
| 4.3. Data Collection and Correlation . . . . . . . . . . . . . 13 | 4.3. Data Collection and Correlation . . . . . . . . . . . . . 13 | |||
| 5. Synchronization and Timing . . . . . . . . . . . . . . . . . 14 | 5. Synchronization and Timing . . . . . . . . . . . . . . . . . 14 | |||
| 6. Packet Fragmentation . . . . . . . . . . . . . . . . . . . . 16 | 6. Packet Fragmentation . . . . . . . . . . . . . . . . . . . . 16 | |||
| 7. Results of the Alternate Marking Experiment . . . . . . . . . 16 | 7. Results of the Alternate Marking Experiment . . . . . . . . . 17 | |||
| 7.1. Controlled Domain requirement . . . . . . . . . . . . . . 18 | 7.1. Controlled Domain requirement . . . . . . . . . . . . . . 18 | |||
| 8. Compliance with Guidelines from RFC 6390 . . . . . . . . . . 18 | 8. Compliance with Guidelines from RFC 6390 . . . . . . . . . . 19 | |||
| 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 | |||
| 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 | |||
| 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 | 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 | |||
| 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 | 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 | |||
| 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
| 13.1. Normative References . . . . . . . . . . . . . . . . . . 22 | 13.1. Normative References . . . . . . . . . . . . . . . . . . 23 | |||
| 13.2. Informative References . . . . . . . . . . . . . . . . . 23 | 13.2. Informative References . . . . . . . . . . . . . . . . . 23 | |||
| Appendix A. Changes Log . . . . . . . . . . . . . . . . . . . . 25 | Appendix A. Changes Log . . . . . . . . . . . . . . . . . . . . 25 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
| 1. Introduction | 1. Introduction | |||
| Most Service Providers' networks carry traffic with contents that are | Most Service Providers' networks carry traffic with contents that are | |||
| highly sensitive to packet loss [RFC7680], delay [RFC7679], and | highly sensitive to packet loss [RFC7680], delay [RFC7679], and | |||
| jitter [RFC3393]. | jitter [RFC3393]. | |||
| Service Providers need methodologies and tools to monitor and | Service Providers need methodologies and tools to monitor and | |||
| accurately measure network performance, in order to constantly | accurately measure network performance, in order to constantly | |||
| control the quality of experience perceived by their customers. | control the quality of experience perceived by their customers. | |||
| skipping to change at page 3, line 44 ¶ | skipping to change at page 3, line 44 ¶ | |||
| usually more easily understood by customers and provide much better | usually more easily understood by customers and provide much better | |||
| accuracy, especially for packet loss measurements. | accuracy, especially for packet loss measurements. | |||
| Therefore, the Alternate-Marking Method could be considered Hybrid or | Therefore, the Alternate-Marking Method could be considered Hybrid or | |||
| Passive, depending on the case. In the case where the marking method | Passive, depending on the case. In the case where the marking method | |||
| is obtained by changing existing field values of the packets the | is obtained by changing existing field values of the packets the | |||
| technique is Hybrid. In the case where the marking field is | technique is Hybrid. In the case where the marking field is | |||
| dedicated, reserved, and included in the protocol specification, the | dedicated, reserved, and included in the protocol specification, the | |||
| Alternate-Marking technique can be considered as Passive. | Alternate-Marking technique can be considered as Passive. | |||
| 1.1. Requirements Language | 1.1. Summary of Changes from RFC 8321 | |||
| This document defines the Alternate-Marking Method, addressing | ||||
| ambiguities and overtaking its experimental phase in the original | ||||
| specification [RFC8321]. | ||||
| The relevant changes are: | ||||
| o Added the recommendations about the methods to employ in case one | ||||
| or two flag bits are available for marking (Section 7). | ||||
| o Changed the structure to improve the readability. | ||||
| o Removed the wording about the initial experiments of the method | ||||
| and considerations that no longer apply. | ||||
| o Extended the description of detailed aspects of the methodology, | ||||
| e.g. synchronization, timing, packet fragmentation, marked and | ||||
| unmarked traffic handling. | ||||
| It is important to note that all the changes are totally backward | ||||
| compatible with [RFC8321] and no new additional technique has been | ||||
| introduced in this document compared to [RFC8321]. | ||||
| 1.2. Requirements Language | ||||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
| 14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| 2. Overview of the Method | 2. Overview of the Method | |||
| In order to perform packet loss measurements on a production traffic | In order to perform packet loss measurements on a production traffic | |||
| skipping to change at page 10, line 7 ¶ | skipping to change at page 10, line 18 ¶ | |||
| if packet misordering can be avoided; otherwise, the first packet of | if packet misordering can be avoided; otherwise, the first packet of | |||
| a block on R1 could be different from the first packet of the same | a block on R1 could be different from the first packet of the same | |||
| block on R2 (for instance, if that packet is lost between R1 and R2 | block on R2 (for instance, if that packet is lost between R1 and R2 | |||
| or it arrives after the next one). Since packet misordering is | or it arrives after the next one). Since packet misordering is | |||
| generally undetectable it is not possible to check whether the first | generally undetectable it is not possible to check whether the first | |||
| packet on R1 is the same on R2 and this is part of the intrinsic | packet on R1 is the same on R2 and this is part of the intrinsic | |||
| error in this measurement. | error in this measurement. | |||
| 3.2.1.1. Mean Delay | 3.2.1.1. Mean Delay | |||
| As mentioned before, the method previously exposed for measuring the | The method previously exposed for measuring the delay is sensitive to | |||
| delay is sensitive to out-of-order reception of packets. In order to | out-of-order reception of packets. In order to overcome this | |||
| overcome this problem, a different approach has been considered: it | problem, an approach based on the concept of mean delay can be | |||
| is based on the concept of mean delay. The mean delay is calculated | considered. The mean delay is calculated by considering the average | |||
| by considering the average arrival time of the packets within a | arrival time of the packets within a single block. The network | |||
| single block. The network device locally stores a timestamp for each | device locally stores a timestamp for each packet received within a | |||
| packet received within a single block: summing all the timestamps and | single block: summing all the timestamps and dividing by the total | |||
| dividing by the total number of packets received, the average arrival | number of packets received, the average arrival time for that block | |||
| time for that block of packets can be calculated. By subtracting the | of packets can be calculated. By subtracting the average arrival | |||
| average arrival times of two adjacent devices, it is possible to | times of two adjacent devices, it is possible to calculate the mean | |||
| calculate the mean delay between those nodes. When computing the | delay between those nodes. This method greatly reduces the number of | |||
| mean delay, the measurement error could be augmented by accumulating | timestamps that have to be collected (only one per block for each | |||
| the measurement error of a lot of packets. This method is robust to | network device) and it is robust to out-of-order packets with only a | |||
| out-of-order packets and also to packet loss (only a small error is | small error introduced in case of packet loss. But, when computing | |||
| introduced). Moreover, it greatly reduces the number of timestamps | the mean delay, the measurement error could be augmented by | |||
| (only one per block for each network device) that have to be | accumulating the measurement error of a lot of packets. | |||
| collected by the management system. On the other hand, it only gives | Additionally, it only gives one measure for the duration of the | |||
| one measure for the duration of the block, and it doesn't give the | block, and it doesn't give the minimum, maximum, and median delay | |||
| minimum, maximum, and median delay values [RFC6703]. This limitation | values [RFC6703]. This limitation could be overcome by reducing the | |||
| could be overcome by reducing the duration of the block (for | duration of the block (for instance, from minutes to seconds), which | |||
| instance, from 5 minutes to a few seconds), which implies a highly | implies a highly optimized implementation of the method. For this | |||
| optimized implementation of the method. | reason, the mean delay calculation may not be so viable in some | |||
| cases. | ||||
| 3.2.2. Double-Marking Methodology | 3.2.2. Double-Marking Methodology | |||
| The Single-Marking methodology for one-way delay measurement is | As mentioned above, the Single-Marking methodology for one-way delay | |||
| sensitive to out-of-order reception of packets. The first approach | measurement has some limitations, since it is sensitive to out-of- | |||
| to overcome this problem has been described before and is based on | order reception of packets and even the mean delay calculation is | |||
| the concept of mean delay. But the limitation of mean delay is that | limited because it doesn't give information about the delay value's | |||
| it doesn't give information about the delay value's distribution for | distribution for the duration of the block. Actually, it may be | |||
| the duration of the block. Additionally, it may be useful to have | useful to have not only the mean delay but also the minimum, maximum, | |||
| not only the mean delay but also the minimum, maximum, and median | and median delay values and, in wider terms, to know more about the | |||
| delay values and, in wider terms, to know more about the statistic | statistic distribution of delay values. So, in order to have more | |||
| distribution of delay values. So, in order to have more information | information about the delay and to overcome out-of-order issues, a | |||
| about the delay and to overcome out-of-order issues, a different | different approach can be introduced and it is based on a Double- | |||
| approach can be introduced; it is based on a Double-Marking | Marking methodology. | |||
| methodology. | ||||
| Basically, the idea is to use the first marking to create the | Basically, the idea is to use the first marking to create the | |||
| alternate flow and, within this colored flow, a second marking to | alternate flow and, within this colored flow, a second marking to | |||
| select the packets for measuring delay/jitter. The first marking is | select the packets for measuring delay/jitter. The first marking is | |||
| needed for packet loss and mean delay measurement. The second | needed for packet loss and may be used for mean delay measurement. | |||
| marking creates a new set of marked packets that are fully identified | The second marking creates a new set of marked packets that are fully | |||
| over the network, so that a network device can store the timestamps | identified over the network, so that a network device can store the | |||
| of these packets; these timestamps can be compared with the | timestamps of these packets; these timestamps can be compared with | |||
| timestamps of the same packets on a second router to compute packet | the timestamps of the same packets on a second router to compute | |||
| delay values for each packet. The number of measurements can be | packet delay values for each packet. The number of measurements can | |||
| easily increased by changing the frequency of the second marking. | be easily increased by changing the frequency of the second marking. | |||
| But the frequency of the second marking must not be too high in order | But the frequency of the second marking must not be too high in order | |||
| to avoid out-of-order issues. Between packets with the second | to avoid out-of-order issues. Between packets with the second | |||
| marking, there should be a security time gap (e.g., this gap could | marking, there should be a security time gap (e.g., this gap could | |||
| be, at the minimum, the mean network delay calculated with the | be, at the minimum, the mean network delay calculated with the | |||
| previous methodology) to avoid out-of-order issues and also to have a | previous methodology) to avoid out-of-order issues and also to have a | |||
| number of measurement packets that are rate independent. If a | number of measurement packets that are rate independent. If a | |||
| second-marking packet is lost, the delay measurement for the | second-marking packet is lost, the delay measurement for the | |||
| considered block is corrupted and should be discarded. | considered block is corrupted and should be discarded. | |||
| Mean delay is calculated on all the packets of a sample and is a | An efficient and robust mode is to select a single packet with the | |||
| simple computation to be performed for a Single-Marking Method. In | second marking for each block, in this way there is no time gap to | |||
| some cases, the mean delay measure is not sufficient to characterize | consider between the double-marked packets to avoid their reorder. | |||
| the sample, and more statistics of delay extent data are needed, | ||||
| e.g., percentiles, variance, and median delay values. The | The Double-Marking methodology can also be used to get more | |||
| conventional range (maximum-minimum) should be avoided for several | statistics of delay extent data, e.g., percentiles, variance, and | |||
| reasons, including stability of the maximum delay due to the | median delay values. Indeed, a subset of batch packets is selected | |||
| influence by outliers. RFC 5481 [RFC5481], Section 6.5 highlights | for extensive delay calculation by using the second marking and it is | |||
| how the 99.9th percentile of delay and delay variation is more | possible to perform a detailed analysis on these double-marked | |||
| helpful to performance planners. To overcome this drawback, the idea | packets. It is worth noting that there are classic algorithms for | |||
| is to couple the mean delay measure for the entire batch with a | ||||
| Double-Marking Method, where a subset of batch packets is selected | ||||
| for extensive delay calculation by using a second marking. In this | ||||
| way, it is possible to perform a detailed analysis on these double- | ||||
| marked packets. Please note that there are classic algorithms for | ||||
| median and variance calculation, but they are out of the scope of | median and variance calculation, but they are out of the scope of | |||
| this document. The comparison between the mean delay for the entire | this document. The conventional range (maximum-minimum) should be | |||
| batch and the mean delay on these double-marked packets gives useful | avoided for several reasons, including stability of the maximum delay | |||
| information since it is possible to understand if the Double-Marking | due to the influence by outliers. In this regard, RFC 5481 | |||
| measurements are actually representative of the delay trends. | [RFC5481], Section 6.5 highlights how the 99.9th percentile of delay | |||
| and delay variation is more helpful to performance planners. | ||||
| 3.3. Delay Variation Measurement | 3.3. Delay Variation Measurement | |||
| Similar to one-way delay measurement (both for Single Marking and | Similar to one-way delay measurement (both for Single Marking and | |||
| Double Marking), the method can also be used to measure the inter- | Double Marking), the method can also be used to measure the inter- | |||
| arrival jitter. We refer to the definition in RFC 3393 [RFC3393]. | arrival jitter. We refer to the definition in RFC 3393 [RFC3393]. | |||
| The alternation of colors, for a Single-Marking Method, can be used | The alternation of colors, for a Single-Marking Method, can be used | |||
| as a time reference to measure delay variations. In case of Double | as a time reference to measure delay variations. In case of Double | |||
| Marking, the time reference is given by the second-marked packets. | Marking, the time reference is given by the second-marked packets. | |||
| Considering the example depicted in Figure 2, R1 stores the timestamp | Considering the example depicted in Figure 2, R1 stores the timestamp | |||
| skipping to change at page 16, line 5 ¶ | skipping to change at page 16, line 10 ¶ | |||
| network delay between the network devices, and D_stddev is the | network delay between the network devices, and D_stddev is the | |||
| standard deviation of the delay. | standard deviation of the delay. | |||
| The available counting interval is L - 2d that must be > 0. | The available counting interval is L - 2d that must be > 0. | |||
| The condition that must be satisfied and is a requirement on the | The condition that must be satisfied and is a requirement on the | |||
| synchronization accuracy is: | synchronization accuracy is: | |||
| d < L/2. | d < L/2. | |||
| This is the fundamental rule for deciding when to read the counters | ||||
| and when to select the packets to be double-marked, indeed packet | ||||
| counter and double-marked packets MUST respectively be taken and | ||||
| chosen within the available counting interval that is not affected by | ||||
| error factors. | ||||
| It is worth mentioning that, if the time duration L of each block is | It is worth mentioning that, if the time duration L of each block is | |||
| not so small, the synchronization requirement could be satisfied even | not so small, the synchronization requirement could be satisfied even | |||
| with a relatively inaccurate synchronization method. This is true | with a relatively inaccurate synchronization method. This is true | |||
| for packet loss and two-way delay measurement, but not for one-way | for packet loss and two-way delay measurement, but not for one-way | |||
| delay measurement, where clock synchronization must be accurate. | delay measurement, where clock synchronization must be accurate. | |||
| Therefore, a system that uses only packet loss and two-way delay | Therefore, a system that uses only packet loss and two-way delay | |||
| measurement may not require a very precise synchronization. This is | measurement may not require a very precise synchronization. This is | |||
| because the value of the clocks of network devices does not affect | because the value of the clocks of network devices does not affect | |||
| the computation of the two-way delay measurement. | the computation of the two-way delay measurement. | |||
| skipping to change at page 26, line 37 ¶ | skipping to change at page 26, line 51 ¶ | |||
| Changes in draft-fioccola-rfc8321bis-04/draft-ietf-ippm-rfc8321bis-00 | Changes in draft-fioccola-rfc8321bis-04/draft-ietf-ippm-rfc8321bis-00 | |||
| include: | include: | |||
| o Revised "Introduction" section | o Revised "Introduction" section | |||
| o Revised sections 4.2 "Counting and Timestamping Packets" and 4.3 | o Revised sections 4.2 "Counting and Timestamping Packets" and 4.3 | |||
| on "Data Collection and Correlation" | on "Data Collection and Correlation" | |||
| o Revised section 5 on "Synchronization and Timing" | o Revised section 5 on "Synchronization and Timing" | |||
| Changes in draft-ietf-ippm-rfc8321bis-01 include: | ||||
| o New section on "Summary of Changes from RFC 8321" | ||||
| o Revised sections on "Single-Marking Methodology" and "Double- | ||||
| Marking Methodology" | ||||
| Authors' Addresses | Authors' Addresses | |||
| Giuseppe Fioccola (editor) | Giuseppe Fioccola (editor) | |||
| Huawei Technologies | Huawei Technologies | |||
| Riesstrasse, 25 | Riesstrasse, 25 | |||
| Munich 80992 | Munich 80992 | |||
| Germany | Germany | |||
| Email: giuseppe.fioccola@huawei.com | Email: giuseppe.fioccola@huawei.com | |||
| Mauro Cociglio | Mauro Cociglio | |||
| Telecom Italia | Telecom Italia | |||
| Via Reiss Romoli, 274 | Via Reiss Romoli, 274 | |||
| Torino 10148 | Torino 10148 | |||
| Italy | Italy | |||
| Email: mauro.cociglio@telecomitalia.it | Email: mauro.cociglio@telecomitalia.it | |||
| Greg Mirsky | Greg Mirsky | |||
| Ericsson | Ericsson | |||
| End of changes. 20 change blocks. | ||||
| 73 lines changed or deleted | 108 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/ | ||||