One document matched: draft-bryant-mpls-oam-udp-return-00.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-bryant-mpls-oam-udp-return-00"
ipr="trust200902">
<front>
<title abbrev="MPLS PM UDP Return">MPLS Performance Measurement UDP Return
Path</title>
<author fullname="Stewart Bryant" initials="S" surname="Bryant">
<organization>Cisco Systems</organization>
<address>
<email>stbryant@cisco.com</email>
</address>
</author>
<author fullname="Siva Sivabalan" initials="S" surname="Sivabalan">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>msiva@cisco.com</email>
<uri></uri>
</address>
</author>
<author fullname="Sagar Soni" initials="S" surname="Soni">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>sagsoni@cisco.com</email>
<uri></uri>
</address>
</author>
<date year="2014" />
<area>Routing</area>
<workgroup>MPLS</workgroup>
<keyword>MPLS</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document specifies an extension to the protocol for making
performance measurements of MPLS LSPs that is defined in RFC6374. It
specifies the procedure used for sending and processing MPLS performance
management out-of-band responses for delay and loss measurements over an
IP/UDP return path.</t>
</abstract>
</front>
<middle>
<section anchor="PS" title="Introduction">
<t><xref target="RFC6374"></xref> does not define how an MPLS
performance measurement (PM) out-of-band response delivered over IP will
be transmitted to the Querier.</t>
<t>In a highly scaled system some PM 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 PM measurement. Currently the MPLS PM protocol
does not have any mechanism to deliver the PM Response message to
particular node within a multi-CPU LSR. </t>
<t>The procedure described in this specification shows how to deliver
the response over a dynamic UDP port.</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"></xref>.</t>
</section>
<section title="Solution Overview">
<t>This document specifies that, unless configured otherwise, the
“Return Address TLV” defined in <xref
target="RFC6374"></xref> SHALL be used to carry the return address. It
also defines “Return UDP Port” TLV which, unless configured
otherwise SHALL be used to carry the return UDP port. The Return Address
TLV and the Return UDP PORT TLV carried in the MPLS-PM query message are
used to specify to the Responder how to return the response message.</t>
<t>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 <xref target="RFC3945"></xref> 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"></xref>. The mechanisms
defined in this document can apply to both IP/MPLS and the MPLS
Transport Profile (MPLS-TP).</t>
<section title="Return UDP Port TLV">
<t>The format of the Return UDP TLV is as follows:</t>
<figure>
<artwork><![CDATA[
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 | UDP Dest Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The UDP TLV Type has a value of <TBD>.</t>
</section>
</section>
<section title="Theory of Operation">
<t>This document defines the “Return UDP Port TLV” and uses
“Return Address TLV” that enables the MPLS-PM Querier to
specify the return path for the MPLS-PM reply using IP/UDP
encapsulation.</t>
<t>When the MPLS-PM Response is requested out-of-band by setting Control
Code of the MPLS-PM 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 TLV and “Return Address TLV”
respectively.</t>
<t>If either the “Return Address TLV” or “Return UDP
port TLV” is not present in Query Packet and MPLS PM 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
packet MUST be set to “Invalid Message” 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.</t>
<section title="Sending an MPLS-PM Query ">
<t>When sending an MPLS PM Query packet, in addition to the rules and
procedures defined in <xref target="RFC6374"></xref>; the Control Code
of the MPLS-PM 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-PM Query message.</t>
<t>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).</t>
<t>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 title="Receiving an MPLS PM Query Request ">
<t>The processing of MPLS-PM query messages as defined in <xref
target="RFC6374"></xref> applies in this document. In addition, when
an MPLS PM Query request is received, with the Control Code of the
MPLS-PM 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-PM response back to
Querier.</t>
<t>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 packet
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.</t>
</section>
<section title="Sending an MPLS-PM Response">
<t>As specified in <xref target="RFC6374"></xref> the MPLS PM Response
packet 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 PM Query Packet.</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 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 PM response after the UDP header is as specified in <xref
target="RFC6374"></xref>. As shown in <xref target="encap"></xref> the
Associate Channel Header (ACH) <xref target="RFC5586"></xref> is not
incuded. The information provided by the ACH is not needed since the
correct binding between the Querry and Response messages is achived
though the UDP Port and the Session Indentifier contained in the
RFC6374 message.</t>
<figure anchor="encap" title="Response packet Format">
<artwork><![CDATA[ +----------------------------------------------------------+
| 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 |
. .
+----------------------------------------------------------+
]]></artwork>
<postamble></postamble>
</figure>
<t></t>
<t>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].</t>
</section>
<section title="Receiving an MPLS-PM 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"></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="Manageability Considerations">
<t>The manageability considerations described in Section 7 of <xref
target="RFC6374"></xref> 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 address and UDP port TLVs MAY be
omitted from the MPLS PM messages.</t>
</section>
<section title="Security Considerations">
<t>The MPLS PM 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 <xref target="RFC6374"></xref> 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>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 is requested to assign a new Optional TLV type from MPLS
Loss/Delay Measurement TLV Object Registry contained within the
g-ach-parameters parameters registry set.</t>
<figure>
<artwork><![CDATA[ Code Description Reference
TBD Return UDP Port [This]]]></artwork>
</figure>
<t>The TLV 131 is recommended</t>
</section>
<section title="Acknowledgements">
<t>We acknowledge the contribution of Joseph Chin and Rakesh Gandhi,
both with Cisco Systems.</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'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:15:01 |