Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 6374

Packet Loss and Delay Measurement for MPLS Networks

Pages: 52
Proposed Standard
Updated by:  7214
Part 3 of 3 – Pages 42 to 52
First   Prev   None

Top   ToC   RFC6374 - Page 42   prevText

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   ToC   RFC6374 - 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   ToC   RFC6374 - 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 case. 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   ToC   RFC6374 - 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   ToC   RFC6374 - 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" registry 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   ToC   RFC6374 - 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 (DLM+DM) 0x000E MPLS Inferred Loss and Delay Measurement No RFC 6374 (ILM+DM)

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 Timestamp 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   ToC   RFC6374 - 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   ToC   RFC6374 - 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   ToC   RFC6374 - 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   ToC   RFC6374 - 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   ToC   RFC6374 - 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 EMail: Stewart Bryant Cisco Systems EMail: