draft-ietf-pcn-3-in-1-encoding-04.txt | draft-ietf-pcn-3-in-1-encoding-05.txt | |||
---|---|---|---|---|
Congestion and Pre-Congestion B. Briscoe | Congestion and Pre-Congestion B. Briscoe | |||
Notification BT | Notification BT | |||
Internet-Draft T. Moncaster | Internet-Draft T. Moncaster | |||
Intended status: Experimental Moncaster Internet Consulting | Intended status: Standards Track Moncaster Internet Consulting | |||
Expires: July 15, 2011 M. Menth | Expires: November 22, 2011 M. Menth | |||
University of Tuebingen | University of Tuebingen | |||
January 11, 2011 | May 21, 2011 | |||
Encoding 3 PCN-States in the IP header using a single DSCP | Encoding 3 PCN-States in the IP header using a single DSCP | |||
draft-ietf-pcn-3-in-1-encoding-04 | draft-ietf-pcn-3-in-1-encoding-05 | |||
Abstract | Abstract | |||
The objective of Pre-Congestion Notification (PCN) is to protect the | The objective of Pre-Congestion Notification (PCN) is to protect the | |||
quality of service (QoS) of inelastic flows within a Diffserv domain. | quality of service (QoS) of inelastic flows within a Diffserv domain. | |||
On every link in the PCN domain, the overall rate of the PCN-traffic | On every link in the PCN domain, the overall rate of the PCN-traffic | |||
is metered, and PCN-packets are appropriately marked when certain | is metered, and PCN-packets are appropriately marked when certain | |||
configured rates are exceeded. Egress nodes provide decision points | configured rates are exceeded. Egress nodes provide decision points | |||
with information about the PCN-marks of PCN-packets which allows them | with information about the PCN-marks of PCN-packets which allows them | |||
to take decisions about whether to admit or block a new flow request, | to take decisions about whether to admit or block a new flow request, | |||
skipping to change at page 1, line 49 | skipping to change at page 1, line 49 | |||
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 http://datatracker.ietf.org/drafts/current/. | Drafts is at http://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 July 15, 2011. | This Internet-Draft will expire on November 22, 2011. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2011 IETF Trust and the persons identified as the | Copyright (c) 2011 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 | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://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 | |||
skipping to change at page 2, line 35 | skipping to change at page 2, line 35 | |||
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 | 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3. Requirements for and Applicability of 3-in-1 PCN Encoding . . 5 | 3. Requirements for and Applicability of 3-in-1 PCN Encoding . . 5 | |||
3.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 5 | 3.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.2. Requirements Imposed by Baseline Encoding . . . . . . . . 6 | 3.2. Requirements Imposed by Baseline Encoding . . . . . . . . 6 | |||
3.3. Applicability of 3-in-1 PCN Encoding . . . . . . . . . . . 7 | 3.3. Applicability of 3-in-1 PCN Encoding . . . . . . . . . . . 7 | |||
4. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 7 | 4. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 7 | |||
5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN | 5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN | |||
Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8 | 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8 | |||
6.1. Backward Compatibility with Pre-existing PCN | 6.1. Backward Compatibility with Pre-existing PCN | |||
Implementations . . . . . . . . . . . . . . . . . . . . . 8 | Implementations . . . . . . . . . . . . . . . . . . . . . 9 | |||
6.2. Recommendations for the Use of PCN Encoding Schemes . . . 9 | 6.2. Recommendations for the Use of PCN Encoding Schemes . . . 9 | |||
6.2.1. Use of Both Excess-Traffic-Marking and | 6.2.1. Use of Both Excess-Traffic-Marking and | |||
Threshold-Marking . . . . . . . . . . . . . . . . . . 9 | Threshold-Marking . . . . . . . . . . . . . . . . . . 10 | |||
6.2.2. Unique Use of Excess-Traffic-Marking . . . . . . . . . 9 | 6.2.2. Unique Use of Excess-Traffic-Marking . . . . . . . . . 10 | |||
6.2.3. Unique Use of Threshold-Marking . . . . . . . . . . . 10 | 6.2.3. Unique Use of Threshold-Marking . . . . . . . . . . . 10 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | |||
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 11 | 11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 11 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . . 11 | 12.1. Normative References . . . . . . . . . . . . . . . . . . . 11 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . . 12 | 12.2. Informative References . . . . . . . . . . . . . . . . . . 12 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 | Appendix A. Co-existence of ECN and PCN (informative) . . . . . . 13 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 | ||||
1. Introduction | 1. Introduction | |||
The objective of Pre-Congestion Notification (PCN) [RFC5559] is to | The objective of Pre-Congestion Notification (PCN) [RFC5559] is to | |||
protect the quality of service (QoS) of inelastic flows within a | protect the quality of service (QoS) of inelastic flows within a | |||
Diffserv domain, in a simple, scalable, and robust fashion. Two | Diffserv domain, in a simple, scalable, and robust fashion. Two | |||
mechanisms are used: admission control, to decide whether to admit or | mechanisms are used: admission control, to decide whether to admit or | |||
block a new flow request, and flow termination to terminate some | block a new flow request, and flow termination to terminate some | |||
existing flows during serious pre-congestion. To achieve this, the | existing flows during serious pre-congestion. To achieve this, the | |||
overall rate of PCN-traffic is metered on every link in the domain, | overall rate of PCN-traffic is metered on every link in the domain, | |||
skipping to change at page 3, line 49 | skipping to change at page 3, line 49 | |||
extension to the baseline encoding that uses the EXP codepoint to | extension to the baseline encoding that uses the EXP codepoint to | |||
provide a third PCN marking state in the IP header, still using a | provide a third PCN marking state in the IP header, still using a | |||
single Diffserv codepoint. This encoding scheme is called "3-in-1 | single Diffserv codepoint. This encoding scheme is called "3-in-1 | |||
PCN encoding". | PCN encoding". | |||
This document only concerns the PCN wire protocol encoding for all IP | This document only concerns the PCN wire protocol encoding for all IP | |||
headers, whether IPv4 or IPv6. It makes no changes or | headers, whether IPv4 or IPv6. It makes no changes or | |||
recommendations concerning algorithms for congestion marking or | recommendations concerning algorithms for congestion marking or | |||
congestion response. Other documents define the PCN wire protocol | congestion response. Other documents define the PCN wire protocol | |||
for other header types. For example, the MPLS encoding is defined in | for other header types. For example, the MPLS encoding is defined in | |||
[RFC5129]. Appendix A provides an informative example for a mapping | [RFC5129] and Appendix A of that document provides an informative | |||
between the encodings in IP and in MPLS. | example for a mapping between the encodings in IP and in MPLS. | |||
1.1. Changes in This Version (to be removed by RFC Editor) | 1.1. Changes in This Version (to be removed by RFC Editor) | |||
From draft-ietf-pcn-3-in-1-encoding-04 to -05: | ||||
* Draft moved to standards track as per working group | ||||
discussions. | ||||
* Added Appendix A discussing ECN handling in the PCN-domain. | ||||
* Clarified that this document modifies [RFC5696]. | ||||
* ....... | ||||
From draft-ietf-pcn-3-in-1-encoding-03 to -04: | From draft-ietf-pcn-3-in-1-encoding-03 to -04: | |||
* Updated document to reflect RFC6040. | * Updated document to reflect RFC6040. | |||
* Re-wrote introduction. | * Re-wrote introduction. | |||
* Re-wrote section on applicability. | * Re-wrote section on applicability. | |||
* Re-wrote section on choosing encoding scheme. | * Re-wrote section on choosing encoding scheme. | |||
skipping to change at page 9, line 24 | skipping to change at page 9, line 37 | |||
6.2. Recommendations for the Use of PCN Encoding Schemes | 6.2. Recommendations for the Use of PCN Encoding Schemes | |||
NOTE: This sub-section is informative not normative. | NOTE: This sub-section is informative not normative. | |||
When deciding which PCN encoding is suitable an operator needs to | When deciding which PCN encoding is suitable an operator needs to | |||
take account of how many PCN states need to be encoded. The | take account of how many PCN states need to be encoded. The | |||
following table gives guidelines on which encoding to use with either | following table gives guidelines on which encoding to use with either | |||
threshold-marking, excess-traffic marking or both. | threshold-marking, excess-traffic marking or both. | |||
+------------------------+--------------------------------+ | +------------------------+--------------------------------+ | |||
| Used marking schemes | Recommended encoding scheme | | | Marking schemes in use | Recommended encoding scheme | | |||
+------------------------+--------------------------------+ | +------------------------+--------------------------------+ | |||
| Only threshold-marking | Baseline encoding [RFC5696] | | | Only threshold-marking | Baseline encoding [RFC5696] | | |||
+------------------------+--------------------------------+ | +------------------------+--------------------------------+ | |||
| Only excess-traffic- | Baseline encoding [RFC5696] | | | Only excess-traffic- | Baseline encoding [RFC5696] | | |||
| marking | or 3-in-1 PCN encoding | | | marking | or 3-in-1 PCN encoding | | |||
+------------------------+--------------------------------+ | +------------------------+--------------------------------+ | |||
| Threshold-marking and | 3-in-1 PCN encoding | | | Threshold-marking and | 3-in-1 PCN encoding | | |||
| excess-traffic-marking | | | | excess-traffic-marking | | | |||
+------------------------+--------------------------------+ | +------------------------+--------------------------------+ | |||
skipping to change at page 10, line 48 | skipping to change at page 11, line 16 | |||
The 3-in-1 PCN encoding uses a PCN-compatible DSCP and the ECN field | The 3-in-1 PCN encoding uses a PCN-compatible DSCP and the ECN field | |||
to encode PCN-marks. One codepoint allows non-PCN traffic to be | to encode PCN-marks. One codepoint allows non-PCN traffic to be | |||
carried with the same PCN-compatible DSCP and three other codepoints | carried with the same PCN-compatible DSCP and three other codepoints | |||
support three PCN marking states with different levels of severity. | support three PCN marking states with different levels of severity. | |||
The use of this PCN encoding scheme presupposes that any tunnels in | The use of this PCN encoding scheme presupposes that any tunnels in | |||
the PCN region have been updated to comply with [RFC6040]. | the PCN region have been updated to comply with [RFC6040]. | |||
10. Acknowledgements | 10. Acknowledgements | |||
Thanks to Phil Eardley, Teco Boot, and Kwok Ho Chan for reviewing | Thanks to Phil Eardley, Teco Boot, Kwok Ho Chan and Georgios | |||
this document. | Karaginannis for reviewing this document. | |||
11. Comments Solicited | 11. Comments Solicited | |||
To be removed by RFC Editor: Comments and questions are encouraged | To be removed by RFC Editor: Comments and questions are encouraged | |||
and very welcome. They can be addressed to the IETF Congestion and | and very welcome. They can be addressed to the IETF Congestion and | |||
Pre-Congestion working group mailing list <pcn@ietf.org>, and/or to | Pre-Congestion working group mailing list <pcn@ietf.org>, and/or to | |||
the authors. | the authors. | |||
12. References | 12. References | |||
skipping to change at page 11, line 29 | skipping to change at page 11, line 42 | |||
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, | [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, | |||
"Definition of the Differentiated Services Field (DS | "Definition of the Differentiated Services Field (DS | |||
Field) in the IPv4 and IPv6 Headers", RFC 2474, | Field) in the IPv4 and IPv6 Headers", RFC 2474, | |||
December 1998. | December 1998. | |||
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition | [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition | |||
of Explicit Congestion Notification (ECN) to IP", | of Explicit Congestion Notification (ECN) to IP", | |||
RFC 3168, September 2001. | RFC 3168, September 2001. | |||
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit | ||||
Congestion Notification (ECN) Signaling with Nonces", | ||||
RFC 3540, June 2003. | ||||
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the | [RFC4301] Kent, S. and K. Seo, "Security Architecture for the | |||
Internet Protocol", RFC 4301, December 2005. | Internet Protocol", RFC 4301, December 2005. | |||
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration | ||||
Guidelines for DiffServ Service Classes", RFC 4594, | ||||
August 2006. | ||||
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion | [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion | |||
Marking in MPLS", RFC 5129, January 2008. | Marking in MPLS", RFC 5129, January 2008. | |||
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) | [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) | |||
Architecture", RFC 5559, June 2009. | Architecture", RFC 5559, June 2009. | |||
[RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN- | [RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN- | |||
Nodes", RFC 5670, November 2009. | Nodes", RFC 5670, November 2009. | |||
[RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline | [RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline | |||
Encoding and Transport of Pre-Congestion Information", | Encoding and Transport of Pre-Congestion Information", | |||
RFC 5696, November 2009. | RFC 5696, November 2009. | |||
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated | ||||
Services Code Point (DSCP) for Capacity-Admitted Traffic", | ||||
RFC 5865, May 2010. | ||||
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion | [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion | |||
Notification", RFC 6040, November 2010. | Notification", RFC 6040, November 2010. | |||
12.2. Informative References | 12.2. Informative References | |||
[I-D.ietf-pcn-cl-edge-behaviour] | [I-D.ietf-pcn-cl-edge-behaviour] | |||
Charny, A., Huang, F., Karagiannis, G., Menth, M., and T. | Charny, A., Huang, F., Karagiannis, G., Menth, M., and T. | |||
Taylor, "PCN Boundary Node Behaviour for the Controlled | Taylor, "PCN Boundary Node Behaviour for the Controlled | |||
Load (CL) Mode of Operation", | Load (CL) Mode of Operation", | |||
draft-ietf-pcn-cl-edge-behaviour-08 (work in progress), | draft-ietf-pcn-cl-edge-behaviour-08 (work in progress), | |||
December 2010. | December 2010. | |||
[I-D.ietf-pcn-encoding-comparison] | [I-D.ietf-pcn-encoding-comparison] | |||
Chan, K., Karagiannis, G., Moncaster, T., Menth, M., | Karagiannis, G., Chan, K., Moncaster, T., Menth, M., | |||
Eardley, P., and B. Briscoe, "Pre-Congestion Notification | Eardley, P., and B. Briscoe, "Overview of Pre-Congestion | |||
Encoding Comparison", | Notification Encoding", | |||
draft-ietf-pcn-encoding-comparison-03 (work in progress), | draft-ietf-pcn-encoding-comparison-05 (work in progress), | |||
October 2010. | April 2011. | |||
[I-D.ietf-pcn-sm-edge-behaviour] | [I-D.ietf-pcn-sm-edge-behaviour] | |||
Charny, A., Karagiannis, G., Menth, M., and T. Taylor, | Charny, A., Karagiannis, G., Menth, M., and T. Taylor, | |||
"PCN Boundary Node Behaviour for the Single Marking (SM) | "PCN Boundary Node Behaviour for the Single Marking (SM) | |||
Mode of Operation", draft-ietf-pcn-sm-edge-behaviour-05 | Mode of Operation", draft-ietf-pcn-sm-edge-behaviour-05 | |||
(work in progress), December 2010. | (work in progress), December 2010. | |||
Appendix A. Co-existence of ECN and PCN (informative) | ||||
The PCN encoding described in this document re-uses the bits of the | ||||
ECN field in the IP header. Consequently, this disables ECN within | ||||
the PCN domain. Appendix B of [RFC5696] included advice on handling | ||||
ECN traffic within a PCN-domain. This appendix clarifies that | ||||
advice. | ||||
For the purposes of this appendix we define two forms of traffic that | ||||
might arrive at a PCN-ingress node. These are Admission-controlled | ||||
traffic and Non-admission-controlled traffic. | ||||
Admission-controlled traffic will be remarked to the PCN-compatible | ||||
DSCP by the PCN-ingress node. Two mechanisms can be used to identify | ||||
such traffic: | ||||
a. flow signalling associates a filterspec with a need for admission | ||||
control (e.g. through RSVP or some equivalent message down from a | ||||
SIP server to the ingress), and the PCN-ingress remarks traffic | ||||
matching that filterspec to a PCN-compatible DSCP, as its chosen | ||||
admission control mechanism. | ||||
b. Traffic arrives with a DSCP that implies it requires admission | ||||
control such as VOICE-ADMIT [RFC5865] or Interactive Real-Time, | ||||
Broadcast TV when used for video on demand, and Multimedia | ||||
Conferencing [RFC4594][RFC5865]. | ||||
All other traffic can be thought of as Non-admission-controlled. | ||||
However such traffic may still need to share the same DSCP as the | ||||
Admission-controlled traffic. This may be due to policy (for | ||||
instance if it is high priority voice traffic), or may be because | ||||
there is a shortage of local DSCPs. | ||||
ECN [RFC3168] is an end-to-end congestion notification mechanism. As | ||||
such it is possible that some traffic entering the PCN-domain may | ||||
also be ECN capable The following lists the four cases for how e2e | ||||
ECN traffic may wish to be treated while crossing a PCN domain: | ||||
ECN capable traffic that does not require admission control and does | ||||
not carry a DSCP that the PCN-ingress is using for PCN-capable | ||||
traffic. This requires no action. | ||||
ECN capable traffic that does not require admission control but | ||||
carries a DSCP that the PCN-ingress is using for PCN-capable | ||||
traffic. There are two options. | ||||
* The ingress maps the DSCP to a local DSCP with the same | ||||
scheduling PHB as the original DSCP, and the egress re-maps it | ||||
to the original PCN-compatible DSCP. | ||||
* The ingress tunnels the traffic, setting not-PCN in the outer | ||||
header; note that this turns off ECN for this traffic within | ||||
the PCN domain. | ||||
The first option is recommended unless the operator is short of | ||||
local DSCPs. | ||||
ECN-capable Admission-controlled traffic: There are two options. | ||||
* The PCN-ingress places this traffic in a tunnel with a PCN- | ||||
compatible DSCP in the outer header. The PCN-egress zeroes the | ||||
ECN-field before decapsulation. | ||||
* The PCN-ingress drops CE-marked packets and the PCN-egress | ||||
zeros the ECN field of all PCN packets. | ||||
The second option is not recommended unless tunnelling is not | ||||
possible for some reason.. | ||||
ECN-capable Admission-controlled where the e2e transport somehow | ||||
indicates that it wants to see PCN marks: NOTE this is currently | ||||
experimental only. | ||||
Schemes have been suggested where PCN marks may be leaked out of | ||||
the PCN-domain and used by the end hosts to modify realtime data | ||||
rates. Currently all such schemes are experimental and the | ||||
following is for guidance only. | ||||
The PCN-ingress needs to tunnel the traffic using [RFC6040]. The | ||||
PCN-egress should not zero the ECN field, and the tunnel egress | ||||
should use [RFC6040] normal mode (preserving any PCN-marking). | ||||
Note that this may turn ECT(0) into ECT(1) and so is not | ||||
compatible with the experimental ECN nonce [RFC3540]. | ||||
In the list above any form of IP-in-IP tunnel can be used unless | ||||
specified otherwise. NB, We assume a logical separation of tunneling | ||||
and PCN actions in both PCN-ingress and PCN-egress nodes. That is, | ||||
any tunneling action happens wholly outside the PCN-domain as | ||||
illustrated in the following figure: | ||||
, . . . . . PCN-domain . . . . . . | ||||
. ,--------. ,--------. . | ||||
. _| PCN- |___________________| PCN- |_ . | ||||
. / | ingress | | egress | \ . | ||||
.| '---------' '--------' |. | ||||
| . . . . . . . . . . . . . . .| | ||||
,--------. ,--------. | ||||
_____| Tunnel | | Tunnel |____ | ||||
| Ingress | - - ECN preserved inside tunnel - - | Egress | | ||||
'---------' '--------' | ||||
Figure 4: Separation of tunneling and PCN actions | ||||
Authors' Addresses | Authors' Addresses | |||
Bob Briscoe | Bob Briscoe | |||
BT | BT | |||
B54/77, Adastral Park | B54/77, Adastral Park | |||
Martlesham Heath | Martlesham Heath | |||
Ipswich IP5 3RE | Ipswich IP5 3RE | |||
UK | UK | |||
Phone: +44 1473 645196 | Phone: +44 1473 645196 | |||
skipping to change at page 13, line 7 | skipping to change at page 16, line 7 | |||
Layer Marney | Layer Marney | |||
Colchester CO5 9UZ | Colchester CO5 9UZ | |||
UK | UK | |||
Phone: +44 7764 185416 | Phone: +44 7764 185416 | |||
Email: toby@moncaster.com | Email: toby@moncaster.com | |||
URI: http://www.moncaster.com/ | URI: http://www.moncaster.com/ | |||
Michael Menth | Michael Menth | |||
University of Tuebingen | University of Tuebingen | |||
Sand 13 | Sand 13 | |||
72076 Tuebingen | Tuebingen 72076 | |||
Germany | Germany | |||
Phone: +49 7071 2970505 | Phone: +49 7071 2970505 | |||
Email: menth@informatik.uni-tuebingen.de | Email: menth@informatik.uni-tuebingen.de | |||
End of changes. 18 change blocks. | ||||
22 lines changed or deleted | 149 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |