| TOC |
|
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.
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 (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 (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.
1.
Introduction
1.1.
Conventions
1.2.
Abbreviations
2.
Counting Activation/Deactivation Packet Format
3.
Counting Activation Operations
3.1.
Transmitting a Counting Activation Request
3.2.
Receiving a Counting Activation Request
3.3.
Transmitting a Counting Activation Reply
3.4.
Receiving a Counting Activation Reply
4.
Counting Deactivation Operations
4.1.
Transmitting a Counting Deactivation Request
4.2.
Receiving a Counting Deactivation Request
4.3.
Transmitting a Counting Deactivation Reply
4.4.
Receiving a Counting Deactivation Reply
5.
Considerations for Control Plane
6.
IANA Considerations
7.
Security Considerations
8.
Acknowledgements
9.
References
9.1.
Normative References
9.2.
Informative References
§
Authors' Addresses
| TOC |
As defined in MPLS-TP OAM requirements [RFC5860] (Vigoureux, M., Ward, D., and M. Betts, “Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks,” May 2010.), "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] (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,” April 2010.) and [I‑D.frost‑mpls‑tp‑loss‑delay] (Frost, D. and S. Bryant, “Packet Loss and Delay Measurement for the MPLS Transport Profile,” June 2010.) 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.
| TOC |
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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
| TOC |
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
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
| TOC |
Just like other MPLS-TP OAM packets, the counting activation/deactivation packets will flow over the Generic Associated Channel (G-ACh) [RFC5586] (Bocci, M., Vigoureux, M., and S. Bryant, “MPLS Generic Associated Channel,” June 2009.) 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.
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.
- 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.
| TOC |
As specified in [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,” April 2010.), 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.
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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] (Frost, D. and S. Bryant, “Packet Loss and Delay Measurement for the MPLS Transport Profile,” June 2010.), 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.
| TOC |
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.
| TOC |
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.
| TOC |
Upon the reception of a Counting Deactivation Request, the sink MEP must inspect this message at first, and if no unexpected field or 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.
| TOC |
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.
| TOC |
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.
| TOC |
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] (Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, “RSVP-TE: Extensions to RSVP for LSP Tunnels,” December 2001.), as specified in [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,” March 2010.). 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 OAM PM Loss TLV" defined in [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,” March 2010.) can be simplified and the MEP which receives this TLV can trigger only the sink MEP function.
| TOC |
To be added in a later version of this document.
| TOC |
To be added in a later version of this document.
| TOC |
To be added in a later version of this document.
| TOC |
| TOC |
| TOC |
| [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 (TXT). |
| TOC |
| 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 |