wdiff rfc7876.alt-original rfc7876.txt

MPLS
Internet Engineering Task Force (IETF) S. Bryant
Internet-Draft
Request for Comments: 7876 Independent
Intended status:
Category: Standards Track S. Sivabalan
Expires: October 9, 2016
ISSN: 2070-1721 S. Soni
Cisco Systems
April 7,
July 2016

RFC6374

UDP Return Path
draft-ietf-mpls-rfc6374-udp-return-path-05 for Packet Loss and Delay Measurement for MPLS Networks

Abstract

RFC6374

RFC 6374 defines a protocol for Packet Loss and Delay Measurement for
MPLS networks (MPLS-PLDM). This document specifies the procedures to
be used when sending and processing out-of-band MPLS performance
management responses Responses over an IP/UDP UDP/IP 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 an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for a maximum publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 October 9, 2016.
http://www.rfc-editor.org/info/rfc7876.

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.

Table of Contents

1. Introduction ....................................................3
2. Requirements Language ...........................................3
3. Solution Overview ...............................................3
3.1. UDP Return Object ..........................................4
4. Theory of Operation .............................................5
4.1. Sending an MPLS-PLDM Query .................................5
4.2. Receiving an MPLS-PLDM Query Request .......................5
4.3. Sending an MPLS-PLDM Response ..............................6
4.4. Receiving an MPLS-PLDM Response ............................7
5. Congestion Considerations .......................................7
6. Manageability Considerations ....................................8
7. Security Considerations .........................................8
8. IANA Considerations .............................................8
9. References ......................................................9
9.1. Normative References .......................................9
9.2. Informative References .....................................9
Acknowledgements ..................................................10
Authors' Addresses ................................................10

1. Introduction

This document describes how Packet Loss and Delay Measurement for
MPLS Networks protocol (MPLS-PLDM) MPLS-PLDM [RFC6374] out-of-band responses Responses
can be delivered to the querier using UDP/IP.

The use of UDP may be required to support data path data-path management such
as passage through firewalls, firewalls or to provide the necessary multiplexing
needed in bistatic operation where the querier and the collector are
not co-located and the collector is gathering the
response Response
information for a number of responders. In a highly scaled
system system,
some MPLS-PLDM sessions may be off-loaded to a specific node within
the distributed system that comprises the Label Switching Router
(LSR) as a whole. In such systems systems, the response Response may arrive via any
interface in the LSR and need needs to be forwarded internally to the
processor tasked with handling the particular MPLS-PLDM measurement.
Currently
Currently, the MPLS-PLDM protocol does not have any mechanism to
deliver the PLDM Response message to a particular node within a
multi-CPU LSR.

The procedure described in this specification describes how the
querier requests delivery of the MPLS-PLDM response 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 response Response is delivered over a an MPLS
Associated Channel [RFC5586].

2. Requirements Language

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

3. Solution Overview

This document specifies that, unless configured otherwise, if a UDP
Return Object (URO) is present in a an MPLS-PLDM Query, the responder
SHOULD use the IP address and UDP port in the URO to reply back to
the querier. The querier MAY include multiple UROs in a an MPLS-PLDM
Query indicating to the responder that an identical responses Response SHOULD
be sent to each address-port pair. A responder MAY be designed or
configured to only transmit a single response, Response, in which case the
response
Response MUST be sent using the parameters specified in the first URO
in the query Query packet that it is able to use (see Section 4.3).

The procedures defined in this document may be applied to both
unidirectional and bidirectional LSPs. Label Switched Paths (LSPs). In
this document, the term
bidirectional LSP "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 to the MPLS Transport
Profile (MPLS-TP)[RFC5654],
[RFC5921] (MPLS-TP) [RFC5654] [RFC5921].

3.1. UDP Return Object

NOTE TO RFC Editor please delete the following paragraph before
publication.

START DELETE

Note to reviewers - We considered a number of approaches to the
design. The first was to use the existing address object and a
separate UDP object, but concern was expressed in the WG that there
may be more than one collector that required this information, and
the combined size of the two objects was large. The next approach
considered by the authors was to create a new object by appending a
UDP port to the existing generalized address object. However, noting
that UDP is only likely to be sent over IP and that it will be a long
time before we design a third major version of IP we can compress the
object either by having separate IPv4 and IPv6 objects, or using the
address length as the discriminator. The object design below uses
the latter approach. The resultant combined UDP port + address
object is thus the same size as the original address object.

END DELETE

