One document matched: draft-ietf-mpls-rfc6374-udp-return-path-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="no"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-mpls-rfc6374-udp-return-path-05"
ipr="trust200902">
<front>
<title abbrev="RFC6374 UDP Return Path">RFC6374 UDP Return Path</title>
<author fullname="Stewart Bryant" initials="S" surname="Bryant">
<organization>Independent</organization>
<address>
<email>stewart.bryant@gmail.com</email>
</address>
</author>
<author fullname="Siva Sivabalan" initials="S" surname="Sivabalan">
<organization>Cisco Systems</organization>
<address>
<email>msiva@cisco.com</email>
</address>
</author>
<author fullname="Sagar Soni" initials="S" surname="Soni">
<organization>Cisco Systems</organization>
<address>
<email>sagsoni@cisco.com</email>
</address>
</author>
<date year="2016"/>
<area>Routing</area>
<workgroup>MPLS</workgroup>
<keyword>MPLS</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>RFC6374 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 over an IP/UDP return path.</t>
</abstract>
</front>
<middle>
<section anchor="PS" title="Introduction">
<t>This document describes how Packet Loss and Delay Measurement for
MPLS Networks protocol (MPLS-PLDM) <xref target="RFC6374"/> out-of-band
responses can be delivered to the querier using UDP/IP.</t>
<t>The use of UDP may be required to support data path management such
as passage through 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 information for a
number of responders. In a highly scaled 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
the response may arrive via any interface in the LSR and need to be
forwarded internally 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 a
particular node within a multi-CPU LSR.</t>
<t>The procedure described in this specification describes how the
querier 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 response is delivered over a MPLS Associated
Channel <xref target="RFC5586"/>.</t>
</section>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119"/>.</t>
</section>
<section title="Solution Overview">
<t>This document specifies that, unless configured otherwise, if a UDP
Return Object (URO) is present in a 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 MPLS-PLDM Query
indicating to the responder that an identical responses SHOULD be sent
to each address-port pair. A responder MAY be designed or configured to
only transmit a single response, in which case the response MUST be sent
using the parameters specified in the first URO in the query packet that
it is able to use (see <xref target="SMPLSR"/>).</t>
<t>The procedures defined in this document may be applied to both
unidirectional and bidirectional LSPs. In this document, the term
bidirectional LSP includes the co-routed bidirectional LSP defined in
<xref target="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
<xref target="RFC5654"/>. The mechanisms defined in this document can
apply to both IP/MPLS and to the MPLS Transport Profile (MPLS-TP)<xref
target="RFC5654"/>, <xref target="RFC5921"/></t>
<section title="UDP Return Object">
<t>NOTE TO RFC Editor please delete the following paragraph before
publication.</t>
<t>START DELETE</t>
<t>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.</t>
<t>END DELETE</t>
<t>The format of the UDP Return Object (URO) is as follows:</t>
<figure>
<artwork>
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t/>
<t>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. is
the size of the address in bytes plus 2). When the address is IPv4 the
length field is thus 6 and when the address is IPv6 the length field
is thus 18. The length field therefore acts as both the TLV parsing
parameter and the address family type indicator.</t>
<t>The UDP Return Object Type (URO TLV Type) has a value of 131.</t>
<t>The UDP Destination Port is a UDP Destination port as specified in
<xref target="RFC0768"/>.</t>
<t>The Address is either an IPv4 or an IPv6 address.</t>
<t>The URO MUST NOT appear in a response and MUST be ignored if it is
found to be present.</t>
<t>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 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 MUST NOT be used to construct a
Response to a Query message that contains a URO.</t>
</section>
</section>
<section title="Theory of Operation">
<t>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.</t>
<t>When the MPLS-PLDM Response is requested out-of-band by setting the
Control Code of the MPLS-PLDM query to "Out-of-band Response
Requested", and the URO is present, the responder SHOULD send the
response back to querier on the specified destination UDP port at the
specified destination IP address contained in the URO.</t>
<t>If the URO is expected but is not present in a query message and an
MPLS-PLDM Response is requested out-of-band, the query message MUST NOT
be processed further, and if possible an “Error - Invalid
Message” (<xref target="RFC6374"/> Section 3.1) SHOULD be send to
the querier and the operator notified via the management system (see
<xref target="RxMPLSPMQR"/> for further details.</t>
<section title="Sending an MPLS-PLDM Query ">
<t>When sending an MPLS-PLDM query message, in addition to the rules
and procedures defined in <xref target="RFC6374"/>; the Control Code
of the MPLS-PLDM query MUST be set to "Out-of-band Response
Requested", and a URO MUST be carried in the MPLS-PLDM query
message.</t>
<t>If the querier uses the UDP port to de-multiplex the response for
different measurement type, there MUST be a different UDP port for
each measurement type (Delay, loss and delay-loss combined).</t>
<t>An implementation MAY use multiple UDP ports for same measurement
type to direct the response to the correct management process in the
LSR.</t>
</section>
<section anchor="RxMPLSPMQR"
title="Receiving an MPLS PLDM Query Request ">
<t>The processing of MPLS-PLDM query messages as defined in <xref
target="RFC6374"/> applies in this document. In addition, when an
MPLS-PLDM query message is received, with the control code of the
MPLS-PLDM 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 back to querier.</t>
<t>If an Out-of-band response is requested and the URO is missing, the
query SHOULD be dropped in the case of a unidirectional LSP. If the
TLV is missing on a bidirectional LSP, the control code of the
Response message SHOULD set to 0x1C indicating “Error - Invalid
Message” (<xref target="RFC6374"/> Section 3.1) and the 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.</t>
</section>
<section anchor="SMPLSR" title="Sending an MPLS-PLDM Response">
<t>As specified in <xref target="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.</t>
<t>When the requested return path is an IP forwarding path and this
method is in use, the destination IP address and UDP port is copied
from the URO. The source IP address and the source UDP Port of the
Response packet is left to discretion of the 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 message MUST be discarded,
and the operator SHOULD be informed of the error through the
management system using the normal rate limited approach. If the
responder is configured to only respond with a single 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 approach.</t>
<t>The packet format for the MPLS-PLDM response after the UDP header
is as specified in <xref target="RFC6374"/>. As shown in <xref
target="encap"/> the Associate Channel Header (ACH) <xref
target="RFC5586"/> is not included. The information provided by the
ACH is not needed since the correct binding between the query and
response messages is achieved though the UDP Port and the session
indentifier contained in the RFC6374 message.</t>
<figure anchor="encap" title="Response packet Format">
<artwork> +----------------------------------------------------------+
| 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 |
. .
+----------------------------------------------------------+
</artwork>
<postamble/>
</figure>
<t/>
<t>If the return path is an 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].</t>
</section>
<section title="Receiving an MPLS-PLDM Response">
<t>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 <xref target="RFC6374">F</xref>.</t>
<t>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.</t>
</section>
</section>
<section title="Congestion Considerations">
<t>This protocol MUST be run in accordance the guidance provided in
<xref target="RFC5405"></xref>. As advised in section 3.2.1 of
RFC5405, 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 are
provisioned such that there is a negligible chance of this protocol
causing congestion. Additionally, if a significant number of 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 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
packet within the responder, such as the IPv4 localhost address <xref
target="RFC6890"></xref> or the IPv6 loopback address <xref
target="RFC4291"></xref>. A responder receiving a query specifying
this as a return address, and not being configured to expect such a
return address*, SHOULD notify the operator in a suitably rate limited
manner. </t>
</section>
<section title="Manageability Considerations">
<t>The manageability considerations described in Section 7 of <xref
target="RFC6374"/> are applicable to this specification. Additional
manageability considerations are noted within the elements of procedure
of this document.</t>
<t>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 URO MAY be omitted from the
MPLS-PLDM messages.</t>
</section>
<section title="Security Considerations">
<t>The MPLS-PLDM system is not intended to be deployed on the public
Internet. It is intended for deployment in well managed private and
service provider networks. The security considerations described in
Section 8 of <xref target="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.</t>
<t>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.</t>
<t>There is no additional exposure of information to pervasive
monitoring systems observing LSPs that are being monitored.</t>
</section>
<section title="IANA Considerations">
<t>IANA has made an early allocation of a new Optional TLV type from
MPLS Loss/Delay Measurement TLV Object Registry contained within the
Generic Associated Channel (G-ACh) Parameters registry set. IANA is
requested to modify the description text as shown below.</t>
<figure>
<artwork> Code Description Reference
131 UDP Return [This]</artwork>
</figure>
<t/>
</section>
<section title="Acknowledgements">
<t>We acknowledge the contribution of Joseph Chin and Rakesh Gandhi,
both with Cisco Systems. We thank Loa Andersson, Eric Osborne, Mustapha
Aissaoui, Jeffrey Zhang and Ross Callon for their review comments.</t>
<t>We thank all who have reviewed this text and provided feedback.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.6374'?>
<?rfc include='reference.RFC.3945'?>
<?rfc include='reference.RFC.5654'?>
<?rfc include='reference.RFC.5586'?>
<?rfc include='reference.RFC.0768'?>
<?rfc include='reference.RFC.5405'?>
<?rfc include='reference.RFC.6890'?>
<?rfc include='reference.RFC.4291'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.5921'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:27:13 |