RFC 7876
UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks
RFC 7876 🎀 UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks
okay bestie, let's get into this one! ✨ This is RFC 7876, a Standards Track document from the IETF, dated July 2016. It was written by S. Bryant (Independent), S. Sivabalan and S. Soni (both at Cisco Systems). It's published under ISSN 2070-1721. 💖 It doesn't obsolete anything, and it doesn't update anything either, so it's a fresh standalone spec. 🌸
Quick glossary moment: MPLS is the label-switching stuff that moves packets through core networks, and "PLDM" is Packet Loss and Delay Measurement. 🦋 So MPLS-PLDM is the protocol for measuring how many packets get lost and how long they take on MPLS paths. 🧚
Status of This Memo 💅
This is an Internet Standards Track document. It's a product of the IETF and reflects the consensus of the IETF community. It went through public review and got approved for publication by the IESG (Internet Engineering Steering Group). 🔥 If you want more on Internet Standards, check out Section 2 of RFC 7841. 🫶
The current status, any errata, and feedback instructions live at http://www.rfc-editor.org/info/rfc7876. 🌈
Copyright Notice ✨
Copyright (c) 2016 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) as they stood on the publication date. 📜 Read those carefully, because they spell out your rights and restrictions. Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in that 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 ................................................101. Introduction 🦋
So here's the deal: this doc describes how MPLS-PLDM [RFC6374] out-of-band Responses can be delivered to the querier using UDP/IP. 🌸
Why would you even want UDP? 🤔 Well, it might be required to support data-path management, like getting through firewalls, or to give you the multiplexing you need in bistatic operation. That's where the querier and the collector aren't in the same place, and the collector is gathering Response info for a bunch of responders. 💅 In a highly scaled system, some MPLS-PLDM sessions might get offloaded to one specific node inside the distributed system that makes up the Label Switching Router (LSR) as a whole. Then the Response can arrive on any interface of the LSR and has to be forwarded internally to the processor handling that particular MPLS-PLDM measurement. 🧚
Here's the tea ☕: right now, MPLS-PLDM has no mechanism to deliver the PLDM Response message to a particular node within a multi-CPU LSR. 😭 That's the gap this spec fills.
The procedure here shows how the querier asks for the MPLS-PLDM Response to be delivered over IP to a dynamic UDP port. 🎀 It makes no other changes to the protocol, so it doesn't affect the case where the Response goes over 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 👑
Here's the main idea. Unless it's configured otherwise, if a UDP Return Object (URO) is in an MPLS-PLDM Query, the responder SHOULD use the IP address and UDP port in the URO to reply to the querier. 💅 The querier MAY include multiple UROs in one MPLS-PLDM Query, which tells the responder that an identical Response SHOULD be sent to each address-port pair. 🌈 A responder MAY be designed or configured to send only a single Response. If it does, the Response MUST be sent using the parameters from the first URO in the Query packet that it's able to use (see Section 4.3). ✨
The procedures here can apply to both unidirectional and bidirectional Label Switched Paths (LSPs). 🦋 In this doc, "bidirectional LSP" covers the co-routed bidirectional LSP defined in [RFC3945], plus the associated bidirectional LSP built from a pair of unidirectional LSPs (one per direction) that are associated with each other at the LSP's ingress/egress points [RFC5654]. 🧚 These mechanisms can apply to both IP/MPLS and the MPLS Transport Profile (MPLS-TP) [RFC5654] [RFC5921]. 💜
3.1. UDP Return Object 🎀
Here's the format of the UDP Return Object (URO) 👀:
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 Type | Length={6,18} | UDP-Destination-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Type and Length fields are each 8 bits long. 🍓 The Length field tells you the size in bytes of the rest of the object, which is the address size in bytes plus 2. So if the address is IPv4, Length is 6. If it's IPv6, Length is 18. ✨ That means the Length field does double duty: it's both the TLV parsing parameter and the address family type indicator. Iconic. 👑
The UDP Return Object Type (URO Type) has a value of 131. 💖
The UDP-Destination-Port is a UDP destination port as specified in [RFC768]. 🌸
The Address is either an IPv4 or an IPv6 address. 🦋
The URO MUST NOT appear in a Response, and it MUST be ignored if it's found to be present. 🚫💅
To avoid any confusion about which address the responder should reply to, an MPLS-PLDM Query message that contains a URO MUST NOT include an RFC 6374 Return Address TLV (TLV 1). 🙈 Also, the way of building 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. 🔥
4. Theory of Operation 🧚
This document defines the UDP Return Object so the MPLS-PLDM querier can 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 to "Out-of-band Response Requested", and the URO is present, the responder SHOULD send the Response back to the querier on the specified destination UDP port at the specified destination IP address in the URO. ✨
If the URO is expected but missing from a Query message, and an MPLS-PLDM Response is requested out-of-band, the Query message MUST NOT be processed any further. If possible, an "Error - Invalid Message" ([RFC6374], Section 3.1) SHOULD be sent to the querier, and the operator SHOULD be notified via the management system (see Section 4.2 for further details). 🚨🫶
4.1. Sending an MPLS-PLDM Query 📨
When you're sending an MPLS-PLDM Query message, you follow the rules and procedures from [RFC6374] too. On top of that, 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. 💅
If the querier uses the UDP port to de-multiplex the Response for a different measurement type, there MUST be a different UDP port for each measurement type (delay, loss, and delay-loss combined). 🌈
An implementation MAY use multiple UDP ports for the same measurement type to direct the Response to the correct management process in the LSR. 🦋
4.2. Receiving an MPLS-PLDM Query Request 📥
The processing of MPLS-PLDM Query messages defined in [RFC6374] still applies in this document. 🧚 On top of that, when an MPLS-PLDM Query message arrives with the Control Code set to "Out-of-band Response Requested" and a URO present, the responder SHOULD use that IP address and UDP port to send an MPLS-PLDM Response back to the querier. 💖
If an out-of-band Response is requested but the URO is missing, the Query SHOULD be dropped for a unidirectional LSP. If the TLV is missing on a bidirectional LSP, the Control Code of the Response message SHOULD be set to 0x1C, which means "Error - Invalid Message" ([RFC6374], Section 3.1), and the Response SHOULD be sent over the reverse LSP. 🔁 Getting a malformed request like this SHOULD be reported to the operator through the management system, with normal precautions taken to prevent overloading the error-reporting system. 🚨🫶
Part 1 of 2 is done, bestie! 🎀💖 Part 2 is coming with Sections 4.3 onward, the References, and everything after. Stay tuned! 🦋✨
4.3. Sending an MPLS-PLDM Response 💌
okay so, per [RFC6374], the MPLS-PLDM Response can be sent either over 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. no exceptions, bestie 🙅♀️
When the requested return path is an IP forwarding path and this method is in use, the destination IP address and UDP port get copied straight from the URO 🎀 The source IP address and source UDP port of the Response packet are up to the responder's discretion, subject to the normal management and security considerations. 💅
Now the messy case 😭 If the querier included URO(s) for only one IP address family and a return path of that type isn't 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 isn't available, the responder MAY search the UROs for the first URO specifying a return address family it does have a path for, and use the parameters in that URO to respond. 🧚 And if the responder is designed or configured not to search for a URO it can respond to, then the operator SHOULD be informed of the error through the management system using the normal rate-limited approach. 🫶
The packet format for the MPLS-PLDM Response after the UDP header is as specified in [RFC6374]. 🌸 As shown in Figure 1, the Associated Channel Header (ACH) [RFC5586] is NOT included, lowkey because the ACH info isn't needed. The correct binding between the Query and Response messages is achieved through the UDP port and the session identifier contained in the RFC 6374 message, so it's all good 💖
+----------------------------------------------------------+
| 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 RFC 6374 |
. .
+----------------------------------------------------------+
Figure 1: Response Packet FormatIf 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]. no wiggle room there 🔥
4.4. Receiving an MPLS-PLDM Response 🧚♀️
Okay, receiving time! If the Response came in over UDP/IP and an out-of-band Response was expected, the Response message SHOULD be directed to the appropriate measurement process, picked by the destination UDP port, and processed using the corresponding measurement type procedure specified in [RFC6374]. 🎀
If the Response came in over UDP/IP and an out-of-band Response was NOT requested, that Response SHOULD be dropped 🗑️ and the event SHOULD be reported to the operator through the management system, with normal precautions taken so the error-reporting system doesn't get overloaded. 🙈
5. Congestion Considerations 🌈
This protocol MUST be run in accordance with the guidance in [RFC5405]. 🦋 As advised in Section 3.1.2 of RFC 5405, operators who want to run this protocol at rates above one packet per three seconds need to make sure that the MPLS path being monitored, and any IP path that might carry the Response, are provisioned so there's a negligible chance this protocol causes congestion. 😤
Also, if a significant number of Response packets are lost, the querier MUST reduce the sending rate to a point where there's a negligible chance this protocol is contributing to network congestion. 📉 The operator should also take precautions so Response packets don't leak out of the network domain being used and cause congestion elsewhere. 🫣 If the equipment vendor configures a default IP address, this MUST be an address known to contain the Response packet within the responder. 💜 A responder that receives a Query specifying this as a return address, and that isn't configured to expect such a return address, SHOULD notify the operator in a suitably rate-limited manner. 🔔
6. Manageability Considerations 🍓
The manageability considerations described in Section 7 of [RFC6374] apply to this specification. ✨ Additional manageability considerations are noted within the elements of procedure in this document. 📋
Nothing in this document stops you from using a configured UDP/IP return path in a deployment where configuration is preferred over signaling. 🎀 In those cases, the URO MAY be omitted from the MPLS-PLDM messages. 🙌
7. Security Considerations 🔐💀
Okay, this part is SERIOUS, so please read it 😭 The MPLS-PLDM system is NOT intended to be deployed on the public Internet. It's for well-managed private and service provider networks only. 🏢 The security considerations described in Section 8 of [RFC6374] apply to this specification, and particular attention should be paid to the last two paragraphs. Cryptographic measures may be enhanced by correctly configuring access-control lists and firewalls. 🛡️
To prevent this protocol from being used 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. 🚨 Literally don't skip this one, it's giving "DDoS in disguise" 💀
And there's no additional exposure of information to pervasive monitoring systems observing LSPs that are being monitored. 👀✨
8. IANA Considerations 📚
IANA has assigned a new optional TLV type from the "MPLS Loss/Delay Measurement TLV Object" registry, which lives in the "Generic Associated Channel (G-ACh) Parameters" registry set. 🌸 Here's the entry:
Code Description Reference
131 UDP Return [RFC7876]9. References 📖
9.1. Normative References 💜
[RFC768] 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>.
[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>.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>.Acknowledgements 🫶
Huge shoutout to Joseph Chin and Rakesh Gandhi, both with Cisco Systems, for their contributions! 👑 We also thank Loa Andersson, Eric Osborne, Mustapha Aissaoui, Jeffrey Zhang, and Ross Callon for their review comments. 💖
And we thank everyone who reviewed this text and gave 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📦 where this page comes from
- ietf: rfc7876 2016-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms