Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 6374


Packet Loss and Delay Measurement for MPLS Networks

Part 3 of 3, p. 42 to 52
Prev RFC Part


prevText      Top      Up      ToC       Page 42 
5.  Implementation Disclosure Requirements

   This section summarizes the requirements placed on implementations
   for capabilities disclosure.  The purpose of these requirements is to
   ensure that end users have a clear understanding of implementation

Top      Up      ToC       Page 43 
   capabilities and characteristics that have a direct impact on how
   loss and delay measurement mechanisms function in specific
   situations.  Implementations are REQUIRED to state:

   o  METRICS: Which of the following metrics are supported: packet
      loss, packet throughput, octet loss, octet throughput, average
      loss rate, one-way delay, round-trip delay, two-way channel delay,
      packet delay variation.

   o  MP-LOCATION: The location of loss and delay measurement points
      with respect to other stages of packet processing, such as

   o  CHANNEL-TYPES: The types of channels for which LM and DM are
      supported, including LSP types, pseudowires, and sections (links).

   o  QUERY-RATE: The minimum supported query intervals for LM and DM
      sessions, both in the querier and responder roles.

   o  LOOP: Whether loopback measurement (Section 2.8) is supported.

   o  LM-TYPES: Whether direct or inferred LM is supported, and for the
      latter, which test protocols or proxy message types are supported.

   o  LM-COUNTERS: Whether 64-bit counters are supported.

   o  LM-ACCURACY: The expected measurement accuracy levels for the
      supported forms of LM, and the expected impact of exception
      conditions such as lost and misordered messages.

   o  LM-SYNC: The implementation's behavior in regard to the
      synchronization conditions discussed in Section 2.9.8.

   o  LM-SCOPE: The supported LM scopes (Sections 2.9.9 and 4.2.8).

   o  DM-ACCURACY: The expected measurement accuracy levels for the
      supported forms of DM.

   o  DM-TS-FORMATS: The supported timestamp formats and the extent of
      support for computation with and reconciliation of different

Top      Up      ToC       Page 44 
6.  Congestion Considerations

   An MPLS network may be traffic-engineered in such a way that the
   bandwidth required both for client traffic and for control,
   management, and OAM traffic is always available.  The following
   congestion considerations therefore apply only when this is not the

   The proactive generation of Loss Measurement and Delay Measurement
   messages for purposes of monitoring the performance of an MPLS
   channel naturally results in a degree of additional load placed on
   both the network and the terminal nodes of the channel.  When
   configuring such monitoring, operators should be mindful of the
   overhead involved and should choose transmit rates that do not stress
   network resources unduly; such choices must be informed by the
   deployment context.  In case of slower links or lower-speed devices,
   for example, lower Loss Measurement message rates can be chosen, up
   to the limits noted at the end of Section 2.2.

   In general, lower measurement message rates place less load on the
   network at the expense of reduced granularity.  For delay
   measurement, this reduced granularity translates to a greater
   possibility that the delay associated with a channel temporarily
   exceeds the expected threshold without detection.  For loss
   measurement, it translates to a larger gap in loss information in
   case of exceptional circumstances such as lost LM messages or
   misordered packets.

   When carrying out a sustained measurement operation such as an LM
   operation or continuous proactive DM operation, the querier SHOULD
   take note of the number of lost measurement messages (queries for
   which a response is never received) and set a corresponding
   Measurement Message Loss Threshold.  If this threshold is exceeded,
   the measurement operation SHOULD be suspended so as not to exacerbate
   the possible congestion condition.  This suspension SHOULD be
   accompanied by an appropriate notification to the user so that the
   condition can be investigated and corrected.

   From the receiver perspective, the main consideration is the
   possibility of receiving an excessive quantity of measurement
   messages.  An implementation SHOULD employ a mechanism such as rate-
   limiting to guard against the effects of this case.

7.  Manageability Considerations

   The measurement protocols described in this document are intended to
   serve as infrastructure to support a wide range of higher-level
   monitoring and diagnostic applications, from simple command-line

Top      Up      ToC       Page 45 
   diagnostic tools to comprehensive network performance monitoring and
   analysis packages.  The specific mechanisms and considerations for
   protocol configuration, initialization, and reporting thus depend on
   the nature of the application.

   In the case of on-demand diagnostics, the diagnostic application may
   provide parameters such as the measurement type, the channel, the
   query rate, and the test duration when initiating the diagnostic;
   results and exception conditions are then reported directly to the
   application.  The system may discard the statistics accumulated
   during the test after the results have been reported or retain them
   to provide a historical measurement record.

   Alternatively, measurement configuration may be supplied as part of
   the channel configuration itself in order to support continuous
   monitoring of the channel's performance characteristics.  In this
   case, the configuration will typically include quality thresholds
   depending on the service level agreement, the crossing of which will
   trigger warnings or alarms, and result reporting and exception
   notification will be integrated into the system-wide network
   management and reporting framework.

8.  Security Considerations

   This document describes procedures for the measurement of performance
   metrics over a pre-existing MPLS path (a pseudowire, LSP, or
   section).  As such, it assumes that a node involved in a measurement
   operation has previously verified the integrity of the path and the
   identity of the far end using existing MPLS mechanisms such as
   Bidirectional Forwarding Detection (BFD) [RFC5884]; tools,
   techniques, and considerations for securing MPLS paths are discussed
   in detail in [RFC5920].

   When such mechanisms are not available, and where security of the
   measurement operation is a concern, reception of Generic Associated
   Channel messages with the Channel Types specified in this document
   SHOULD be disabled.  Implementations MUST provide the ability to
   disable these protocols on a per-Channel-Type basis.

   Even when the identity of the far end has been verified, the
   measurement protocols remain vulnerable to injection and man-in-the-
   middle attacks.  The impact of such an attack would be to compromise
   the quality of performance measurements on the affected path.  An
   attacker positioned to disrupt these measurements is, however,
   capable of causing much greater damage by disrupting far more
   critical elements of the network such as the network control plane or
   user traffic flows.  At worst, a disruption of the measurement
   protocols would interfere with the monitoring of the performance

Top      Up      ToC       Page 46 
   aspects of the service level agreement associated with the path; the
   existence of such a disruption would imply that a serious breach of
   basic path integrity had already occurred.

   If desired, such attacks can be mitigated by performing basic
   validation and sanity checks, at the querier, of the counter or
   timestamp fields in received measurement response messages.  The
   minimal state associated with these protocols also limits the extent
   of measurement disruption that can be caused by a corrupt or invalid
   message to a single query/response cycle.

   Cryptographic mechanisms capable of signing or encrypting the
   contents of the measurement packets without degrading the measurement
   performance are not currently available.  In light of the preceding
   discussion, the absence of such cryptographic mechanisms does not
   raise significant security issues.

   Users concerned with the security of out-of-band responses over IP
   networks SHOULD employ suitable security mechanisms such as IPsec
   [RFC4301] to protect the integrity of the return path.

9.  IANA Considerations

   Per this document, IANA has completed the following actions:

   o  Allocation of Channel Types in the "PW Associated Channel Type"

   o  Creation of a "Measurement Timestamp Type" registry

   o  Creation of an "MPLS Loss/Delay Measurement Control Code" registry

   o  Creation of an "MPLS Loss/Delay Measurement Type-Length-Value
      (TLV) Object" registry

Top      Up      ToC       Page 47 
9.1.  Allocation of PW Associated Channel Types

   As per the IANA considerations in [RFC5586], IANA has allocated the
   following Channel Types in the "PW Associated Channel Type" registry:

   Value  Description                              TLV Follows Reference
   ------ ---------------------------------------- ----------- ---------
   0x000A MPLS Direct Loss Measurement (DLM)       No          RFC 6374
   0x000B MPLS Inferred Loss Measurement (ILM)     No          RFC 6374
   0x000C MPLS Delay Measurement (DM)              No          RFC 6374
   0x000D MPLS Direct Loss and Delay Measurement   No          RFC 6374
   0x000E MPLS Inferred Loss and Delay Measurement No          RFC 6374

9.2.  Creation of Measurement Timestamp Type Registry

   IANA has created a new "Measurement Timestamp Type" registry, with
   format and initial allocations as follows:

   Type Description                               Size in Bits Reference
   ---- ----------------------------------------- ------------ ---------
   0    Null Timestamp                            64           RFC 6374
   1    Sequence Number                           64           RFC 6374
   2    Network Time Protocol version 4 64-bit    64           RFC 6374
   3    Truncated IEEE 1588v2 PTP Timestamp       64           RFC 6374

   The range of the Type field is 0-15.

   The allocation policy for this registry is IETF Review.

9.3.  Creation of MPLS Loss/Delay Measurement Control Code Registry

   IANA has created a new "MPLS Loss/Delay Measurement Control Code"
   registry.  This registry is divided into two separate parts, one for
   Query Codes and the other for Response Codes, with formats and
   initial allocations as follows:

   Query Codes

   Code Description                    Reference
   ---- ------------------------------ ---------
   0x0  In-band Response Requested     RFC 6374
   0x1  Out-of-band Response Requested RFC 6374
   0x2  No Response Requested          RFC 6374

Top      Up      ToC       Page 48 
   Response Codes

   Code Description                         Reference
   ---- ----------------------------------- ---------
   0x0  Reserved                            RFC 6374
   0x1  Success                             RFC 6374
   0x2  Data Format Invalid                 RFC 6374
   0x3  Initialization in Progress          RFC 6374
   0x4  Data Reset Occurred                 RFC 6374
   0x5  Resource Temporarily Unavailable    RFC 6374
   0x10 Unspecified Error                   RFC 6374
   0x11 Unsupported Version                 RFC 6374
   0x12 Unsupported Control Code            RFC 6374
   0x13 Unsupported Data Format             RFC 6374
   0x14 Authentication Failure              RFC 6374
   0x15 Invalid Destination Node Identifier RFC 6374
   0x16 Connection Mismatch                 RFC 6374
   0x17 Unsupported Mandatory TLV Object    RFC 6374
   0x18 Unsupported Query Interval          RFC 6374
   0x19 Administrative Block                RFC 6374
   0x1A Resource Unavailable                RFC 6374
   0x1B Resource Released                   RFC 6374
   0x1C Invalid Message                     RFC 6374
   0x1D Protocol Error                      RFC 6374

   IANA has indicated that the values 0x0 - 0xF in the Response Code
   section are reserved for non-error response codes.

   The range of the Code field is 0 - 255.

   The allocation policy for this registry is IETF Review.

Top      Up      ToC       Page 49 
9.4.  Creation of MPLS Loss/Delay Measurement TLV Object Registry

   IANA has created a new "MPLS Loss/Delay Measurement TLV Object"
   registry, with format and initial allocations as follows:

   Type Description                       Reference
   ---- --------------------------------- ---------
   0    Padding - copy in response        RFC 6374
   1    Return Address                    RFC 6374
   2    Session Query Interval            RFC 6374
   3    Loopback Request                  RFC 6374
   127  Experimental use                  RFC 6374
   128  Padding - do not copy in response RFC 6374
   129  Destination Address               RFC 6374
   130  Source Address                    RFC 6374
   255  Experimental use                  RFC 6374

   IANA has indicated that Types 0-127 are classified as Mandatory, and
   that Types 128-255 are classified as Optional.

   The range of the Type field is 0 - 255.

   The allocation policy for this registry is IETF Review.

10.  Acknowledgments

   The authors wish to thank the many participants of the MPLS working
   group who provided detailed review and feedback on this document.
   The authors offer special thanks to Alexander Vainshtein, Loa
   Andersson, and Hiroyuki Takagi for many helpful thoughts and
   discussions, to Linda Dunbar for the idea of using LM messages for
   throughput measurement, and to Ben Niven-Jenkins, Marc Lasserre, and
   Ben Mack-Crane for their valuable comments.

11.  References

11.1.  Normative References

   [IEEE1588]  IEEE, "1588-2008 IEEE Standard for a Precision Clock
               Synchronization Protocol for Networked Measurement and
               Control Systems", March 2008.

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

Top      Up      ToC       Page 50 
   [RFC2474]   Nichols, K., Blake, S., Baker, F., and D. Black,
               "Definition of the Differentiated Services Field (DS
               Field) in the IPv4 and IPv6 Headers", RFC 2474,
               December 1998.

   [RFC3031]   Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
               Label Switching Architecture", RFC 3031, January 2001.

   [RFC3270]   Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
               P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
               Protocol Label Switching (MPLS) Support of Differentiated
               Services", RFC 3270, May 2002.

   [RFC5462]   Andersson, L. and R. Asati, "Multiprotocol Label
               Switching (MPLS) Label Stack Entry: "EXP" Field Renamed
               to "Traffic Class" Field", RFC 5462, February 2009.

   [RFC5586]   Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
               Associated Channel", RFC 5586, June 2009.

   [RFC5905]   Mills, D., Martin, J., Burbank, J., and W. Kasch,
               "Network Time Protocol Version 4: Protocol and Algorithms
               Specification", RFC 5905, June 2010.

11.2.  Informative References

   [RFC2679]   Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
               Delay Metric for IPPM", RFC 2679, September 1999.

   [RFC2680]   Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
               Packet Loss Metric for IPPM", RFC 2680, September 1999.

   [RFC2681]   Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
               Delay Metric for IPPM", RFC 2681, September 1999.

   [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.

   [RFC3260]   Grossman, D., "New Terminology and Clarifications for
               Diffserv", RFC 3260, April 2002.

   [RFC3985]   Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
               Edge (PWE3) Architecture", RFC 3985, March 2005.

   [RFC4301]   Kent, S. and K. Seo, "Security Architecture for the
               Internet Protocol", RFC 4301, December 2005.

Top      Up      ToC       Page 51 
   [RFC4656]   Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
               Zekauskas, "A One-way Active Measurement Protocol
               (OWAMP)", RFC 4656, September 2006.

   [RFC4928]   Swallow, G., Bryant, S., and L. Andersson, "Avoiding
               Equal Cost Multipath Treatment in MPLS Networks",
               BCP 128, RFC 4928, June 2007.

   [RFC5036]   Andersson, L., Minei, I., and B. Thomas, "LDP
               Specification", RFC 5036, October 2007.

   [RFC5357]   Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
               Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
               RFC 5357, October 2008.

   [RFC5481]   Morton, A. and B. Claise, "Packet Delay Variation
               Applicability Statement", RFC 5481, March 2009.

   [RFC5884]   Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
               "Bidirectional Forwarding Detection (BFD) for MPLS Label
               Switched Paths (LSPs)", RFC 5884, June 2010.

   [RFC5920]   Fang, L., "Security Framework for MPLS and GMPLS
               Networks", RFC 5920, July 2010.

   [RFC5921]   Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
               Berger, "A Framework for MPLS in Transport Networks",
               RFC 5921, July 2010.

   [RFC5960]   Frost, D., Bryant, S., and M. Bocci, "MPLS Transport
               Profile Data Plane Architecture", RFC 5960, August 2010.

   [RFC6375]   Frost, D., Ed. and S. Bryant, Ed., "A Packet Loss and
               Delay Measurement Profile for MPLS-Based Transport
               Networks", RFC 6375, September 2011.

   [Y.1731]    ITU-T Recommendation Y.1731, "OAM Functions and
               Mechanisms for Ethernet based Networks", February 2008.

Top      Up      ToC       Page 52 
Appendix A.  Default Timestamp Format Rationale

   This document initially proposed the Network Time Protocol (NTP)
   timestamp format as the mandatory default, as this is the normal
   default timestamp in IETF protocols and thus would seem the "natural"
   choice.  However, a number of considerations have led instead to the
   specification of the truncated IEEE 1588 Precision Time Protocol
   (PTP) timestamp as the default.  NTP has not gained traction in
   industry as the protocol of choice for high-quality timing
   infrastructure, whilst IEEE 1588 PTP has become the de facto time
   transfer protocol in networks that are specially engineered to
   provide high-accuracy time distribution service.  The PTP timestamp
   format is also the ITU-T format of choice for packet transport
   networks, which may rely on MPLS protocols.  Applications such as
   one-way delay measurement need the best time service available, and
   converting between the NTP and PTP timestamp formats is not a trivial
   transformation, particularly when it is required that this be done in
   real time without loss of accuracy.

   The truncated IEEE 1588 PTP format specified in this document is
   considered to provide a more than adequate wrap time and greater time
   resolution than it is expected will be needed for the operational
   lifetime of this protocol.  By truncating the timestamp at both the
   high and low order bits, the protocol achieves a worthwhile reduction
   in system resources.

Authors' Addresses

   Dan Frost
   Cisco Systems


   Stewart Bryant
   Cisco Systems