GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6777

Internet Engineering Task Force (IETF) W. Sun, Ed. Request for Comments: 6777 SJTU Category: Standards Track G. Zhang, Ed. ISSN: 2070-1721 CATR

                                                                J. Gao
                                                                Huawei
                                                                G. Xie
                                                          UC Riverside
                                                            R. Papneja
                                                                Huawei
                                                         November 2012

Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS

          and MPLS Traffic Engineering (MPLS-TE) Networks

Abstract

 When setting up a Label Switched Path (LSP) in Generalized MPLS
 (GMPLS) and MPLS Traffic Engineering (MPLS-TE) networks, the
 completion of the signaling process does not necessarily mean that
 the cross-connection along the LSP has been programmed accordingly
 and in a timely manner.  Meanwhile, the completion of the signaling
 process may be used by LSP users or applications that control their
 use as an indication that the data path has become usable.  The
 existence of the inconsistency between the signaling messages and
 cross-connection programming, and the possible failure of cross-
 connection programming, if not properly treated, will result in data
 loss or even application failure.  Characterization of this
 performance can thus help designers to improve the way in which LSPs
 are used and to make applications or tools that depend on and use
 LSPs more robust.  This document defines a series of performance
 metrics to evaluate the connectivity of the data path in the
 signaling process.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6777.

Sun, et al. Standards Track [Page 1] RFC 6777 LSP Data Path Delay Metrics November 2012

Copyright Notice

 Copyright (c) 2012 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1. Introduction ....................................................4
 2. Conventions Used in This Document ...............................5
 3. Overview of Performance Metrics .................................5
 4. Terms Used in This Document .....................................6
 5. A Singleton Definition for RRFD .................................7
    5.1. Motivation .................................................7
    5.2. Metric Name ................................................7
    5.3. Metric Parameters ..........................................7
    5.4. Metric Units ...............................................7
    5.5. Definition .................................................8
    5.6. Discussion .................................................8
    5.7. Methodologies ..............................................9
 6. A Singleton Definition for RSRD ................................10
    6.1. Motivation ................................................10
    6.2. Metric Name ...............................................10
    6.3. Metric Parameters .........................................10
    6.4. Metric Units ..............................................11
    6.5. Definition ................................................11
    6.6. Discussion ................................................11
    6.7. Methodologies .............................................12
 7. A Singleton Definition for PRFD ................................13
    7.1. Motivation ................................................13
    7.2. Metric Name ...............................................13
    7.3. Metric Parameters .........................................13
    7.4. Metric Units ..............................................13
    7.5. Definition ................................................14
    7.6. Discussion ................................................14
    7.7. Methodologies .............................................15

Sun, et al. Standards Track [Page 2] RFC 6777 LSP Data Path Delay Metrics November 2012

 8. A Singleton Definition for PSFD ................................16
    8.1. Motivation ................................................16
    8.2. Metric Name ...............................................16
    8.3. Metric Parameters .........................................16
    8.4. Metric Units ..............................................16
    8.5. Definition ................................................17
    8.6. Discussion ................................................17
    8.7. Methodologies .............................................18
 9. A Singleton Definition for PSRD ................................19
    9.1. Motivation ................................................19
    9.2. Metric Name ...............................................19
    9.3. Metric Parameters .........................................19
    9.4. Metric Units ..............................................19
    9.5. Definition ................................................20
    9.6. Discussion ................................................20
    9.7. Methodologies .............................................21
 10. A Definition for Samples of Data Path Delay ...................22
    10.1. Metric Name ..............................................22
    10.2. Metric Parameters ........................................22
    10.3. Metric Units .............................................22
    10.4. Definition ...............................................22
    10.5. Discussion ...............................................23
    10.6. Methodologies ............................................23
    10.7. Typical Testing Cases ....................................23
         10.7.1. With No LSP in the Network ........................23
         10.7.2. With a Number of LSPs in the Network ..............24
 11. Some Statistics Definitions for Metrics to Report .............24
    11.1. The Minimum of the Metric ................................24
    11.2. The Median of the Metric .................................24
    11.3. The Percentile of the Metric .............................24
    11.4. Failure Probability ......................................25
         11.4.1. Failure Count .....................................25
         11.4.2. Failure Ratio .....................................25
 12. Security Considerations .......................................25
 13. References ....................................................26
    13.1. Normative References .....................................26
    13.2. Informative References ...................................26
 Appendix A. Acknowledgements ......................................27
 Appendix B. Contributors ..........................................28

Sun, et al. Standards Track [Page 3] RFC 6777 LSP Data Path Delay Metrics November 2012

1. Introduction

 Label Switched Paths (LSPs) are established, controlled, and
 allocated for use by management tools or directly by the components
 that use them.  In this document, we call such management tools and
 the components that use LSPs "applications".  Such applications may
 be Network Management Systems (NMSs); hardware or software components
 that forward data onto virtual links; programs or tools that use
 dedicated links; or any other user of an LSP.
 Ideally, the completion of the signaling process means that the
 signaled LSP is ready to carry traffic.  However, in actual
 implementations, vendors may choose to program the cross-connection
 in a pipelined manner, so that the overall LSP provisioning delay can
 be reduced.  In such situations, the data path may not be ready for
 use instantly after the signaling process completes.  Implementation
 deficiency may also cause inconsistency between the signaling process
 and data path provisioning.  For example, if the data plane fails to
 program the cross-connection accordingly but does not manage to
 report this to the control plane, the signaling process may complete
 successfully while the corresponding data path will never become
 functional at all.
 On the other hand, the completion of the signaling process may be
 used in many cases as an indication of data path connectivity.  For
 example, when invoking through the User-Network Interface (UNI)
 [RFC4208], a client device or an application may use the reception of
 the correct Resv message as an indication that the data path is fully
 functional and start to transmit traffic.  This will result in data
 loss or even application failure.
 Although RSVP(-TE) specifications have suggested that the cross-
 connections are programmed before signaling messages are propagated
 upstream, it is still worthwhile to verify the conformance of an
 implementation and measure the delay, when necessary.
 This document defines a series of performance metrics to evaluate the
 connectivity of the data path during the signaling process.  The
 metrics defined in this document complement the control plane metrics
 defined in [RFC5814].  These metrics can be used to verify the
 conformance of implementations against related specifications, as
 elaborated in [RFC6383].  They also can be used to build more robust
 applications.

Sun, et al. Standards Track [Page 4] RFC 6777 LSP Data Path Delay Metrics November 2012

2. Conventions Used in This Document

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in [RFC2119].

3. Overview of Performance Metrics

 In this memo, we define five performance metrics to characterize the
 performance of data path provisioning with GMPLS/MPLS-TE signaling.
 These metrics complement the metrics defined in [RFC5814], in the
 sense that the completion of the signaling process for an LSP and the
 programming of cross-connections along the LSP may not be consistent.
 The performance metrics in [RFC5814] characterize the performance of
 LSP provisioning from the pure signaling point of view, while the
 metric in this document takes into account the validity of the data
 path.
 The five metrics are:
 o  Resv Received, Forward Data (RRFD) - the delay between the point
    when the Resv message is received by the ingress node and the
    forward data path becomes ready for use.
 o  Resv Sent, Reverse Data (RSRD) - the delay between the point when
    the Resv message is sent by the egress node and the reverse data
    path becomes ready for use.
 o  PATH Received, Forward Data (PRFD) - the delay between the point
    when the PATH message is received by the egress node and the
    forward data path becomes ready for use.
 o  PATH Sent, Forward Data (PSFD) - the delay between the point when
    the PATH message is sent by the ingress node and the forward data
    path becomes ready for use.
 o  PATH Sent, Reverse Data (PSRD) - the delay between the point when
    the PATH message is sent by the ingress node and the reverse data
    path becomes ready for use.
 As in [RFC5814], we continue to use the structures and notions
 introduced and discussed in the IP Performance Metrics (IPPM)
 Framework documents [RFC2330] [RFC2679] [RFC2681].  The reader is
 assumed to be familiar with the notions in those documents.  The
 reader is also assumed to be familiar with the definitions in
 [RFC5814].

Sun, et al. Standards Track [Page 5] RFC 6777 LSP Data Path Delay Metrics November 2012

4. Terms Used in This Document

 o  Forward data path - the data path from the ingress node to the
    egress node.  Instances of a forward data path include the data
    path of a unidirectional LSP and a data path from the ingress node
    to the egress node in a bidirectional LSP.
 o  Reverse data path - the data path from the egress node to the
    ingress node 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, PRFD, PSFD, and PSRD.  Data path delay as used in this
    document must be distinguished from the transmission delay along
    the data path, i.e., the time needed to transmit traffic from one
    side of the data path to the other.
 o  Error-free signal - data-plane-specific indication of connectivity
    of the data path.  For example, for interfaces capable of packet
    switching, the reception of the first error-free packet from one
    side of the LSP to the other may be used as the error-free signal.
    For Synchronous Digital Hierarchy/Synchronous Optical Network
    (SDH/SONET) cross-connects, the disappearance of alarm can be used
    as the error-free signal.  Throughout this document, we will use
    "error-free signal" as a general term.  An implementation must
    choose a proper data path signal that is specific to the data path
    technology being tested.
 o  Ingress/egress node - in this memo, an ingress/egress node means a
    measurement endpoint with both control plane and data plane
    features.  Typically, the control plane part on an ingress/egress
    node interacts with the control plane of the network under test.
    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
    under test, or receive data path signals from the network under
    test.

Sun, et al. Standards Track [Page 6] RFC 6777 LSP Data Path Delay Metrics November 2012

5. A Singleton Definition for RRFD

 This part defines a metric for forward data path delay when an LSP is
 set up.
 As described in [RFC6383], the completion of the RSVP-TE signaling
 process does not necessarily mean that the cross-connections along
 the LSP being set up are in place and ready to carry traffic.  This
 metric defines the time difference between the reception of a Resv
 message by the ingress node and the completion of the cross-
 connection programming along the forward data path.

5.1. Motivation

 RRFD is useful for the following reasons:
 o  For the reasons described in [RFC6383], the data path may not be
    ready for use instantly after the completion of the RSVP-TE
    signaling process.  The delay itself is part of the implementation
    performance.
 o  The completion of the signaling process may be used by application
    designers as an indication of data path connectivity.  The
    existence of this delay and the potential failure of cross-
    connection programming, if not properly treated, will result in
    data loss or application failure.  The typical value of this delay
    can thus help designers to improve the application model.

5.2. Metric Name

 RRFD = Resv Received, Forward Data path

5.3. Metric Parameters

 o  ID0, the ingress Label Switching Router (LSR) ID
 o  ID1, the egress LSR ID
 o  T, a time when the setup is attempted

5.4. Metric Units

 The value of RRFD is either a real number of milliseconds or
 undefined.

Sun, et al. Standards Track [Page 7] RFC 6777 LSP Data Path Delay Metrics November 2012

5.5. Definition

 For a real number dT,
    RRFD from ingress node ID0 to egress node ID1 at T is dT
 means that
 o  ingress node ID0 sends a PATH message to egress node ID1,
 o  the last bit of the corresponding Resv message is received by
    ingress node ID0 at T, and
 o  an error-free signal is received by egress node ID1 by using a
    data-plane-specific test pattern at T+dT.

5.6. Discussion

 The following issues are likely to come up in practice:
 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 is required.
 o  The accuracy of RRFD 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 connectivity 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 use small intervals, under the
    condition that the injected traffic does not exceed the capacity
    of the forward data path.  The value of such intervals MUST be
    reported.
 o  The accuracy of RRFD is also dependent on the time needed to
    propagate the error-free signal from the ingress node to the
    egress node.  A typical value for 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  The accuracy of this metric is also dependent on the physical-
    layer serialization/deserialization of the test signal for certain
    data path technologies.  For instance, for an LSP between a pair

Sun, et al. Standards Track [Page 8] RFC 6777 LSP Data Path Delay Metrics November 2012

    of low-speed Ethernet interfaces, the time needed to serialize/
    deserialize a large frame may not be negligible.  In this case, it
    is RECOMMENDED that the ingress node use small frames.  The
    average length of the frame MAY be reported.
 o  It is possible that under some implementations, a node may program
    the cross-connection before it sends a PATH message further
    downstream, and the data path may be ready for use before a Resv
    message reaches the ingress node.  In such cases, RRFD can be a
    negative value.  It is RECOMMENDED that a PRFD measurement be
    carried out to further characterize the forward data path delay
    when a negative RRFD value is observed.
 o  If an error-free signal is received by the egress node before a
    PATH message is sent on the ingress node, an error MUST be
    reported and the measurement SHOULD terminate.
 o  If the corresponding Resv message is received but no error-free
    signal is received by the egress node within a reasonable period
    of time, i.e., a threshold, RRFD MUST be treated as undefined.
    The value of the threshold MUST be reported.
 o  If the LSP setup fails, this metric value MUST NOT be counted.

5.7. Methodologies

 Generally, the methodology would proceed as follows:
 o  Make sure that the network has enough resources to set up the
    requested LSP.
 o  Start the data path measurement and/or monitoring procedures on
    the ingress node and egress node.  If an error-free signal is
    received by the egress node before a 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.
 o  Upon receiving the last bit of the corresponding Resv message,
    take the timestamp (T1) on the ingress node as soon as possible.
 o  When an error-free signal is observed on the egress node, take the
    timestamp (T2) as soon as possible.  An estimate of RRFD (T2 - T1)
    can be computed.

Sun, et al. Standards Track [Page 9] RFC 6777 LSP Data Path Delay Metrics November 2012

 o  If the corresponding Resv message arrives but no error-free signal
    is received within a reasonable period of time by the ingress
    node, RRFD is deemed to be undefined.
 o  If the LSP setup fails, RRFD is not counted.

6. A Singleton Definition for RSRD

 This part defines a metric for reverse data path delay when an LSP is
 set up.
 As described in [RFC6383], the completion of the RSVP-TE signaling
 process does not necessarily mean that the cross-connections along
 the LSP being set up are in place and ready to carry traffic.  This
 metric defines the time difference between the completion of the
 signaling process and the completion of the cross-connection
 programming along the reverse data path.  This metric MAY be used
 together with RRFD to characterize the data path delay of a
 bidirectional LSP.

6.1. Motivation

 RSRD is useful for the following reasons:
 o  For the reasons described in [RFC6383], the data path may not be
    ready for use instantly after the completion of the RSVP-TE
    signaling process.  The delay itself is part of the implementation
    performance.
 o  The completion of the signaling process may be used by application
    designers as an indication of data path connectivity.  The
    existence of this delay and the possible failure of cross-
    connection programming, if not properly treated, will result in
    data loss or application failure.  The typical value of this delay
    can thus help designers to improve the application model.

6.2. Metric Name

 RSRD = Resv Sent, Reverse Data path

6.3. Metric Parameters

 o  ID0, the ingress LSR ID
 o  ID1, the egress LSR ID
 o  T, a time when the setup is attempted

Sun, et al. Standards Track [Page 10] RFC 6777 LSP Data Path Delay Metrics November 2012

6.4. Metric Units

 The value of RSRD is either a real number of milliseconds or
 undefined.

6.5. Definition

 For a real number dT,
    RSRD from ingress node ID0 to egress node ID1 at T is dT
 means that
 o  ingress node ID0 sends a PATH message to egress node ID1,
 o  the last bit of the corresponding Resv message is sent by egress
    node ID1 at T, and
 o  an error-free signal is received by the ingress node ID0 using a
    data-plane-specific test pattern at T+dT.

6.6. Discussion

 The following issues are likely to come up in practice:
 o  The accuracy of RSRD depends on the clock resolution of both the
    ingress node and egress node.  Clock synchronization between the
    ingress node and egress node is required.
 o  The accuracy of RSRD 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
    (sometimes the tester) may use a rate-based method to verify the
    connectivity 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 in this case that the egress node use
    small intervals, under the condition that the injected traffic
    does not exceed the capacity of the reverse data path.  The value
    of the interval MUST be reported.
 o  The accuracy of RSRD is also dependent on the time needed to
    propagate the error-free signal from the egress node to the
    ingress node.  A typical value for 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.

Sun, et al. Standards Track [Page 11] RFC 6777 LSP Data Path Delay Metrics November 2012

 o  The accuracy of this metric is also dependent on the physical-
    layer serialization/deserialization of the test signal for certain
    data path technologies.  For instance, for an LSP between a pair
    of low-speed Ethernet interfaces, the time needed to serialize/
    deserialize a large frame may not be negligible.  In this case, it
    is RECOMMENDED that the egress node use small frames.  The average
    length of the frame MAY be reported.
 o  If the corresponding Resv message is sent but no error-free signal
    is received by the ingress node within a reasonable period of
    time, i.e., a threshold, RSRD MUST be treated as undefined.  The
    value of the threshold MUST be reported.
 o  If an error-free signal is received before a PATH message is sent
    on the ingress node, an error MUST be reported and the measurement
    SHOULD terminate.
 o  If the LSP setup fails, this metric value MUST NOT be counted.

6.7. Methodologies

 Generally, the methodology would proceed as follows:
 o  Make sure that the network has enough resources to set up the
    requested LSP.
 o  Start the data path measurement and/or monitoring procedures on
    the ingress node and egress node.  If an error-free signal is
    received by the ingress node before a 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.
 o  Upon sending the last bit of the corresponding Resv message, take
    the timestamp (T1) on the egress node as soon as possible.
 o  When an error-free signal is observed on the ingress node, take
    the timestamp (T2) as soon as possible.  An estimate of RSRD
    (T2 - T1) can be computed.
 o  If the LSP setup fails, RSRD is not counted.
 o  If no error-free signal is received within a reasonable period of
    time by the ingress node, RSRD is deemed to be undefined.

Sun, et al. Standards Track [Page 12] RFC 6777 LSP Data Path Delay Metrics November 2012

7. A Singleton Definition for PRFD

 This part defines a metric for forward data path delay when an LSP is
 set up.
 In an RSVP-TE implementation, when setting up an LSP, each node may
 choose to program the cross-connection before it sends a PATH message
 further downstream.  In this case, the forward data path may become
 ready for use before the signaling process completes, i.e., before
 the Resv message reaches the ingress node.  This metric can be used
 to identify such an implementation practice and give useful
 information to application designers.

7.1. Motivation

 PRFD is useful for the following reasons:
 o  PRFD can be used to identify an RSVP-TE implementation practice in
    which cross-connections are programmed before a PATH message is
    sent downstream.
 o  The value of PRFD may also help application designers to fine-tune
    their application model.

7.2. Metric Name

 PRFD = PATH Received, Forward Data path

7.3. Metric Parameters

 o  ID0, the ingress LSR ID
 o  ID1, the egress LSR ID
 o  T, a time when the setup is attempted

7.4. Metric Units

 The value of PRFD is either a real number of milliseconds or
 undefined.

Sun, et al. Standards Track [Page 13] RFC 6777 LSP Data Path Delay Metrics November 2012

7.5. Definition

 For a real number dT,
    PRFD from ingress node ID0 to egress node ID1 at T is dT
 means that
 o  ingress node ID0 sends a PATH message to egress node ID1,
 o  the last bit of the PATH message is received by egress node ID1 at
    T, and
 o  an error-free signal is received by the egress node ID1 using a
    data-plane-specific test pattern at T+dT.

7.6. Discussion

 The following issues are likely to come up in practice:
 o  The accuracy of PRFD depends on the clock resolution of the egress
    node.  Clock synchronization between the ingress node and egress
    node is not required.
 o  The accuracy of PRFD 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
    (sometimes the tester) may use a rate-based method to verify the
    connectivity 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 in this case that the ingress node
    use 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 PRFD is also dependent on the time needed to
    propagate the error-free signal from the ingress node to the
    egress node.  A typical value for 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  The accuracy of this metric is also dependent on the physical-
    layer serialization/deserialization of the test signal for certain
    data path technologies.  For instance, for an LSP between a pair

Sun, et al. Standards Track [Page 14] RFC 6777 LSP Data Path Delay Metrics November 2012

    of low-speed Ethernet interfaces, the time needed to serialize/
    deserialize a large frame may not be negligible.  In this case, it
    is RECOMMENDED that the ingress node use small frames.  The
    average length of the frame MAY be reported.
 o  If an error-free signal is received before a 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  This metric SHOULD be used together with RRFD.  It is RECOMMENDED
    that a PRFD measurement be carried out after a negative RRFD value
    has already been observed.

7.7. Methodologies

 Generally, the methodology would proceed as follows:
 o  Make sure that the network has enough resources to set up the
    requested LSP.
 o  Start the data path measurement and/or monitoring procedures on
    the ingress node and egress node.  If an error-free signal is
    received by the egress node before a 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.
 o  Upon receiving the last bit of the PATH message, take the
    timestamp (T1) on the egress node as soon as possible.
 o  When an error-free signal is observed on the egress node, take the
    timestamp (T2) as soon as possible.  An estimate of PRFD (T2 - T1)
    can be computed.
 o  If the LSP setup fails, PRFD is not counted.
 o  If no error-free signal is received within a reasonable period of
    time by the egress node, PRFD is deemed to be undefined.

Sun, et al. Standards Track [Page 15] RFC 6777 LSP Data Path Delay Metrics November 2012

8. A Singleton Definition for PSFD

 This part defines a metric for forward data path delay when an LSP is
 set up.
 As described in [RFC6383], the completion of the RSVP-TE signaling
 process does not necessarily mean that the cross-connections along
 the LSP being set up are in place and ready to carry traffic.  This
 metric defines the time difference between the point when the PATH
 message is sent by the ingress node and the completion of the cross-
 connection programming along the LSP forward data path.

8.1. Motivation

 PSFD is useful for the following reasons:
 o  For the reasons described in [RFC6383], 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 an indication of data path connectivity.  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 = PATH Sent, Forward Data path

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

 The value of PSFD is either a real number of milliseconds or
 undefined.

Sun, et al. Standards Track [Page 16] RFC 6777 LSP Data Path Delay Metrics November 2012

8.5. Definition

 For a real number dT,
    PSFD from ingress node ID0 to egress node ID1 at T is dT
 means that
 o  ingress node ID0 sends the first bit of a PATH message to egress
    node ID1 at T, and
 o  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.  Clock synchronization between the
    ingress node and egress node is required.
 o  The accuracy of PSFD 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 connectivity 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 use 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 PSFD is also dependent on the time needed to
    propagate the error-free signal from the ingress node to the
    egress node.  A typical value for 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  The accuracy of this metric is also dependent on the physical-
    layer serialization/deserialization of the test signal for certain
    data path technologies.  For instance, for an LSP between a pair

Sun, et al. Standards Track [Page 17] RFC 6777 LSP Data Path Delay Metrics November 2012

    of low-speed Ethernet interfaces, the time needed to serialize/
    deserialize a large frame may not be negligible.  In this case, it
    is RECOMMENDED that the ingress node use small frames.  The
    average length of the frame MAY be reported.
 o  If an error-free signal is received before a 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 egress node within a reasonable period
    of time, i.e., a threshold, PSFD 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 resources to set up the
    requested LSP.
 o  Start the data path measurement and/or monitoring procedures on
    the ingress node and egress node.  If an error-free signal is
    received by the egress node before a 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
    timestamp (T2) as soon as possible.  An estimate of PSFD (T2 - T1)
    can be computed.
 o  If the LSP setup fails, PSFD 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.

Sun, et al. Standards Track [Page 18] RFC 6777 LSP Data Path Delay Metrics November 2012

9. A Singleton Definition for PSRD

 This part defines a metric for reverse data path delay when an LSP is
 set up.
 This metric defines the time difference between the point when the
 ingress node sends the PATH message and 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 [RFC6383], 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 an indication of data path connectivity.  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 = PATH Sent, Reverse Data path

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

 The value of PSRD is either a real number of milliseconds or
 undefined.

Sun, et al. Standards Track [Page 19] RFC 6777 LSP Data Path Delay Metrics November 2012

9.5. Definition

 For a real number dT,
    PSRD from ingress node ID0 to egress node ID1 at T is dT
 means that
 o  ingress node ID0 sends the first bit of a PATH message to egress
    node ID1 at T, and
 o  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.  Clock synchronization between the ingress node and
    egress node is not required.
 o  The accuracy of PSRD 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 connectivity 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 use 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 PSRD is also dependent on the time needed to
    propagate the error-free signal from the egress node to the
    ingress node.  A typical value for 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  The accuracy of this metric is also dependent on the physical-
    layer serialization/deserialization of the test signal for certain
    data path technologies.  For instance, for an LSP between a pair

Sun, et al. Standards Track [Page 20] RFC 6777 LSP Data Path Delay Metrics November 2012

    of low-speed Ethernet interfaces, the time needed to serialize/
    deserialize a large frame may not be negligible.  In this case, it
    is RECOMMENDED that the egress node use small frames.  The average
    length of the frame MAY be reported.
 o  If an error-free signal is received before a 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, PSRD 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 resources to set up the
    requested LSP.
 o  Start the data path measurement and/or monitoring procedures on
    the ingress node and egress node.  If an error-free signal is
    received by the egress node before a 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 timestamp (T2) as soon as possible.  An estimate of PSRD
    (T2 - T1) can be computed.
 o  If the LSP setup fails, PSRD is not counted.
 o  If no error-free signal is received within a reasonable period of
    time by the ingress node, PSRD is deemed to be undefined.

Sun, et al. Standards Track [Page 21] RFC 6777 LSP Data Path Delay Metrics November 2012

10. A Definition for Samples of Data Path Delay

 In Sections 5, 6, 7, 8, and 9, we defined the singleton metrics of
 data path delay.  Now, we define how to get one particular sample of
 such a delay.  Sampling is done to select a particular portion of
 singleton values of the given parameters.  As 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, or PSRD.

10.2. Metric Parameters

 o  ID0, the ingress LSR ID
 o  ID1, the egress LSR ID
 o  T0, a time
 o  Tf, a time
 o  Lambda, a rate in reciprocal milliseconds
 o  Th, the LSP holding time
 o  Td, the maximum waiting time for successful LSP setup
 o  Ts, the maximum waiting time for an error-free signal

10.3. Metric Units

 A sequence of pairs; the elements of each pair are:
 o  T, a time when setup is attempted
 o  dT, either a real number of milliseconds or undefined

10.4. Definition

 Given T0, Tf, and Lambda, compute a pseudo-random Poisson process
 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
 and less than or equal to Tf are then selected.  At each of the times
 in this process, we obtain the value of a data path delay sample of
 type <X> at this time.  The value of the sample is the sequence made

Sun, et al. Standards Track [Page 22] RFC 6777 LSP Data Path Delay Metrics November 2012

 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
 said to be empty.

10.5. Discussion

 The following issues are likely to come up in practice:
 o  The parameters Lambda, Th, and Td should be carefully chosen, as
    explained in the discussions for LSP setup delay (see [RFC5814]).
 o  The parameter Ts should be carefully chosen and MUST be reported
    along with the LSP forward/reverse data path delay sample.

10.6. Methodologies

 Generally, the methodology would proceed as follows:
 o  Select specific times, using the specified Poisson arrival
    process.
 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
    process.

10.7. Typical Testing Cases

10.7.1. With No LSP in the Network

10.7.1.1. Motivation

 Data path delay with no LSP in the network is important because this
 reflects the inherent delay of a device implementation.  The minimum
 value provides an indication of the delay that will likely be
 experienced when an LSP data path is configured under light traffic
 load.

10.7.1.2. Methodologies

 Make sure that there is no LSP in the network, and proceed with the
 methodologies described in Section 10.6.

Sun, et al. Standards Track [Page 23] RFC 6777 LSP Data Path Delay Metrics November 2012

10.7.2. With a Number of LSPs in the Network

10.7.2.1. Motivation

 Data path delay with a number of LSPs in the network is important
 because it reflects the performance of an operational network with
 considerable load.  This delay may vary significantly as the number
 of existing LSPs varies.  It can be used as a scalability metric of a
 device implementation.

10.7.2.2. Methodologies

 o  Set up the required number of LSPs.
 o  Wait until the network reaches a stable state.
 o  Then proceed with the methodologies described in Section 10.6.

11. Some Statistics Definitions for Metrics to Report

 Given the samples of the performance metric, we now offer several
 statistics of these samples to report.  From these statistics, we can
 draw some useful conclusions regarding a GMPLS network.  The value of
 these metrics is either a real number of milliseconds or undefined.
 In the following discussion, we only consider the finite values.

11.1. The Minimum of the Metric

 The minimum of the metric is the minimum of all the dT values in the
 sample.  In computing this, undefined values SHOULD be treated as
 infinitely large.  Note that this means that the minimum could thus
 be undefined if all the dT values are undefined.  In addition, the
 metric minimum SHOULD be set to undefined if the sample is empty.

11.2. The Median of the Metric

 The median of the metric is the median of the dT values in the given
 sample.  In computing the median, the undefined values MUST NOT be
 included.  The median SHOULD be set to undefined if all the dT values
 are undefined, or if the sample is empty.  When the number of defined
 values in the given sample is small, the metric median may not be
 typical and SHOULD be used carefully.

11.3. The Percentile of the Metric

 The "empirical distribution function" (EDF) of a set of scalar
 measurements is a function F(x), which, for any x, gives the
 fractional proportion of the total measurements that were <= x.

Sun, et al. Standards Track [Page 24] RFC 6777 LSP Data Path Delay Metrics November 2012

 Given a percentage X, the Xth percentile of the metric means the
 smallest value of x for which F(x) >= X.  In computing the
 percentile, undefined values MUST NOT be included.
 See [RFC2330] for further details.

11.4. Failure Probability

 Given the samples of the performance metric, we now offer two
 statistics of failure events of these samples to report: Failure
 Count and Failure Ratio.  The two statistics can be applied to both
 the 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 a sample of RSRD can be used to
 calculate the reverse data path failure statistics.  Detailed
 definitions of 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, a 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
 conformant to signaling specifications and behave as normal signaling
 endpoints, it will not incur security issues other than normal LSP
 provisioning.  However, the measurement parameters must be carefully
 selected so that the measurements inject trivial amounts of
 additional traffic into the networks they measure.  If they inject
 "too much" traffic, they can skew the results of the measurement and
 in extreme cases cause congestion and denial of service.
 In the data plane, the measurement endpoint MUST use a signal that is
 consistent with what is specified in the control plane.  For example,
 in a packet switched case, the traffic injected into the data plane

Sun, et al. Standards Track [Page 25] RFC 6777 LSP Data Path Delay Metrics November 2012

 MUST NOT exceed the specified rate in the corresponding LSP setup
 request.  In a wavelength switched case, the measurement endpoint
 MUST use the specified or negotiated lambda with appropriate power.
 The security considerations pertaining to the original RSVP protocol
 [RFC2205] and its TE extensions [RFC3209] also remain relevant.

13. References

13.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
            Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
            Functional Specification", RFC 2205, September 1997.
 [RFC2679]  Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
            Delay Metric for IPPM", RFC 2679, September 1999.
 [RFC2681]  Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
            Delay Metric for IPPM", RFC 2681, September 1999.
 [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
            and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
            Tunnels", RFC 3209, December 2001.

13.2. Informative References

 [RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
            "Framework for IP Performance Metrics", RFC 2330,
            May 1998.
 [RFC4208]  Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
            "Generalized Multiprotocol Label Switching (GMPLS) User-
            Network Interface (UNI): Resource ReserVation Protocol-
            Traffic Engineering (RSVP-TE) Support for the Overlay
            Model", RFC 4208, October 2005.
 [RFC5814]  Sun, W. and G. Zhang, "Label Switched Path (LSP) Dynamic
            Provisioning Performance Metrics in Generalized MPLS
            Networks", RFC 5814, March 2010.
 [RFC6383]  Shiomoto, K. and A. Farrel, "Advice on When It Is Safe to
            Start Sending Data on Label Switched Paths Established
            Using RSVP-TE", RFC 6383, September 2011.

Sun, et al. Standards Track [Page 26] RFC 6777 LSP Data Path Delay Metrics November 2012

Appendix A. Acknowledgements

 We wish to thank Adrian Farrel, Lou Berger, and Al Morton for their
 comments and help.  We also wish to thank Klaas Wierenga and Alexey
 Melnikov for their reviews.
 This document contains ideas as well as text that have appeared in
 existing IETF documents.  The authors wish to thank G. Almes, S.
 Kalidindi, and M. Zekauskas.
 We also wish to thank Weisheng Hu, Yaohui Jin, and Wei Guo in the
 state key laboratory of advanced optical communication systems and
 networks for their valuable comments.  We also wish to thank the
 National Natural Science Foundation of China (NSFC) and the
 863 program of China for their support.

Sun, et al. Standards Track [Page 27] RFC 6777 LSP Data Path Delay Metrics November 2012

Appendix B. Contributors

 Bin Gu
 IXIA
 Oriental Kenzo Plaza 8M, 48 Dongzhimen Wai Street
 Dongcheng District
 Beijing  200240
 China
 Phone: +86 13611590766
 EMail: BGu@ixiacom.com
 Xueqin Wei
 Fiberhome Telecommunication Technology Co., Ltd.
 Wuhan
 China
 Phone: +86 13871127882
 EMail: xqwei@fiberhome.com.cn
 Tomohiro Otani
 KDDI R&D Laboratories, Inc.
 2-1-15 Ohara Kamifukuoka Saitama
 356-8502
 Japan
 Phone: +81-49-278-7357
 EMail: tm-otani@kddi.com
 Ruiquan Jing
 China Telecom Beijing Research Institute
 118 Xizhimenwai Avenue
 Beijing  100035
 China
 Phone: +86-10-58552000
 EMail: jingrq@ctbri.com.cn

Sun, et al. Standards Track [Page 28] RFC 6777 LSP Data Path Delay Metrics November 2012

Authors' Addresses

 Weiqiang Sun (editor)
 Shanghai Jiao Tong University
 800 Dongchuan Road
 Shanghai  200240
 China
 Phone: +86 21 3420 5359
 EMail: sun.weiqiang@gmail.com
 Guoying Zhang (editor)
 China Academy of Telecommunication Research, MIIT, China
 No. 52 Hua Yuan Bei Lu, Haidian District
 Beijing  100191
 China
 Phone: +86 1062300103
 EMail: zhangguoying@catr.cn
 Jianhua Gao
 Huawei Technologies Co., Ltd.
 China
 Phone: +86 755 28973237
 EMail: gjhhit@huawei.com
 Guowu Xie
 University of California, Riverside
 900 University Ave.
 Riverside, CA  92521
 USA
 Phone: +1 951 237 8825
 EMail: xieg@cs.ucr.edu
 Rajiv Papneja
 Huawei Technologies
 Santa Clara, CA  95050
 Reston, VA  20190
 USA
 EMail: rajiv.papneja@huawei.com

Sun, et al. Standards Track [Page 29]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6777.txt · Last modified: 2012/11/06 19:26 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki