draft-ietf-ccamp-dpm-00.txt   draft-ietf-ccamp-dpm-01.txt 
Network Working Group W. Sun Network Working Group W. Sun, Ed.
Internet-Draft SJTU Internet-Draft SJTU
Intended status: Standards Track G. Zhang Intended status: Standards Track G. Zhang, Ed.
Expires: November 29, 2010 CATR Expires: April 12, 2011 CATR
May 28, 2010 October 9, 2010
Label Switched Path (LSP) Data Path Delay Metric in Generalized MPLS/ Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS/
MPLS-TE Networks MPLS-TE Networks
draft-ietf-ccamp-dpm-00.txt draft-ietf-ccamp-dpm-01.txt
Abstract Abstract
When setting up a label switched path (LSP) in Generalized MPLS and When setting up a label switched path (LSP) in Generalized MPLS and
MPLS/TE networks, the completion of the signaling process does not MPLS/TE networks, the completion of the signaling process does not
necessarily mean that the cross connection along the LSP have been necessarily mean that the cross connection along the LSP have been
programmed accordingly and in a timely manner. Meanwhile, the programmed accordingly and in a timely manner. Meanwhile, the
completion of signaling process may be used by applications as completion of signaling process may be used by applications as
indication that data path has become usable. The existence of this indication that data path has become usable. The existence of this
delay and the possible failure of cross connection programming, if delay and the possible failure of cross connection programming, if
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 November 29, 2010. This Internet-Draft will expire on April 12, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 3, line 42 skipping to change at page 3, line 42
7. A singleton Definition for PRFD . . . . . . . . . . . . . . . 15 7. A singleton Definition for PRFD . . . . . . . . . . . . . . . 15
7.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 15
7.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 15 7.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 15
7.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 15 7.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 15
7.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 15 7.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 15
7.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 15 7.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 15
7.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 16 7.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 16
7.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 16 7.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 16
8. A Definition for Samples of Data Path Delay . . . . . . . . . 18 8. A singleton Definition for PSFD . . . . . . . . . . . . . . . 18
8.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 18
8.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 18 8.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 18
8.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 18 8.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 18
8.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 18 8.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 18
8.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 19 8.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 19
8.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 19 8.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 19
8.7. Typical testing cases . . . . . . . . . . . . . . . . . . 19 8.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 20
8.7.1. With No LSP in the Network . . . . . . . . . . . . . . 19
8.7.2. With a Number of LSPs in the Network . . . . . . . . . 20
9. Some Statistics Definitions for Metrics to Report . . . . . . 21 9. A singleton Definition for PSRD . . . . . . . . . . . . . . . 21
9.1. The Minimum of Metric . . . . . . . . . . . . . . . . . . 21 9.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 21
9.2. The Median of Metric . . . . . . . . . . . . . . . . . . . 21 9.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 21
9.3. The percentile of Metric . . . . . . . . . . . . . . . . . 21 9.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 21
9.4. The Failure Probability . . . . . . . . . . . . . . . . . 21 9.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 21
9.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 21
9.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 22
9.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 10. A Definition for Samples of Data Path Delay . . . . . . . . . 24
10.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 24
10.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 24
10.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 24
10.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 24
10.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 25
10.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 25
10.7. Typical testing cases . . . . . . . . . . . . . . . . . . 25
10.7.1. With No LSP in the Network . . . . . . . . . . . . . 25
10.7.2. With a Number of LSPs in the Network . . . . . . . . 25
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 11. Some Statistics Definitions for Metrics to Report . . . . . . 27
11.1. The Minimum of Metric . . . . . . . . . . . . . . . . . . 27
11.2. The Median of Metric . . . . . . . . . . . . . . . . . . . 27
11.3. The percentile of Metric . . . . . . . . . . . . . . . . . 27
11.4. The Failure Probability . . . . . . . . . . . . . . . . . 27
11.4.1. Failure Count . . . . . . . . . . . . . . . . . . . . 28
11.4.2. Failure Ratio . . . . . . . . . . . . . . . . . . . . 28
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 12. Security Considerations . . . . . . . . . . . . . . . . . . . 29
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
13.1. Normative References . . . . . . . . . . . . . . . . . . . 25
13.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
15.1. Normative References . . . . . . . . . . . . . . . . . . . 32
15.2. Informative References . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
Ideally, the completion of the signaling process means that the Ideally, the completion of the signaling process means that the
signaled label switched path (LSP) is available and is ready to carry signaled label switched path (LSP) is available and is ready to carry
traffic. However, in actual implementations, vendors may choose to traffic. However, in actual implementations, vendors may choose to
program the cross connection in a pipelined manner, so that the program the cross connection in a pipelined manner, so that the
overall LSP provisioning delay can be reduced. In such situations, overall LSP provisioning delay can be reduced. In such situations,
the data path may not be available instantly after the signaling the data path may not be available instantly after the signaling
process completes. Implementation deficiency may also cause the process completes. Implementation deficiency may also cause the
inconsistency in between the signaling process and data path inconsistency in between the signaling process and data path
provisioning. For example, if the data plane failed to program the provisioning. For example, if the data plane fails to program the
cross connection accordingly but does not manage to report this to cross connection accordingly but does not manage to report this to
the control plane, the signaling process may complete successfully the control plane, the signaling process may complete successfully
while the corresponding data path will never become functional at while the corresponding data path will never become functional at
all. all.
On the other hand, the completion of the signaling process may be On the other hand, the completion of the signaling process may be
used in many cases as indication of data path availability. For used in many cases as indication of data path availability. For
example, when invoking through User Network Interface (UNI), a client example, when invoking through User Network Interface (UNI), a client
device or an application may use the reception of the correct RESV device or an application may use the reception of the correct RESV
message as indication that data path is fully functional and start to message as indication that data path is fully functional and start to
skipping to change at page 5, line 37 skipping to change at page 5, line 37
failure. failure.
Although RSVP(-TE) specifications have suggested that the cross Although RSVP(-TE) specifications have suggested that the cross
connections are programmed before signaling messages are propagated connections are programmed before signaling messages are propagated
upstream, it is still worthwhile to verify the conformance of an upstream, it is still worthwhile to verify the conformance of an
implementation and measure the delay, when necessary. implementation and measure the delay, when necessary.
This document defines a series of performance metrics to evaluate the This document defines a series of performance metrics to evaluate the
availability of data path when the signaling process completes. The availability of data path when the signaling process completes. The
metrics defined in this document complements the control plane metrics defined in this document complements the control plane
metrics defined in [RFC5814]. They can be used to verify the metrics defined in [RFC5814]. These metrics can be used to verify
conformance of implementations against related specifications, as the conformance of implementations against related specifications, as
elaborated in [I-D.shiomoto-ccamp-switch-programming]. They also can elaborated in [I-D.shiomoto-ccamp-switch-programming]. They also can
be used to build more robust applications. be used to build more robust applications.
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 this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Overview of Performance Metrics 3. Overview of Performance Metrics
In this memo, we define three performance metrics to characterize the In this memo, we define five performance metrics to characterize the
performance of data path provisioning with GMPLS/MPLS-TE signaling. performance of data path provisioning with GMPLS/MPLS-TE signaling.
These metrics complement the metrics defined in [RFC5814], in the These metrics complement the metrics defined in [RFC5814], in the
sense that the completion of the signaling process for a Label sense that the completion of the signaling process for a Label
Switched Path (LSP) and the programming of cross connections along Switched Path (LSP) and the programming of cross connections along
the LSP may not be consistent. The performance metrics in [RFC5814] the LSP may not be consistent. The performance metrics in [RFC5814]
characterize the performance of LSP provisioning from the pure characterize the performance of LSP provisioning from the pure
signaling point of view, while the metric in this document takes into signaling point of view, while the metric in this document takes into
account the validity of the data path. account the validity of the data path.
The three metrics are: The five metrics are:
o RRFD - the delay between RESV message received by ingress node and o RRFD - the delay between RESV message received by ingress node and
forward data path becomes available. forward data path becomes available.
o RSRD - the delay between RESV message sent by egress node and o RSRD - the delay between RESV message sent by egress node and
reverse data path becomes available. reverse data path becomes available.
o PRFD - the delay between PATH message received by egress node and o PRFD - the delay between PATH message received by egress node and
forward data path becomes available. forward data path becomes available.
o PSFD - the delay between PATH message sent by ingress and forward
data path becomes available.
o PSRD - the delay between PATH message sent by ingress and reverse
data path becomes available.
As in [RFC5814], we continue to use the structures and notions As in [RFC5814], we continue to use the structures and notions
introduced and discussed in the IPPM Framework document, [RFC2330] introduced and discussed in the IPPM Framework document, [RFC2330]
[RFC2679] [RFC2681]. The reader is assumed to be familiar with the [RFC2679] [RFC2681]. The reader is assumed to be familiar with the
notions in those documents. The readers are assumed to be familiar notions in those documents. The readers are assumed to be familiar
with the definitions in [RFC5814] as well. with the definitions in [RFC5814] as well.
4. Terms used in this document 4. Terms used in this document
o Forward data path - the data path from the ingress to the egress. o Forward data path - the data path from the ingress to the egress.
Instances of forward data path include the data path of a uni- Instances of forward data path include the data path of a uni-
directional LSP and data path from the ingress node to the egress directional LSP and data path from the ingress node to the egress
node in a bidirectional LSP. node in a bidirectional LSP.
o Reverse data path - the data path from the egress to the ingress o Reverse data path - the data path from the egress to the ingress
in a bidirectional LSP. in a bidirectional LSP.
o Data path delay - the time needed to complete the data
path configuration, in relation to the signaling process. five
types of data path delay are defined in this document, namely
RRFD, RSRD and PRFD. Data path delay used in this document must
be distinguished from the data path transmission delay.
o Error free signal - data plane specific indication of availability o Error free signal - data plane specific indication of availability
of the data path. For example, for packet switched interfaces, of the data path. For example, for packet switching capable
the reception of the first error free packet from one side of the interfaces, the reception of the first error free packet from one
LSP to the other can be used as the error free signal. For SDH/ side of the LSP to the other can be used as the error free signal.
SONET cross connects, the disappearance of alarm can be used as For SDH/SONET cross connects, the disappearance of alarm can be
the error free signal. Through out this document, we will use the used as the error free signal. Through out this document, we will
"error free signal" as a general term. An implementations must use the "error free signal" as a general term. An implementations
choose a proper data path signal that is specific to the data path must choose a proper data path signal that is specific to the data
technology being tested. path technology being tested.
o Ingress/egress node - in this memo, an ingress/egress node means a o Ingress/egress node - in this memo, an ingress/egress node means a
measurement endpoint with both control plane and data plane measurement endpoint with both control plane and data plane
features. Typically, the control plane part on an ingress/egress features. Typically, the control plane part on an ingress/egress
node interact with the control plane of the network under test. node interact with the control plane of the network under test.
The data plane part of an ingress/egress node will generate data The data plane part of an ingress/egress node will generate data
path signals and send the signal to the data plane of the network path signals and send the signal to the data plane of the network
under test, or receive data path signals from the network under under test, or receive data path signals from the network under
test. test.
skipping to change at page 10, line 25 skipping to change at page 10, line 25
The following issues are likely to come up in practice: The following issues are likely to come up in practice:
o The accuracy of RRFD depends on the clock resolution of both the o The accuracy of RRFD depends on the clock resolution of both the
ingress node and egress node. Clock synchronization between the ingress node and egress node. Clock synchronization between the
ingress node and egress node is required. ingress node and egress node is required.
o The accuracy of RRFD is also dependent on how the error free o The accuracy of RRFD is also dependent on how the error free
signal is received and may differ significantly when the underline signal is received and may differ significantly when the underline
data plane technology is different. For instance, for an LSP data plane technology is different. For instance, for an LSP
between a pair of Ethernet interfaces, the ingress node (sometimes between a pair of Ethernet interfaces, the ingress node may use a
the tester) may use a rate based method to verify the availability rate based method to verify the availability of the data path and
of the data path and use the reception of the first error free use the reception of the first error free frame as the error free
frame as the error free signal. In this case, the interval signal. In this case, the interval between two successive frames
between two successive frames has a significant impact on has a significant impact on accuracy. It is RECOMMENDED that the
accuracy. It is RECOMMENDED that the ingress node uses small ingress node uses small intervals, under the condition that the
intervals, under the condition that the injected traffic does not injected traffic does not exceed the capacity of the forward data
exceed the capacity of the forward data path. The value of the path. The value of the interval MUST be reported.
interval MUST be reported.
o The accuracy of RRFD is also dependent on the time needed to o The accuracy of RRFD is also dependent on the time needed to
propagate the error free signal from the ingress node to the propagate the error free signal from the ingress node to the
egress node. A typical value of propagating the error free signal egress node. A typical value of propagating the error free signal
from the ingress node to the egress node under the same from the ingress node to the egress node under the same
measurement setup MAY be reported. The methodology to obtain such measurement setup MAY be reported. The methodology to obtain such
values is outside the scope of this document. values is outside the scope of this document.
o It is possible that under some implementations, a node may program o It is possible that under some implementations, a node may program
the cross connection before it sends PATH message further the cross connection before it sends PATH message further
downstream and the data path may be available before a RESV downstream and the data path may be available before a RESV
message reaches the ingress node. In such cases, RRFD can be a message reaches the ingress node. In such cases, RRFD can be a
negetive value. It is RECOMMENDED that PRFD measurement is negative value. It is RECOMMENDED that PRFD measurement is
carried out to further characterize the forward data path delay carried out to further characterize the forward data path delay
when a negetive RRFD value is observed. when a negative RRFD value is observed.
o If error free signal is received by the egress node before PATH o If error free signal is received by the egress node before PATH
message is sent, an error MUST be reported and the measurement message is sent on the ingress node, an error MUST be reported and
SHOULD terminate. the measurement SHOULD terminate.
o If the corresponding RESV message is received, but no error free o If the corresponding RESV message is received, but no error free
signal is received by the egress node within a reasonable period signal is received by the egress node within a reasonable period
of time, RRFD MUST be treated as undefined. The value of the of time, i.e., a threshold, RRFD MUST be treated as undefined.
threshold MUST be reported. The value of the threshold MUST be reported.
o If the LSP setup fails, RRFD MUST NOT be counted. o If the LSP setup fails, the metric value MUST NOT be counted.
5.7. Methodologies 5.7. Methodologies
Generally the methodology would proceed as follows: Generally the methodology would proceed as follows:
o Make sure that the network has enough resource to set up the o Make sure that the network has enough resource to set up the
requested LSP. requested LSP.
o Start the data path measurement and/or monitoring procedures on o Start the data path measurement and/or monitoring procedures on
the ingress node and egress node. If error free signal is the ingress node and egress node. If error free signal is
received by the egress node before PATH message is sent, report an received by the egress node before PATH message is sent, report an
error and terminate the mmeasurement. error and terminate the measurement.
o At the ingress node, form the PATH message according to the LSP o At the ingress node, form the PATH message according to the LSP
requirements and send the message towards the egress node. requirements and send the message towards the egress node.
o Upon receiving the last bit of the corresponding RESV message, o Upon receiving the last bit of the corresponding RESV message,
take the time stamp (T1) on the ingress node as soon as possible. take the time stamp (T1) on the ingress node as soon as possible.
o When an error free signal is observed on the egress node, take the o When an error free signal is observed on the egress node, take the
time stamp (T2) as soon as possible. An estimate of RRFD (T2 - time stamp (T2) as soon as possible. An estimate of RRFD (T2 -
T1) can be computed. T1) can be computed.
o If the corresponding RESV message arrives, but no error free o If the corresponding RESV message arrives, but no error free
signal is received within a reasonable period of time by the signal is received within a reasonable period of time by the
ingress node, RRFD is deemed to be undefined. ingress node, RRFD is deemed to be undefined.
o If the LSP setup fails, RRFD is not counted. o If the LSP setup fails, RRFD is not counted.
6. A singleton Definition for RSRD 6. A singleton Definition for RSRD
This part defines a metric for reverse data path delay when an LSP is This part defines a metric for reverse data path delay when an LSP is
setup. setup.
As described in [I-D.shiomoto-ccamp-switch-programming], the As described in [I-D.shiomoto-ccamp-switch-programming], the
completion of the RSVP-TE signaling process does not necessarily mean completion of the RSVP-TE signaling process does not necessarily mean
that the cross connections along the LSP being setup are in place and that the cross connections along the LSP being setup are in place and
ready to carry traffic. This metric defines the time difference ready to carry traffic. This metric defines the time difference
between the completion of the signaling process and the completion of between the completion of the signaling process and the completion of
the cross connection programming along the reverse data path. This the cross connection programming along the reverse data path. This
skipping to change at page 13, line 43 skipping to change at page 13, line 43
o The accuracy of RSRD is also dependent on the time needed to o The accuracy of RSRD is also dependent on the time needed to
propagate the error free signal from the egress node to the propagate the error free signal from the egress node to the
ingress node. A typical value of propagating the error free ingress node. A typical value of propagating the error free
signal from the egress node to the ingress node under the same signal from the egress node to the ingress node under the same
measurement setup MAY be reported. The methodology to obtain such measurement setup MAY be reported. The methodology to obtain such
values is outside the scope of this document. values is outside the scope of this document.
o If the corresponding RESV message is sent, but no error free o If the corresponding RESV message is sent, but no error free
signal is received by the ingress node within a reasonable period signal is received by the ingress node within a reasonable period
of time, RSRD MUST be treated as undefined. The value of the of time, i.e., a threshold, RSRD MUST be treated as undefined.
threshold MUST be reported. The value of the threshold MUST be reported.
o If error free signal is received before PATH message is sent, an o If error free signal is received before PATH message is sent on
error MUST be reported and the measurement SHOULD terminate. the ingress node, an error MUST be reported and the measurement
SHOULD terminate.
o If the LSP setup fails, RSRD MUST NOT be counted. o If the LSP setup fails, the metric value MUST NOT be counted.
6.7. Methodologies 6.7. Methodologies
Generally the methodology would proceed as follows: Generally the methodology would proceed as follows:
o Make sure that the network has enough resource to set up the o Make sure that the network has enough resource to set up the
requested LSPs. requested LSP.
o Start the data path measurement and/or monitoring procedures on o Start the data path measurement and/or monitoring procedures on
the ingress node and egress node. If error free signal is the ingress node and egress node. If error free signal is
received by the ingress node before PATH message is sent, report received by the ingress node before PATH message is sent, report
an error and terminate the mmeasurement. an error and terminate the measurement.
o At the ingress node, form the PATH message according to the LSP o At the ingress node, form the PATH message according to the LSP
requirements and send the message towards the egress node. requirements and send the message towards the egress node.
o Upon sending the last bit of the corresponding RESV message, take o Upon sending the last bit of the corresponding RESV message, take
the time stamp (T1) on the egress node as soon as possible. the time stamp (T1) on the egress node as soon as possible.
o When an error free signal is observed on the ingress node, take o When an error free signal is observed on the ingress node, take
the time stamp (T2) as soon as possible. An estimate of RSRD the time stamp (T2) as soon as possible. An estimate of RSRD
(T2-T1) can be computed. (T2-T1) can be computed.
o If the LSP setup fails, RSRD is not counted. o If the LSP setup fails, RSRD is not counted.
o If no error free signal is received within a reasonable period of o If no error free signal is received within a reasonable period of
time by the ingress node, RSRD is deemed to be undefined. time by the ingress node, RSRD is deemed to be undefined.
7. A singleton Definition for PRFD 7. A singleton Definition for PRFD
This part defines a metric for forward data path delay when an LSP is This part defines a metric for forward data path delay when an LSP is
setup. setup.
In an RSVP-TE implementation, when setting up an LSP, each node may In an RSVP-TE implementation, when setting up an LSP, each node may
choose to program the cross connection before it sends PATH message choose to program the cross connection before it sends PATH message
further downstream. In this case, the forward data path may become further downstream. In this case, the forward data path may become
available before the signaling process completes, ie. before the RESV available before the signaling process completes, ie. before the RESV
reaches the ingress node. This metric can be used to identify such reaches the ingress node. This metric can be used to identify such
implementation practice and give useful information to application implementation practice and give useful information to application
skipping to change at page 16, line 36 skipping to change at page 16, line 36
o The accuracy of PRFD is also dependent on the time needed to o The accuracy of PRFD is also dependent on the time needed to
propagate the error free signal from the ingress node to the propagate the error free signal from the ingress node to the
egress node. A typical value of propagating the error free signal egress node. A typical value of propagating the error free signal
from the ingress node to the egress node under the same from the ingress node to the egress node under the same
measurement setup MAY be reported. The methodology to obtain such measurement setup MAY be reported. The methodology to obtain such
values is outside the scope of this document. values is outside the scope of this document.
o If error free signal is received before PATH message is sent, an o If error free signal is received before PATH message is sent, an
error MUST be reported and the measurement SHOULD terminate. error MUST be reported and the measurement SHOULD terminate.
o If the LSP setup fails, PRFD MUST NOT be counted. o If the LSP setup fails, the metric value MUST NOT be counted.
o This metric SHOULD be used together with RRFD. It is RECOMMENDED o This metric SHOULD be used together with RRFD. It is RECOMMENDED
that PRFD measurement is carried out after a negetive RRFD value that PRFD measurement is carried out after a negetive RRFD value
has already been observed. has already been observed.
7.7. Methodologies 7.7. Methodologies
Generally the methodology would proceed as follows: Generally the methodology would proceed as follows:
o Make sure that the network has enough resource to set up the o Make sure that the network has enough resource to set up the
requested LSPs. requested LSP.
o Start the data path measurement and/or monitoring procedures on o Start the data path measurement and/or monitoring procedures on
the ingress node and egress node. If error free signal is the ingress node and egress node. If error free signal is
received by the egress node before PATH message is sent, report an received by the egress node before PATH message is sent, report an
error and terminate the mmeasurement. error and terminate the measurement.
o At the ingress node, form the PATH message according to the LSP o At the ingress node, form the PATH message according to the LSP
requirements and send the message towards the egress node. requirements and send the message towards the egress node.
o Upon receiving the last bit of the PATH message, take the time o Upon receiving the last bit of the PATH message, take the time
stamp (T1) on the egress node as soon as possible. stamp (T1) on the egress node as soon as possible.
o When an error free signal is observed on the egress node, take the o When an error free signal is observed on the egress node, take the
time stamp (T2) as soon as possible. An estimate of PRFD (T2-T1) time stamp (T2) as soon as possible. An estimate of PRFD (T2-T1)
can be computed. can be computed.
o If the LSP setup fails, PRFD is not counted. o If the LSP setup fails, PRFD is not counted.
o If no error free signal is received within a reasonable period of o If no error free signal is received within a reasonable period of
time by the egress node, PRFD is deemed to be undefined. time by the egress node, PRFD is deemed to be undefined.
8. A Definition for Samples of Data Path Delay 8. A singleton Definition for PSFD
In Section Section 5, Section 6 and Section 7, we define the This part defines a metric for forward data path delay when an LSP is
singleton metrics of data path delay. Now we define how to get one setup.
particular sample of such delay. Sampling is to select a particular
potion of singleton values of the given parameters. Like in
[RFC2330], we use Poisson sampling as an example.
8.1. Metric Name As described in [I-D.shiomoto-ccamp-switch-programming], the
completion of the RSVP-TE signaling process does not necessarily mean
that the cross connections along the LSP being setup are in place and
ready to carry traffic. This metric defines the time from the PATH
message sent by the ingress node, till the completion of the cross
connection programming along the LSP forward data path.
Type <X> Data path delay sample, where X is either RRFD, RSRD or 8.1. Motivation
PRFD.
8.2. Metric Parameters PSFD is useful for the following reasons:
o For the reasons described in
[I-D.shiomoto-ccamp-switch-programming], the data path setup delay
may not be consistent with the control plane LSP setup delay. The
data path setup delay metric is more precise for LSP setup
performance measurement.
o The completion of the signaling process may be used by application
designers as indication of data path availability. The difference
between the control plane setup delay and data path delay, and the
potential failure of cross connection programming, if not properly
treated, will result in data loss or application failure. This
metric can thus help designers to improve the application model.
8.2. Metric Name
PSFD
8.3. Metric Parameters
o ID0, the ingress LSR ID
o ID1, the egress LSR ID
o T, a time when the setup is attempted
8.4. Metric Units
Either a real number of milli-seconds or undefined.
8.5. Definition
For a real number dT, PSFD from ingress node ID0 to egress node ID1
at T is dT means that ingress node ID0 sends the first bit of a PATH
message to egress node ID1 at T, and an error free signal is received
by the egress node ID1 using a data plane specific test pattern at
T+dT.
8.6. Discussion
The following issues are likely to come up in practice:
o The accuracy of PSFD depends on the clock resolution of both the
ingress node and egress node. And clock synchronization between
the ingress node and egress node is required.
o The accuracy of this metric is also dependent on how the error
free signal is received and may differ significantly when the
underlying data plane technology is different. For instance, for
an LSP between a pair of Ethernet interfaces, the ingress node may
use a rate based method to verify the availability of the data
path and use the reception of the first error free frame as the
error free signal. In this case, the interval between two
successive frames has a significant impact on accuracy. It is
RECOMMENDED that the ingress node uses small intervals, under the
condition that the injected traffic does not exceed the capacity
of the forward data path. The value of the interval MUST be
reported.
o The accuracy of this metric is also dependent on the time needed
to propagate the error free signal from the ingress node to the
egress node. A typical value of propagating the error free signal
from the ingress node to the egress node under the same
measurement setup MAY be reported. The methodology to obtain such
values is outside the scope of this document.
o If error free signal is received before PATH message is sent, an
error MUST be reported and the measurement SHOULD terminate.
o If the LSP setup fails, the metric value MUST NOT be counted.
o If the PATH message is sent by the ingress node, but no error free
signal is received by the egress node within a reasonable period
of time, i.e., a threshold, the metric value MUST be treated as
undefined. The value of the threshold MUST be reported.
8.7. Methodologies
Generally the methodology would proceed as follows:
o Make sure that the network has enough resource to set up the
requested LSP.
o Start the data path measurement and/or monitoring procedures on
the ingress node and egress node. If error free signal is
received by the egress node before PATH message is sent, report an
error and terminate the measurement.
o At the ingress node, form the PATH message according to the LSP
requirements and send the message towards the egress node. A
timestamp (T1) may be stored locally in the ingress node when the
PATH message packet is sent towards the egress node.
o When an error free signal is observed on the egress node, take the
time stamp (T2) as soon as possible. An estimate of PSFD (T2-T1)
can be computed.
o If the LSP setup fails, this metric is not counted.
o If no error free signal is received within a reasonable period of
time by the egress node, PSFD is deemed to be undefined.
9. A singleton Definition for PSRD
This part defines a metric for reverse data path delay when an LSP is
setup.
This metric defines the time from the ingress node sends the PATH
message, till the completion of the cross connection programming
along the LSP reverse data path. This metric MAY be used together
with PSFD to characterize the data path delay of a bidirectional LSP.
9.1. Motivation
PSRD is useful for the following reasons:
o For the reasons described in
[I-D.shiomoto-ccamp-switch-programming], the data path setup delay
may not be consistent with the control plane LSP setup delay. The
data path setup delay metric is more precise for LSP setup
performance measurement.
o The completion of the signaling process may be used by application
designers as indication of data path availability. The difference
between the control plane setup delay and data path delay, and the
potential failure of cross connection programming, if not properly
treated, will result in data loss or application failure. This
metric can thus help designers to improve the application model.
9.2. Metric Name
PSRD
9.3. Metric Parameters
o ID0, the ingress LSR ID
o ID1, the egress LSR ID
o T, a time when the setup is attempted
9.4. Metric Units
Either a real number of milli-seconds or undefined.
9.5. Definition
For a real number dT, PSRD from ingress node ID0 to egress node ID1
at T is dT means that ingress node ID0 sends the first bit of a PATH
message to egress node ID1 at T, and an error free signal is received
through the reverse data path by the ingress node ID0 using a data
plane specific test pattern at T+dT.
9.6. Discussion
The following issues are likely to come up in practice:
o The accuracy of PSRD depends on the clock resolution of the
ingress node. And clock synchronization between the ingress node
and egress node is not required.
o The accuracy of this metric is also dependent on how the error
free signal is received and may differ significantly when the
underlying data plane technology is different. For instance, for
an LSP between a pair of Ethernet interfaces, the egress node may
use a rate based method to verify the availability of the data
path and use the reception of the first error free frame as the
error free signal. In this case, the interval between two
successive frames has a significant impact on accuracy. It is
RECOMMENDED that the egress node uses small intervals, under the
condition that the injected traffic does not exceed the capacity
of the forward data path. The value of the interval MUST be
reported.
o The accuracy of this metric is also dependent on the time needed
to propagate the error free signal from the egress node to the
ingress node. A typical value of propagating the error free
signal from the egress node to the ingress node under the same
measurement setup MAY be reported. The methodology to obtain such
values is outside the scope of this document.
o If error free signal is received before PATH message is sent, an
error MUST be reported and the measurement SHOULD terminate.
o If the LSP setup fails, this metric value MUST NOT be counted.
o If the PATH message is sent by the ingress node, but no error free
signal is received by the ingress node within a reasonable period
of time, i.e., a threshold, the metric value MUST be treated as
undefined. The value of the threshold MUST be reported.
9.7. Methodologies
Generally the methodology would proceed as follows:
o Make sure that the network has enough resource to set up the
requested LSP.
o Start the data path measurement and/or monitoring procedures on
the ingress node and egress node. If error free signal is
received by the egress node before PATH message is sent, report an
error and terminate the measurement.
o At the ingress node, form the PATH message according to the LSP
requirements and send the message towards the egress node. A
timestamp (T1) may be stored locally in the ingress node when the
PATH message packet is sent towards the egress node.
o When an error free signal is observed on the ingress node, take
the time stamp (T2) as soon as possible. An estimate of PSFD
(T2-T1) can be computed.
o If the LSP setup fails, this metric is not counted.
o If no error free signal is received within a reasonable period of
time by the ingress node, the metric value is deemed to be
undefined.
10. A Definition for Samples of Data Path Delay
In Section 5, Section 6, Section 7, Section 8 and Section 9, we
define the singleton metrics of data path delay. Now we define how
to get one particular sample of such delay. Sampling is to select a
particular potion of singleton values of the given parameters. Like
in [RFC2330], we use Poisson sampling as an example.
10.1. Metric Name
Type <X> Data path delay sample, where X is either RRFD, RSRD, PRFD,
PSFD and PSRD.
10.2. Metric Parameters
o ID0, the ingress LSR ID o ID0, the ingress LSR ID
o ID1, the egress LSR ID o ID1, the egress LSR ID
o T0, a time o T0, a time
o Tf, a time o Tf, a time
o Lambda, a rate in the reciprocal seconds o Lambda, a rate in the reciprocal seconds
o Th, LSP holding time o Th, LSP holding time
o Td, the maximum waiting time for successful LSP setup o Td, the maximum waiting time for successful LSP setup
o Ts, the maximum waiting time for error free signal o Ts, the maximum waiting time for error free signal
8.3. Metric Units 10.3. Metric Units
A sequence of pairs; the elements of each pair are: A sequence of pairs; the elements of each pair are:
o T, a time when setup is attempted o T, a time when setup is attempted
o dT, either a real number of milli-seconds or undefined o dT, either a real number of milli-seconds or undefined
8.4. Definition 10.4. Definition
Given T0, Tf, and lambda, compute a pseudo-random Poisson process Given T0, Tf, and Lambda, compute a pseudo-random Poisson process
beginning at or before T0, with average arrival rate lambda, and beginning at or before T0, with average arrival rate Lambda, and
ending at or after Tf. Those time values greater than or equal to T0 ending at or after Tf. Those time values greater than or equal to T0
and less than or equal to Tf are then selected. At each of the times and less than or equal to Tf are then selected. At each of the times
in this process, we obtain the value of data path delay sample of in this process, we obtain the value of data path delay sample of
type <X> at this time. The value of the sample is the sequence made type <X> at this time. The value of the sample is the sequence made
up of the resulting <time, type <X> data path delay> pairs. If there up of the resulting <time, type <X> data path delay> pairs. If there
are no such pairs, the sequence is of length zero and the sample is are no such pairs, the sequence is of length zero and the sample is
said to be empty. said to be empty.
8.5. Discussion 10.5. Discussion
The following issues are likely to come up in practice: The following issues are likely to come up in practice:
o The parameters lambda, Th and Td should be carefully chosen, as o The parameters Lambda, Th and Td should be carefully chosen, as
explained in the discussions for LSP setup delay. explained in the discussions for LSP setup delay (see [RFC5814]).
o The parameter Ts should be carefully chosen and MUST be reported o The parameter Ts should be carefully chosen and MUST be reported
along with the LSP forward/reverse data path delay sample. along with the LSP forward/reverse data path delay sample.
o Note that for online or passive measurements, the holding time of 10.6. Methodologies
an LSP is determined by actual traffic, hence in this case Th is
not an input parameter.
8.6. Methodologies
Generally the methodology would proceed as follows: Generally the methodology would proceed as follows:
o The selection of specific times, using the specified Poisson o The selection of specific times, using the specified Poisson
arrival process, and arrival process, and
o Set up the LSP and obtain the value of type <X> data path delay o Set up the LSP and obtain the value of type <X> data path delay
o Release the LSP after Th, and wait for the next Poisson arrival o Release the LSP after Th, and wait for the next Poisson arrival
process process
8.7. Typical testing cases 10.7. Typical testing cases
8.7.1. With No LSP in the Network 10.7.1. With No LSP in the Network
8.7.1.1. Motivation 10.7.1.1. Motivation
Data path delay with no LSP in the network is important because this Data path delay with no LSP in the network is important because this
reflects the inherent delay of a device implementation. The minimum reflects the inherent delay of a device implementation. The minimum
value provides an indication of the delay that will likely be value provides an indication of the delay that will likely be
experienced when an LSP data path is configured under light traffic experienced when an LSP data path is configured under light traffic
load. load.
8.7.1.2. Methodologies 10.7.1.2. Methodologies
Make sure that there is no LSP in the network, and proceed with the Make sure that there is no LSP in the network, and proceed with the
methodologies described in Section 8.6. methodologies described in Section 10.6.
8.7.2. With a Number of LSPs in the Network 10.7.2. With a Number of LSPs in the Network
8.7.2.1. Motivation 10.7.2.1. Motivation
Data path delay with a number of LSPs in the network is important Data path delay with a number of LSPs in the network is important
because it reflects the performance of an operational network with because it reflects the performance of an operational network with
considerable load. This delay may vary significantly as the number considerable load. This delay may vary significantly as the number
of existing LSPs varies. It can be used as a scalability metric of a of existing LSPs varies. It can be used as a scalability metric of a
device implementation. device implementation.
8.7.2.2. Methodologies 10.7.2.2. Methodologies
Setup the required number of LSPs, and wait until the network reaches Setup the required number of LSPs, and wait until the network reaches
a stable state, and then proceed with the methodologies described in a stable state, and then proceed with the methodologies described in
Section 8.6. Section 10.6.
9. Some Statistics Definitions for Metrics to Report 11. Some Statistics Definitions for Metrics to Report
Given the samples of the performance metric, we now offer several Given the samples of the performance metric, we now offer several
statistics of these samples to report. From these statistics, we can statistics of these samples to report. From these statistics, we can
draw some useful conclusions of a GMPLS network. The value of these draw some useful conclusions of a GMPLS network. The value of these
metrics is either a real number, or an undefined number of metrics is either a real number, or an undefined number of
milliseconds. In the following discussion, we only consider the milliseconds. In the following discussion, we only consider the
finite values. finite values.
9.1. The Minimum of Metric 11.1. The Minimum of Metric
The minimum of metric is the minimum of all the dT values in the The minimum of metric is the minimum of all the dT values in the
sample. In computing this, undefined values SHOULD be treated as sample. In computing this, undefined values SHOULD be treated as
infinitely large. Note that this means that the minimum could thus infinitely large. Note that this means that the minimum could thus
be undefined if all the dT values are undefined. In addition, the be undefined if all the dT values are undefined. In addition, the
metric minimum SHOULD be set to undefined if the sample is empty. metric minimum SHOULD be set to undefined if the sample is empty.
9.2. The Median of Metric 11.2. The Median of Metric
Metric median is the median of the dT values in the given sample. In Metric median is the median of the dT values in the given sample. In
computing the median, the undefined values MUST NOT be counted in. computing the median, the undefined values MUST NOT be counted in.
The Median SHOULD be set to undefined if all the dT values are
undefined, or if the sample is empty.
9.3. The percentile of Metric 11.3. The percentile of Metric
Given a metric and a percent X between 0% and 100%, the Xth The "empirical distribution function" (EDF) of a set of scalar
percentile of all the dT values in the sample. In addition, the measurements is a function F(x) which for any x gives the fractional
percentile is undefined if the sample is empty. proportion of the total measurements that were <= x.
Example: suppose we take a sample and the results are: Stream1 = Given a percentage X, the X-th percentile of Metric means the
<<T1, 100 msec>, <T2, 110 msec>, <T3, undefined>, <T4, 90 msec>, smallest value of x for which F(x) >= X. In computing the percentile,
<T5,500 msec>>. Then the 50th percentile would be 110 msec, since 90 undefined values MUST NOT be included.
msec and 100 msec are smaller, and 110 and 500 msec are larger
(undefined values are not counted in).
9.4. The Failure Probability See [RFC2330] for further details.
In the process of LSP setup/release, it may fail for some reason. 11.4. The Failure Probability
The failure probability is the ratio of the unsuccessful times to the
total times.
10. Security Considerations Given the samples of the performance metric, we now offer two
statistics of failure events of these samples to report. The two
statistics can be applied to both forward data path and reverse data
path. For example, when a sample of RRFD has been obtained the
forward data path failure statistics can be obtained, while when a
sample of RSRD can be used to calculate the reverse data path failure
statistics. Detailed definitions of the Failure Count and Failure
Ratio are given below.
11.4.1. Failure Count
Failure Count is defined as the number of the undefined value of the
corresponding performance metric in a sample. The value of Failure
Count is an integer.
11.4.2. Failure Ratio
Failure Ratio is the percentage of the number of failure events to
the total number of requests in a sample. Here an failure event
means that the signaling completes with no error, while no error free
signal is observed. The calculation for Failure Ratio is defined as
follows:
Failure Ratio = Number of undefined value/(Number of valid metric
values + Number of undefined value) * 100%.
12. Security Considerations
In the control plane, since the measurement endpoints must be In the control plane, since the measurement endpoints must be
conformant to signaling specifications and behave as normal signaling conformant to signaling specifications and behave as normal signaling
endpoints, it will not incur other security issues than normal LSP endpoints, it will not incur other security issues than normal LSP
provisioning. However, the measurement parameters must be carefully provisioning. However, the measurement parameters must be carefully
selected so that the measurements inject trivial amounts of selected so that the measurements inject trivial amounts of
additional traffic into the networks they measure. If they inject additional traffic into the networks they measure. If they inject
"too much" traffic, they can skew the results of the measurement, and "too much" traffic, they can skew the results of the measurement, and
in extreme cases cause congestion and denial of service. in extreme cases cause congestion and denial of service.
In the data plane, the measurement endpoint MUST use a signal that is In the data plane, the measurement endpoint MUST use a signal that is
consistent with what is specified in the control plane. For example, consistent with what is specified in the control plane. For example,
in a packet switched case, the traffic injected into the data plane in a packet switched case, the traffic injected into the data plane
MUST NOT exceed the specified rate in the corresponding LSP setup MUST NOT exceed the specified rate in the corresponding LSP setup
request. In a wavelength switched case, the measurement endpoint request. In a wavelength switched case, the measurement endpoint
MUST use the specified or negotiated lambda with appropriate power. MUST use the specified or negotiated lambda with appropriate power.
The security considerations pertaining to the original RSVP protocol The security considerations pertaining to the original RSVP protocol
[RFC2205] and its TE extensions [RFC3209] also remain relevant. [RFC2205] and its TE extensions [RFC3209] also remain relevant.
11. IANA Considerations 13. IANA Considerations
This document makes no requests for IANA action. This document makes no requests for IANA action.
12. Acknowledgements 14. Acknowledgements
We wish to thank Adrian Farrel and Lou Berger for their comments and We wish to thank Adrian Farrel and Lou Berger for their comments and
helps. helps.
This document contains ideas as well as text that have appeared in This document contains ideas as well as text that have appeared in
existing IETF documents. The authors wish to thank G. Almes, S. existing IETF documents. The authors wish to thank G. Almes, S.
Kalidindi and M. Zekauskas. Kalidindi and M. Zekauskas.
We also wish to thank Weisheng Hu, Yaohui Jin and Wei Guo in the We also wish to thank Weisheng Hu, Yaohui Jin and Wei Guo in the
state key laboratory of advanced optical communication systems and state key laboratory of advanced optical communication systems and
networks for the valuable comments. We also wish to thank the networks for the valuable comments. We also wish to thank the
support from NSFC and 863 program of China. support from NSFC and 863 program of China.
13. References 15. References
13.1. Normative References 15.1. Normative References
[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.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999. Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, September 1999. Delay Metric for IPPM", RFC 2681, September 1999.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
13.2. Informative References 15.2. Informative References
[I-D.shiomoto-ccamp-switch-programming] [I-D.shiomoto-ccamp-switch-programming]
Shiomoto, K. and A. Farrel, "Advice on When It is Safe to Shiomoto, K. and A. Farrel, "Advice on When It is Safe to
Start Sending Data on Label Switched Paths Established Start Sending Data on Label Switched Paths Established
Using RSVP-TE", draft-shiomoto-ccamp-switch-programming-01 Using RSVP-TE", draft-shiomoto-ccamp-switch-programming-01
(work in progress), October 2009. (work in progress), October 2009.
[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.
 End of changes. 71 change blocks. 
124 lines changed or deleted 409 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/