One document matched: draft-bryant-mpls-oam-udp-return-02.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-02"
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>
<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="2014" />
<area>Routing</area>
<workgroup>MPLS</workgroup>
<keyword>MPLS</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>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.</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"></xref>
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 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.</t>
<t>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 <xref target="RFC5586"></xref>.</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, if a UDP
Return Object (URO) is present in a MPLS-PLDM Query, the responder MUST
use the IP address and UDP port in the URO to reply back to the querier.
Multiple UROs MAY be present in a MPLS-PLDM Query indicating that an
identical responses SHOULD be sent to each addess-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 querry packet.</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="UDP Return Object">
<t>[Note to reviewers - to be deleted before publication - 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 in
the WG was that there may be more than one collector that required
this information, and the combined size of the two objects. 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 by 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 an IPv4
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>The format of the UDP Return Object (URO) 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| URO TLV Type | Length={6,18} | UDP-Destination-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t></t>
<t>The Type and Length fields are each 8 bits long, and 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
<TBD>. </t>
<t>The UDP Destination Port is a UDP Destination port as specified in
<xref target="RFC0768"></xref>. </t>
<t>The Address is either an IPv4 or an IPv6 address.</t>
<t>The URO MUST NOT appear in a response.</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 IP/UDP
encapsulation.</t>
<t>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”, 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 as received in the URO.</t>
<t>If the URO is expected but 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.</t>
<section title="Missing TLV">
<t>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.</t>
</section>
<section title="Sending an MPLS-PM Query ">
<t>When sending an MPLS-PLDM Query message, in addition to the rules
and procedures defined in <xref target="RFC6374"></xref>; 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-multiplexing of 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 title="Receiving an MPLS PM Query Request ">
<t>The processing of MPLS-PLDM query messages as defined in <xref
target="RFC6374"></xref> 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 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 Address object or
the URO is missing, the Query SHOULD be dropped in the case of a
unidirectional LSP. If both these TLVs are 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.
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-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 MUST be
copied from the URO. 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 <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 achieved
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 = 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></postamble>
</figure>
<t></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-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 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 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 registry set.</t>
<figure>
<artwork><![CDATA[ Code Description Reference
TBD Return UDP Port [This]]]></artwork>
</figure>
<t>The TLV 131 is recommended.</t>
<t>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.</t>
<figure>
<artwork><![CDATA[ Code Description Reference
TBD Missing TLV [This]]]></artwork>
</figure>
<t>The response code 0x1E is recommended.</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, and Jeffrey Zhang 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'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:56:38 |