The format of the UDP Return Object (URO) 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| URO TLV Type | Length={6,18} | UDP-Destination-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Type and Length fields are each 8 bits long. The Length field
indicates the size in bytes of the remainder of the object (i.e. (i.e., it
is the size of the address in bytes plus 2). When the address is IPv4
IPv4, the length Length field is thus 6 and 6; when the address is IPv6 IPv6, the length
Length field is thus 18. The length Length field therefore acts as both the
TLV parsing parameter and the address family type indicator.

The UDP Return Object Type (URO TLV Type) has a value of 131.

The UDP Destination Port UDP-Destination-Port is a UDP Destination destination port as specified in
[RFC0768].

The Address is either an IPv4 or an IPv6 address.

The URO MUST NOT appear in a response Response and MUST be ignored if it is
found to be present.

To prevent any ambiguity as to which address the responder needs to
reply to, an MPLS-PLDM Query message containing a URO MUST NOT
include an RFC6374 RFC 6374 Return Address TLV (TLV 1). Additionally, the
method of constructing the return address from the Source Address TLV
(TLV 130) described in Section 3.5.2 of RFC6374 [RFC6374] MUST NOT be used to
construct a Response to a Query message that contains a URO.

4. Theory of Operation

This document defines the UDP Return Object to enable the MPLS-PLDM
querier to specify the return path for the MPLS-PLDM reply using UDP/
IP encapsulation.

When the MPLS-PLDM Response is requested out-of-band by setting the
Control Code of the MPLS-PLDM query Query to "Out-of-band Response
Requested", and the URO is present, the responder SHOULD send the
response
Response back to querier on the specified destination UDP port at the
specified destination IP address contained in the URO.

If the URO is expected but is not present in a query Query message and an
MPLS-PLDM Response is requested out-of-band, the query Query message MUST
NOT be processed further, and if possible possible, an "Error - Invalid
Message" ([RFC6374] ([RFC6374], Section 3.1) SHOULD be send sent to the querier and
the operator notified via the management system (see Section 4.2 for
further details. details).

4.1. Sending an MPLS-PLDM Query

When sending an MPLS-PLDM query Query message, in addition to the rules and
procedures defined in [RFC6374]; [RFC6374], the Control Code of the MPLS-PLDM
query
Query MUST be set to "Out-of-band Response Requested", and a URO MUST
be carried in the MPLS-PLDM query Query message.

If the querier uses the UDP port to de-multiplex the response Response for a
different measurement type, there MUST be a different UDP port for
each measurement type (Delay, loss (delay, loss, and delay-loss combined).

An implementation MAY use multiple UDP ports for the same measurement
type to direct the response Response to the correct management process in the
LSR.

4.2. Receiving an MPLS PLDM MPLS-PLDM Query Request

The processing of MPLS-PLDM query Query messages as defined in [RFC6374]
applies in this document. In addition, when an MPLS-PLDM query Query
message is received, with the control code Control Code of the MPLS-PLDM query Query set
to "Out-of-band Response Requested" with a URO present, then the
responder SHOULD use that IP address and UDP port to send MPLS-PLDM
response an MPLS-
PLDM Response back to the querier.

If an Out-of-band response out-of-band Response is requested and the URO is missing, the
query
Query SHOULD be dropped in the case of a unidirectional LSP. If the
TLV is missing on a bidirectional LSP, the control code Control Code of the
Response message SHOULD set to 0x1C indicating "Error - Invalid
Message" ([RFC6374] ([RFC6374], Section 3.1) 3.1), and the response Response SHOULD be sent
over the reverse LSP. The receipt of such a mal-formed malformed request SHOULD
be
notified reported to the operator through the management system, taking the with
normal precautions with taken in respect to the prevention of overload of
the
error reporting error-reporting system.

4.3. Sending an MPLS-PLDM Response

As specified in [RFC6374] [RFC6374], the MPLS-PLDM Response can be sent over either
over the reverse MPLS LSP for a bidirectional LSP or over an IP path.
It MUST NOT be sent other than in response Response to an MPLS-PLDM
query 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 is are copied
from the URO. The source IP address and the source UDP Port port of the
Response packet is are left to the discretion of the responder responder, subject
to the normal management and security considerations. If the querier
has included URO(s) for only one IP address family and a return path
of that type is not available, then the query Query message MUST be
discarded, and the operator SHOULD be informed of the error through
the management system using the normal rate limited rate-limited approach. If the
responder is configured to only respond with a single response, Response, and a
path using the IP address family in the first URO is not available,
the responder MAY search the UROs for the first URO specifying a
return address family for which it does have a path and use the
parameters in that URO to respond. If the responder is designed or
configured not to search for a URO that it can respond to, then the
operator SHOULD be informed of the error through the management
system using the normal rate limited rate-limited approach.

The packet format for the MPLS-PLDM response Response after the UDP header is
as specified in [RFC6374]. As shown in Figure 1 1, the Associate Associated
Channel Header (ACH) [RFC5586] is not included. The information
provided by the ACH is not needed since the correct binding between
the query Query and response Response messages is achieved though through the UDP Port port and
the session indentifier identifier contained in the RFC6374 RFC 6374 message.

+----------------------------------------------------------+
| IP Header |
. Source Address = Responders IP Address |
. Destination Address = URO.Address |
. Protocol = UDP .
. .
+----------------------------------------------------------+
| UDP Header |
. Source Port = As chosen by Responder .
. Destination Port = URO.UDP-Destination-Port .
. .
+----------------------------------------------------------+
| Message as specified in RFC6374 RFC 6374 |
. .
+----------------------------------------------------------+

Figure 1: Response packet Packet Format

If the return path is an IP path, only one-way delay or one-way loss
measurement can be carried out. In this case case, timestamps 3 and 4
MUST be zero as specified in [RFC6374].

4.4. Receiving an MPLS-PLDM Response

If the response Response was received over UDP/IP and an out-of-band response Response
was expected, the Response message SHOULD be directed to the
appropriate measurement process as determined by the destination UDP
Port,
port and processed using the corresponding measurement type procedure
specified in F [RFC6374].

If the Response was received over UDP/IP and an out-of-band response Response
was not requested, that response Response SHOULD be dropped dropped, and the event
SHOULD be notified reported to the operator through the management system,
taking the
with normal precautions with taken in respect to the prevention of
overload of the error reporting error-reporting system.

5. Congestion Considerations

This protocol MUST be run in accordance with the guidance provided in
[RFC5405]. As advised in section 3.2.1 Section 3.1.2 of RFC5405, RFC 5405, operators that
wish to run this protocol at rates in excess of one packet per three
seconds need to ensure that the MPLS path being monitored and any IP
path that may be used to carry the response Response are provisioned such that
there is a negligible chance of this protocol causing congestion.
Additionally, if a significant number of response Response packets are lost,
the querier MUST reduce the sending rate to a point where there is a
negligible chance that this protocol is contributing to network
congestion. The operator should also take precautions that response Response
packets do not leak out of the network domain being used and cause
congestion elsewhere. If a default IP address is configured by the
equipment vendor, this MUST be an address known to contain the
response
Response packet within the responder, such as the IPv4 localhost
address [RFC6890] or the IPv6 loopback address [RFC4291]. responder. A responder receiving a query Query
specifying this as a return address, and not being configured to
expect such a return address*, address, SHOULD notify the operator in a
suitably rate limited rate-limited manner.

6. Manageability Considerations

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 in 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.
signaling. In these circumstances circumstances, the URO MAY be omitted from the
MPLS-PLDM messages.

7. Security Considerations

The MPLS-PLDM system is not intended to be deployed on the public
Internet. It is intended for deployment in well managed well-managed private and
service provider networks. The security considerations described in
Section 8 of [RFC6374] are applicable to this specification specification, and the
reader's
particular attention is drawn should be paid to the last two paragraphs.
Cryptographic measures may be enhanced by the correct configuration
of access control access-control lists and firewalls.

To prevent the use of this protocol as a reflection attack vector,
the operator should ensure that the IP address in the URO addresses a
system that is expecting to act as a receiver of PLDM responses. Responses.

There is no additional exposure of information to pervasive
monitoring systems observing LSPs that are being monitored.

8. IANA Considerations

IANA has made an early allocation of assigned a new Optional optional TLV type from
MPLS the "MPLS Loss/Delay
Measurement TLV Object Registry Object" registry contained within the
Generic "Generic
Associated Channel (G-ACh) Parameters Parameters" registry set. IANA is
requested to modify the description text as shown below. set:

Code Description Reference
131 UDP Return [This]

10. [RFC7876]

9. References

10.1.

9.1. Normative References

[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<http://www.rfc-editor.org/info/rfc768>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.

[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945,
DOI 10.17487/RFC3945, October 2004,
<http://www.rfc-editor.org/info/rfc3945>.

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>.

[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405,
DOI 10.17487/RFC5405, November 2008,
<http://www.rfc-editor.org/info/rfc5405>.

[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586,
DOI 10.17487/RFC5586, June 2009,
<http://www.rfc-editor.org/info/rfc5586>.

[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
Sprecher, N., and S. Ueno, "Requirements of an MPLS
Transport Profile", RFC 5654, DOI 10.17487/RFC5654,
September 2009, <http://www.rfc-editor.org/info/rfc5654>.

[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374,
DOI 10.17487/RFC6374, September 2011,
<http://www.rfc-editor.org/info/rfc6374>.

[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153,
RFC 6890, DOI 10.17487/RFC6890, April 2013,
<http://www.rfc-editor.org/info/rfc6890>.

10.2.

9.2. Informative References

[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
L., and L. Berger, "A Framework for MPLS in Transport
Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010,
<http://www.rfc-editor.org/info/rfc5921>.
9.

Acknowledgements

We acknowledge the contribution contributions of Joseph Chin and Rakesh Gandhi,
both with Cisco Systems. We thank Loa Andersson, Eric Osborne,
Mustapha Aissaoui, Jeffrey Zhang Zhang, and Ross Callon for their review
comments.

We thank all who have reviewed this text and provided feedback.

Authors' Addresses

Stewart Bryant
Independent

Email: stewart.bryant@gmail.com

Siva Sivabalan
Cisco Systems

Email: msiva@cisco.com

Sagar Soni
Cisco Systems

Email: sagsoni@cisco.com