| MPLS | S. Bryant |
| Internet-Draft | S. Sivabalan |
| Intended status: Standards Track | S. Soni |
| Expires: November 22, 2014 | Cisco Systems |
| May 21, 2014 |
MPLS Performance Measurement UDP Return Path
draft-bryant-mpls-oam-udp-return-01
This document specifies the proceedure to be used by the Packet Loss and Delay Measurement for MPLS Networks protocol defined in RFC6374 when sending and processing MPLS performance management out-of-band responses for delay and loss measurements over an IP/UDP 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 November 22, 2014.
Copyright (c) 2014 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.
The Packet Loss and Delay Measurement for MPLS Networks protocol (MPLS-PLDM) defined in[RFC6374] does not define how an MPLS-PLDM out-of-band response delivered over IP will be transmitted to the Querier.
In a highly scaled system some MPLS-PLDM sessions may be off-loaded to a specific node within a the distributed system that comprises the LSR as a whole. In such systems the response may arrive via any interface in the LSR and need to internally forwarded to the processor tasked with handling the particular MPLS-PLDM measurement. Currently the MPLS-PLDM protocol does not have any mechanism to deliver the PLDM Response message to particular node within a multi-CPU LSR.
The procedure described in this specification describes how the queryer requests delivery of the MPLS-PLDM response over IP to a dynamic UDP port. It makes no other changes to the protocol and thus does not affect the case where the reponse is delivered over a MPLS Associated Channel [RFC5586].
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].
This document specifies that, unless configured otherwise, the Addressing Object defined in [RFC6374] SHALL be sent in MPLS-PLDM query messages to tell the responder the IP return address to be used. This document also defines Return UDP Port object which, unless configured otherwise SHALL be used to the return UDP port. The Addressing Object and the Return UDP PORT object carried in the MPLS-PLDM query message are used to specify to the Responder how to return the response message.
The procedures defined in this document may be applied to both unidirectional tunnels and Bidirectional LSPs. In this document, the term bidirectional LSP includes the co-routed Bidirectional LSP defined in [RFC3945] and the associated bidirectional LSP that is constructed from a pair of unidirectional LSPs (one for each direction) that are associated with one another at the LSP's ingress/egress points [RFC5654]. The mechanisms defined in this document can apply to both IP/MPLS and the MPLS Transport Profile (MPLS-TP).
The format of the Return UDP Port Object is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP TLV Type | Length = 2 | UDP Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Return UDP Port Object TLV Type (UDP TLV Type) has a value of <TBD>.
The Return UDP Port Object MUST NOT appear in a response.
This document defines the Return UDP Port Object and uses the Addressing Object to enable the MPLS-PLDM Querier to specify the return path for the MPLS-PLDM reply using IP/UDP encapsulation.
When the MPLS-PLDM Response is requested out-of-band by setting Control Code of the MPLS-PLDM Query to "Out-of-band Response Requested”, the responder SHOULD send the response back to Querier on the specified destination UDP port at the specified destination IP address as received in the Return UDP Port Object and Return Address Object respectively.
If either the Return Address Object or Return UDP Port Object is not present in Query message and an MPLS-PLDM Response is requested out-of-band, the Query message MUST NOT be processed further. If received over a bidirectional LSP, the control code of the Response message MUST be set to “Error - Missing TLV” and a Response SHOULD be sent over the reverse LSP. The receipt of such a mal-formed request SHOULD be notified to the operator through the management system, taking the normal precautions with respect to the prevention of overload of the error reporting system.
The control code "Missing TLV", which is classified as an Error response code, indicates that the operation failed because one or more required TLV Objects was not sent in the query message.
When sending an MPLS-PLDM Query message, in addition to the rules and procedures defined in [RFC6374]; the Control Code of the MPLS-PLDM Query MUST be set to "Out-of-band Response Requested", and a “Return UDP Port TLV” along with “Return Address TLV” MUST be carried in the MPLS-PLDM Query message.
Since the Querier uses the UDP port to de-multiplex response for different measurement type, there SHOULD be a different UDP port for each measurement type (Delay, loss and delay-loss combined).
An implementation MAY use multiple UDP ports for same measurement type to direct the response to the correct management process in the LSR.
The processing of MPLS-PLDM query messages as defined in [RFC6374] applies in this document. In addition, when an MPLS-PLDM Query request is received, with the Control Code of the MPLS-PLDM Query set to "Out-of-band Response Requested" with a Return address TLV and Return UDP TLV is present, then the Responder SHOULD use that IP address and UDP port to send MPLS-PLDM response back to Querier.
If an Out-of-band response is requested and either the Return Address TLV or the Return UDP port TLV is missing, the Query SHOULD be dropped in the case of unidirectional LSP. If either of these TLVs is missing on a bidirectional LSP, the control code of Response message should set to “Invalid Message” and the response SHOULD be sent over the reverse LSP. In either case the receipt of such a mal-formed request SHOULD be notified to the operator through the management system, taking the normal precautions with respect to the prevention of overload of the error reporting system.
As specified in [RFC6374] the MPLS-PLDM Response can be sent over either the reverse MPLS LSP for a bidirectional LSP or over an IP path. It MUST NOT be sent other than in response to an MPLS-PLDM Query message.
When the requested return path is an IP forwarding path and this method is in use, the destination IP address and UDP port SHOULD be copied from the Return Address TLV and the Return UDP TLV respectively. The source IP address and the source UDP port of Response packet is left to discretion of the Responder subject to the normal management and security considerations. The packet format for the MPLS-PLDM response after the UDP header is as specified in [RFC6374]. As shown in Figure 1 the Associate Channel Header (ACH) [RFC5586] is not incuded. The information provided by the ACH is not needed since the correct binding between the Querry and Response messages is achieved though the UDP Port and the Session Indentifier contained in the RFC6374 message.
As noted in
+----------------------------------------------------------+
| IP Header |
. Source Address = Responders IP Address |
. Destination Addess = Return Address TLV.Address |
. Protocol = UDP .
. .
+----------------------------------------------------------+
| UDP Header |
. Source Port = As chosen by Responder .
. Destination Port = Return UDP Port TLV.UDP Dest Port .
. .
+----------------------------------------------------------+
| Message as specified in RFC6374 |
. .
+----------------------------------------------------------+
Figure 1: Response packet Format
If the return path is IP path, only one-way delay or one-way loss measurement can be carried out. In this case timestamps 3 and 4 MUST be zero as specified in [RFC6374].
If the response was received over UDP/IP and an out-of-band response was expected, the Response message SHOULD be directed to the appropriate measurement process as determined by the destination UDP Port, and processed using the corresponding measurement type procedure specified in [RFC6374].
If the Response was received over UDP/IP and an out-of-band response was not requested, that response should be dropped and the event SHOULD be notified to the operator through the management system, taking the normal precautions with respect to the prevention of overload of the error reporting system.
The manageability considerations described in Section 7 of [RFC6374] are applicable to this specification. Additional manageability considerations are noted within the elements of procedure of this document.
Nothing in this document precludes the use of a configured UDP/IP return path in a deployment in which configuration is preferred to signalling. In these circumstances the address and UDP port TLVs MAY be omitted from the MPLS-PLDM messages.
The MPLS-PLDM system is not intended to be deployed on the public Internet. It is intended for deployment in well manages private and service provider networks. The security considerations described in Section 8 of [RFC6374] are applicable to this specification and the reader's attention is drawn to the last two paragraphs. Cryptographic measures may be enhanced by the correct configuration of access control lists and firewalls.
There is no additional exposure of information to pervasive monitoring systems observing LSPs that are being monitored.
IANA is requested to assign a new Optional TLV type from MPLS Loss/Delay Measurement TLV Object Registry contained within the g-ach-parameters registry set.
Code Description Reference
TBD Return UDP Port [This]
The TLV 131 is recommended.
IANA is requested to assign a new response code in the MPLS Loss/Delay Measurement Control Code Registry contained within the g-ach-parameters registry set.
Code Description Reference
TBD Missing TLV [This]
The response code 0x1E is recommended.
We acknowledge the contribution of Joseph Chin and Rakesh Gandhi, both with Cisco Systems. We thank Loa Andersson for his review comments.
We thank all who have reviewed this text and provided feedback.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC3945] | Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. |
| [RFC5586] | Bocci, M., Vigoureux, M. and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009. |
| [RFC5654] | Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N. and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009. |
| [RFC6374] | Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, September 2011. |