MPLS Working Group M. Xiao Internet-Draft J. Yang Intended status: Standards Track B. Wu Expires: January 6, 2011 ZTE Corporation July 5, 2010 Extension to Packet Loss Measurement for Counting Activation and Deactivation draft-xiao-mpls-tp-lm-counting-extension-00 Abstract Packet loss measurement for MPLS Transport Profile (MPLS-TP) PseudoWires, Label Switched Paths, and Sections, is an important Operation, Administration and Maintenance (OAM) function of the MPLS-TP. When this OAM function is performed, counting the transmitted and received packets at both the source MEP and the sink MEP needs to be activated at first. This document specifies OAM packets and protocol mechanism to facilitate the counting activation and deactivation at the sink MEP, and leave out the unnecessary management configuration at the sink MEP when the MPLS-TP connection is bidirectional or there exists an out-of-band return path. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 6, 2011. Copyright Notice Copyright (c) 2010 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 Xiao, et al. Expires January 6, 2011 [Page 1] Internet-Draft Extension to Packet Loss Measurement July 2010 (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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 2. Counting Activation/Deactivation Packet Format . . . . . . . . 4 3. Counting Activation Operations . . . . . . . . . . . . . . . . 6 3.1. Transmitting a Counting Activation Request . . . . . . . . 6 3.2. Receiving a Counting Activation Request . . . . . . . . . 6 3.3. Transmitting a Counting Activation Reply . . . . . . . . . 7 3.4. Receiving a Counting Activation Reply . . . . . . . . . . 7 4. Counting Deactivation Operations . . . . . . . . . . . . . . . 7 4.1. Transmitting a Counting Deactivation Request . . . . . . . 7 4.2. Receiving a Counting Deactivation Request . . . . . . . . 7 4.3. Transmitting a Counting Deactivation Reply . . . . . . . . 8 4.4. Receiving a Counting Deactivation Reply . . . . . . . . . 8 5. Considerations for Control Plane . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Xiao, et al. Expires January 6, 2011 [Page 2] Internet-Draft Extension to Packet Loss Measurement July 2010 1. Introduction As defined in MPLS-TP OAM requirements [RFC5860], "the MPLS-TP OAM toolset MUST provide a function to enable the quantification of packet loss ratio over a PW, LSP, or Section, this function MAY either be performed proactively or on-demand, this function SHOULD be performed between End Points of PWs, LSPs, and Sections and it SHOULD be possible to rely on user traffic to perform this functionality". To fulfill the above MPLS-TP OAM requirements with respect to packet loss measurement, the coherent general OAM procedures including configuration considerations, and specific function implementation including OAM packets format are specified in [I-D.ietf-mpls-tp-oam-framework] and [I-D.frost-mpls-tp-loss-delay] respectively. From the two documents it can be inferred that when packet loss measurement is performed, counting the transmitted and received packets at both the source MEP and the sink MEP needs to be activated at first, and furthermore the counting should rely on user traffic packets with specific configured PHB. Also note that in this context the source MEP specifies the MEP which will transmit Loss Measurement Query message and the sink MEP specifies the MEP which will reply Loss Measurement Response message. This document specifies OAM packets and protocol mechanism to facilitate the counting activation and deactivation at the sink MEP, and leave out the unnecessary management configuration at the sink MEP when the MPLS-TP connection is bidirectional or there exists an out-of-band return path. 1.1. Conventions 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 RFC 2119 [RFC2119]. 1.2. Abbreviations ACH: Associated Channel Header G-ACh: Generic Associated Channel ICC: ITU Carrier Code LM: Loss Measurement LSP: Label Switched Path MEP: Maintenance Entity Group End Point Xiao, et al. Expires January 6, 2011 [Page 3] Internet-Draft Extension to Packet Loss Measurement July 2010 MPLS-TP: MPLS Transport Profile OAM: Operations, Administration and Maintenance PHB: Per-hop Behavior PM: Performance Monitoring PW: PseudoWire RSVP-TE: Resource Reservation Protocol-Traffic Engineering TLV: Type Length Value 2. Counting Activation/Deactivation Packet Format Just like other MPLS-TP OAM packets, the counting activation/ deactivation packets will flow over the Generic Associated Channel (G-ACh) [RFC5586] of an MPLS-TP connection. The counting activation/ deactivation packets are used to perform signaling between the source MEP and the sink MEP of packet loss measurement. The format of a counting activation/deactivation packet is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | 0xHH (Packet Loss Measurement)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH TLV Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ Zero or more ACH TLVs ~ ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ Counting Activation/Deactivation Message ~ ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Counting Activation/Deactivation Packet The Version and Reserved field are always set to 0. Xiao, et al. Expires January 6, 2011 [Page 4] Internet-Draft Extension to Packet Loss Measurement July 2010 The Packet Loss Measurement Channel Type is 0xHH (to be assigned by IANA). The ACH TLVs may include (but are not limited to) the IF_ID, Global-ID, ICC, and Authentication TLVs. The format of a counting activation/deactivation message is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version|R| A/D | Control Code | Reserved | PHB | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Counting Activation/Deactivation Message Version The Version Number is currently set to 0. R flag The R flag represents the Request/Reply type. Set to 0 for a Request message; Set to 1 for a Reply message. A/D The A/D field represents the Activation/Deactivation type. Set to 0x100 for an Activation message; Set to 0x010 for a Deactivation message; other values are reserved for future use. Control Code According to the value of R flag, the Control Code is set as follow. For a Request: 0x0: Request (in-band reply requested). Indicates that this request has been sent over a bidirectional connection and the reply is expected over the same connection. Xiao, et al. Expires January 6, 2011 [Page 5] Internet-Draft Extension to Packet Loss Measurement July 2010 0x1: Request (out-of-band reply requested). Indicates that the reply is expected over an out-of-band path. For a Reply: 0x0: Success. Indicates that the operation succeeded. 0x1: Error. Indicates that the operation failed. Reserved The Reserved bits are for future use and always set to 0. PHB The PHB is set to the PHB value provisioned at the source MEP. 3. Counting Activation Operations As specified in [I-D.ietf-mpls-tp-oam-framework], before packet loss measurement is initiated, whether the operational mode is proactive monitoring or on-demand monitoring, the measurement parameters need to be provisioned at the source MEP. The provisioned measurement parameters for proactive monitoring include measurement interval and PHB value which identifies the per-hop behavior of packets with loss information, and further include measurement times for on-demand monitoring. Also note that after these packet loss measurement parameters are provisioned and this function is enabled at the source MEP, counting the transmitted and received packets with the provisioned PHB at the source MEP will be activated automatically. 3.1. Transmitting a Counting Activation Request After initiating a packet loss measurement operation, whether the operational mode is proactive monitoring or on-demand monitoring, the source MEP (i.e. the initiator MEP) will at first transmit a Counting Activation Request to the sink MEP (i.e. the peer MEP). This message is intended to trigger the sink MEP to start counting the transmitted and received packets with the specified PHB. 3.2. Receiving a Counting Activation Request Upon the reception of a Counting Activation Request, the sink MEP must inspect this message at first, and if no unexpected field or value is found then the sink MEP should start counting the transmitted and received packets with the received PHB, otherwise specific error should be returned at the sink MEP. Xiao, et al. Expires January 6, 2011 [Page 6] Internet-Draft Extension to Packet Loss Measurement July 2010 3.3. Transmitting a Counting Activation Reply When a Counting Activation Request is received, the sink MEP must transmit a Counting Activation Reply to the source MEP. The Control Code in Counting Activation Reply Message should be set to 0x0 to reflect the successful operation (i.e. activate counting successfully) at the sink MEP, or on the contrary set to 0x1 to reflect the failed operation (i.e. activate counting unsuccessfully) at the sink MEP. The received PHB value should be copied to the same PHB field in the Counting Activation Reply message. 3.4. Receiving a Counting Activation Reply Upon the reception of a Counting Activation Reply, the source MEP must inspect this message at first, if no unexpected field or value is found and the received Control Code indicates successful operation at the sink MEP, then the source MEP should start transmitting Loss Measurement Query to commence the procedures defined in [I-D.frost-mpls-tp-loss-delay], otherwise specific error should be returned at the source MEP. If there is no any Counting Activation Reply received after a while (such as 1 second), then specific error should be returned at the source MEP. 4. Counting Deactivation Operations As indicated above, before packet loss measurement is initiated, the measurement parameters need to be provisioned at the source MEP, and after this function is enabled, counting the transmitted and received packets with the provisioned PHB at the source MEP will be activated automatically. Similarly with that after the packet loss measurement function is disabled at the source MEP, counting the transmitted and received packets with the provisioned PHB at the source MEP will be deactivated automatically. 4.1. Transmitting a Counting Deactivation Request After stopping a packet loss measurement operation, the source MEP (i.e. the initiator MEP) will stop transmitting Loss Measurement Query, and then transmit a Counting Deactivation Request to the sink MEP (i.e. the peer MEP). This message is intended to trigger the sink MEP to stop counting the transmitted and received packets with the specified PHB. 4.2. Receiving a Counting Deactivation Request Upon the reception of a Counting Deactivation Request, the sink MEP must inspect this message at first, and if no unexpected field or Xiao, et al. Expires January 6, 2011 [Page 7] Internet-Draft Extension to Packet Loss Measurement July 2010 value is found then the sink MEP should stop counting the transmitted and received packets with the received PHB, otherwise specific error should be returned at the sink MEP. 4.3. Transmitting a Counting Deactivation Reply When a Counting Deactivation Request is received, the sink MEP must transmit a Counting Deactivation Reply to the source MEP. The Control Code in Counting Deactivation Reply Message should be set to 0x0 to reflect the successful operation (i.e. deactivate counting successfully) at the sink MEP, or on the contrary set to 0x1 to reflect the failed operation (i.e. deactivate counting unsuccessfully) at the sink MEP. The received PHB value should be copied to the same PHB field in the Counting Deactivation Reply message. 4.4. Receiving a Counting Deactivation Reply Upon the reception of a Counting Deactivation Reply, the source MEP must inspect this message at first, if no unexpected field or value is found and the received Control Code indicates successful operation at the sink MEP, then there is no action at the source MEP, otherwise specific error should be returned at the source MEP. If there is no any Counting Deactivation Reply received after a while (such as 1 second), then specific error should be returned at the source MEP. 5. Considerations for Control Plane When the packet loss measurement is employed in operational mode of proactive monitoring, the configured measurement parameters can be transferred from the source MEP to the sink MEP through the control plane by extending RSVP-TE [RFC3209], as specified in [I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext]. But in that draft, the sink MEP of one LM session is configured as a source MEP of another LM session, with all the same parameters such as measurement interval and PHB value. Actually there is another option which will distinguish the sink MEP function from the source MEP function when configuring proactive packet loss measurement at an MEP, which means that at the sink MEP only the function of counting the transmitted and received packets with specified PHB will be activated, in other words the sink MEP won't act as a source MEP of another LM session and won't transmit LM message initiatively. The option dictated above help to increase operation flexibility when performing proactive packet loss measurement, and decrease the bandwidth taken up by OAM messages due to that in this case only one LM session is needed. If this option is adopted when configuring parameters of proactive packet loss measurement by control plane, then the "MPLS Xiao, et al. Expires January 6, 2011 [Page 8] Internet-Draft Extension to Packet Loss Measurement July 2010 OAM PM Loss TLV" defined in [I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext] can be simplified and the MEP which receives this TLV can trigger only the sink MEP function. 6. IANA Considerations To be added in a later version of this document. 7. Security Considerations To be added in a later version of this document. 8. Acknowledgements To be added in a later version of this document. 9. References 9.1. Normative References [I-D.frost-mpls-tp-loss-delay] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for the MPLS Transport Profile", draft-frost-mpls-tp-loss-delay-02 (work in progress), June 2010. [I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext] Bellagamba, E., Andersson, L., Skoldstrom, P., and D. Ward, "Configuration of pro-active MPLS-TP Operations, Administration, and Maintenance (OAM) Functions Using RSVP-TE or LSP Ping", draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-01 (work in progress), March 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009. Xiao, et al. Expires January 6, 2011 [Page 9] Internet-Draft Extension to Packet Loss Measurement July 2010 [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010. 9.2. Informative References [I-D.ietf-mpls-tp-oam-framework] Allan, D., Busi, I., Niven-Jenkins, B., Fulignoli, A., Hernandez-Valencia, E., Levrau, L., Mohan, D., Sestito, V., Sprecher, N., Helvoort, H., Vigoureux, M., Weingarten, Y., and R. Winter, "MPLS-TP OAM Framework", draft-ietf-mpls-tp-oam-framework-06 (work in progress), April 2010. Authors' Addresses Min Xiao ZTE Corporation Email: xiao.min2@zte.com.cn Jian Yang ZTE Corporation Email: yang_jian@zte.com.cn Bo Wu ZTE Corporation Email: wu.bo@zte.com.cn Xiao, et al. Expires January 6, 2011 [Page 10]