idnits 2.17.1 draft-ietf-mpls-rfc6374-udp-return-path-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 7, 2016) is 2941 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'This' is mentioned on line 341, but not defined ** Obsolete normative reference: RFC 5405 (Obsoleted by RFC 8085) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS S. Bryant 3 Internet-Draft Independent 4 Intended status: Standards Track S. Sivabalan 5 Expires: October 9, 2016 S. Soni 6 Cisco Systems 7 April 7, 2016 9 RFC6374 UDP Return Path 10 draft-ietf-mpls-rfc6374-udp-return-path-05 12 Abstract 14 RFC6374 defines a protocol for Packet Loss and Delay Measurement for 15 MPLS networks (MPLS-PLDM). This document specifies the procedures to 16 be used when sending and processing out-of-band MPLS performance 17 management responses over an IP/UDP return path. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 9, 2016. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 1. Introduction 53 This document describes how Packet Loss and Delay Measurement for 54 MPLS Networks protocol (MPLS-PLDM) [RFC6374] out-of-band responses 55 can be delivered to the querier using UDP/IP. 57 The use of UDP may be required to support data path management such 58 as passage through firewalls, or to provide the necessary 59 multiplexing needed in bistatic operation where the querier and the 60 collector are not co-located and the collector is gathering the 61 response information for a number of responders. In a highly scaled 62 system some MPLS-PLDM sessions may be off-loaded to a specific node 63 within the distributed system that comprises the Label Switching 64 Router (LSR) as a whole. In such systems the response may arrive via 65 any interface in the LSR and need to be forwarded internally to the 66 processor tasked with handling the particular MPLS-PLDM measurement. 67 Currently the MPLS-PLDM protocol does not have any mechanism to 68 deliver the PLDM Response message to a particular node within a 69 multi-CPU LSR. 71 The procedure described in this specification describes how the 72 querier requests delivery of the MPLS-PLDM response over IP to a 73 dynamic UDP port. It makes no other changes to the protocol and thus 74 does not affect the case where the response is delivered over a MPLS 75 Associated Channel [RFC5586]. 77 2. Requirements Language 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC2119]. 83 3. Solution Overview 85 This document specifies that, unless configured otherwise, if a UDP 86 Return Object (URO) is present in a MPLS-PLDM Query, the responder 87 SHOULD use the IP address and UDP port in the URO to reply back to 88 the querier. The querier MAY include multiple UROs in a MPLS-PLDM 89 Query indicating to the responder that an identical responses SHOULD 90 be sent to each address-port pair. A responder MAY be designed or 91 configured to only transmit a single response, in which case the 92 response MUST be sent using the parameters specified in the first URO 93 in the query packet that it is able to use (see Section 4.3). 95 The procedures defined in this document may be applied to both 96 unidirectional and bidirectional LSPs. In this document, the term 97 bidirectional LSP includes the co-routed bidirectional LSP defined in 98 [RFC3945] and the associated bidirectional LSP that is constructed 99 from a pair of unidirectional LSPs (one for each direction) that are 100 associated with one another at the LSP's ingress/egress points 101 [RFC5654]. The mechanisms defined in this document can apply to both 102 IP/MPLS and to the MPLS Transport Profile (MPLS-TP)[RFC5654], 103 [RFC5921] 105 3.1. UDP Return Object 107 NOTE TO RFC Editor please delete the following paragraph before 108 publication. 110 START DELETE 112 Note to reviewers - We considered a number of approaches to the 113 design. The first was to use the existing address object and a 114 separate UDP object, but concern was expressed in the WG that there 115 may be more than one collector that required this information, and 116 the combined size of the two objects was large. The next approach 117 considered by the authors was to create a new object by appending a 118 UDP port to the existing generalized address object. However, noting 119 that UDP is only likely to be sent over IP and that it will be a long 120 time before we design a third major version of IP we can compress the 121 object either by having separate IPv4 and IPv6 objects, or using the 122 address length as the discriminator. The object design below uses 123 the latter approach. The resultant combined UDP port + address 124 object is thus the same size as the original address object. 126 END DELETE 128 The format of the UDP Return Object (URO) is as follows: 130 0 1 2 3 131 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 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | URO TLV Type | Length={6,18} | UDP-Destination-Port | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 ~ Address ~ 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 The Type and Length fields are each 8 bits long. The Length field 139 indicates the size in bytes of the remainder of the object (i.e. is 140 the size of the address in bytes plus 2). When the address is IPv4 141 the length field is thus 6 and when the address is IPv6 the length 142 field is thus 18. The length field therefore acts as both the TLV 143 parsing parameter and the address family type indicator. 145 The UDP Return Object Type (URO TLV Type) has a value of 131. 147 The UDP Destination Port is a UDP Destination port as specified in 148 [RFC0768]. 150 The Address is either an IPv4 or an IPv6 address. 152 The URO MUST NOT appear in a response and MUST be ignored if it is 153 found to be present. 155 To prevent any ambiguity as to which address the responder needs to 156 reply to, an MPLS-PLDM Query message containing a URO MUST NOT 157 include an RFC6374 Return Address TLV (TLV 1). Additionally, the 158 method of constructing the return address from the Source Address TLV 159 (TLV 130) described in Section 3.5.2 of RFC6374 MUST NOT be used to 160 construct a Response to a Query message that contains a URO. 162 4. Theory of Operation 164 This document defines the UDP Return Object to enable the MPLS-PLDM 165 querier to specify the return path for the MPLS-PLDM reply using UDP/ 166 IP encapsulation. 168 When the MPLS-PLDM Response is requested out-of-band by setting the 169 Control Code of the MPLS-PLDM query to "Out-of-band Response 170 Requested", and the URO is present, the responder SHOULD send the 171 response back to querier on the specified destination UDP port at the 172 specified destination IP address contained in the URO. 174 If the URO is expected but is not present in a query message and an 175 MPLS-PLDM Response is requested out-of-band, the query message MUST 176 NOT be processed further, and if possible an "Error - Invalid 177 Message" ([RFC6374] Section 3.1) SHOULD be send to the querier and 178 the operator notified via the management system (see Section 4.2 for 179 further details. 181 4.1. Sending an MPLS-PLDM Query 183 When sending an MPLS-PLDM query message, in addition to the rules and 184 procedures defined in [RFC6374]; the Control Code of the MPLS-PLDM 185 query MUST be set to "Out-of-band Response Requested", and a URO MUST 186 be carried in the MPLS-PLDM query message. 188 If the querier uses the UDP port to de-multiplex the response for 189 different measurement type, there MUST be a different UDP port for 190 each measurement type (Delay, loss and delay-loss combined). 192 An implementation MAY use multiple UDP ports for same measurement 193 type to direct the response to the correct management process in the 194 LSR. 196 4.2. Receiving an MPLS PLDM Query Request 198 The processing of MPLS-PLDM query messages as defined in [RFC6374] 199 applies in this document. In addition, when an MPLS-PLDM query 200 message is received, with the control code of the MPLS-PLDM query set 201 to "Out-of-band Response Requested" with a URO present, then the 202 responder SHOULD use that IP address and UDP port to send MPLS-PLDM 203 response back to querier. 205 If an Out-of-band response is requested and the URO is missing, the 206 query SHOULD be dropped in the case of a unidirectional LSP. If the 207 TLV is missing on a bidirectional LSP, the control code of the 208 Response message SHOULD set to 0x1C indicating "Error - Invalid 209 Message" ([RFC6374] Section 3.1) and the response SHOULD be sent over 210 the reverse LSP. The receipt of such a mal-formed request SHOULD be 211 notified to the operator through the management system, taking the 212 normal precautions with respect to the prevention of overload of the 213 error reporting system. 215 4.3. Sending an MPLS-PLDM Response 217 As specified in [RFC6374] the MPLS-PLDM Response can be sent over 218 either the reverse MPLS LSP for a bidirectional LSP or over an IP 219 path. It MUST NOT be sent other than in response to an MPLS-PLDM 220 query message. 222 When the requested return path is an IP forwarding path and this 223 method is in use, the destination IP address and UDP port is copied 224 from the URO. The source IP address and the source UDP Port of the 225 Response packet is left to discretion of the responder subject to the 226 normal management and security considerations. If the querier has 227 included URO(s) for only one IP address family and a return path of 228 that type is not available, then the query message MUST be discarded, 229 and the operator SHOULD be informed of the error through the 230 management system using the normal rate limited approach. If the 231 responder is configured to only respond with a single response, and a 232 path using the IP address family in the first URO is not available, 233 the responder MAY search the UROs for the first URO specifying a 234 return address family for which it does have a path and use the 235 parameters in that URO to respond. If the responder is designed or 236 configured not to search for a URO that it can respond to, then the 237 operator SHOULD be informed of the error through the management 238 system using the normal rate limited approach. 240 The packet format for the MPLS-PLDM response after the UDP header is 241 as specified in [RFC6374]. As shown in Figure 1 the Associate 242 Channel Header (ACH) [RFC5586] is not included. The information 243 provided by the ACH is not needed since the correct binding between 244 the query and response messages is achieved though the UDP Port and 245 the session indentifier contained in the RFC6374 message. 247 +----------------------------------------------------------+ 248 | IP Header | 249 . Source Address = Responders IP Address | 250 . Destination Address = URO.Address | 251 . Protocol = UDP . 252 . . 253 +----------------------------------------------------------+ 254 | UDP Header | 255 . Source Port = As chosen by Responder . 256 . Destination Port = URO.UDP-Destination-Port . 257 . . 258 +----------------------------------------------------------+ 259 | Message as specified in RFC6374 | 260 . . 261 +----------------------------------------------------------+ 263 Figure 1: Response packet Format 265 If the return path is an IP path, only one-way delay or one-way loss 266 measurement can be carried out. In this case timestamps 3 and 4 MUST 267 be zero as specified in [RFC6374]. 269 4.4. Receiving an MPLS-PLDM Response 271 If the response was received over UDP/IP and an out-of-band response 272 was expected, the Response message SHOULD be directed to the 273 appropriate measurement process as determined by the destination UDP 274 Port, and processed using the corresponding measurement type 275 procedure specified in F [RFC6374]. 277 If the Response was received over UDP/IP and an out-of-band response 278 was not requested, that response SHOULD be dropped and the event 279 SHOULD be notified to the operator through the management system, 280 taking the normal precautions with respect to the prevention of 281 overload of the error reporting system. 283 5. Congestion Considerations 285 This protocol MUST be run in accordance the guidance provided in 286 [RFC5405]. As advised in section 3.2.1 of RFC5405, operators that 287 wish to run this protocol at rates in excess of one packet per three 288 seconds need to ensure that the MPLS path being monitored and any IP 289 path that may be used to carry the response are provisioned such that 290 there is a negligible chance of this protocol causing congestion. 291 Additionally, if a significant number of response packets are lost, 292 the querier MUST reduce the sending rate to a point where there is a 293 negligible chance that this protocol is contributing to network 294 congestion. The operator should also take precautions that response 295 packets do not leak out of the network domain being used and cause 296 congestion elsewhere. If a default IP address is configured by the 297 equipment vendor, this MUST be an address known to contain the 298 response packet within the responder, such as the IPv4 localhost 299 address [RFC6890] or the IPv6 loopback address [RFC4291]. A 300 responder receiving a query specifying this as a return address, and 301 not being configured to expect such a return address*, SHOULD notify 302 the operator in a suitably rate limited manner. 304 6. Manageability Considerations 306 The manageability considerations described in Section 7 of [RFC6374] 307 are applicable to this specification. Additional manageability 308 considerations are noted within the elements of procedure of this 309 document. 311 Nothing in this document precludes the use of a configured UDP/IP 312 return path in a deployment in which configuration is preferred to 313 signalling. In these circumstances the URO MAY be omitted from the 314 MPLS-PLDM messages. 316 7. Security Considerations 318 The MPLS-PLDM system is not intended to be deployed on the public 319 Internet. It is intended for deployment in well managed private and 320 service provider networks. The security considerations described in 321 Section 8 of [RFC6374] are applicable to this specification and the 322 reader's attention is drawn to the last two paragraphs. 323 Cryptographic measures may be enhanced by the correct configuration 324 of access control lists and firewalls. 326 To prevent the use of this protocol as a reflection attack vector, 327 the operator should ensure that the IP address in the URO addresses a 328 system that is expecting to act as a receiver of PLDM responses. 330 There is no additional exposure of information to pervasive 331 monitoring systems observing LSPs that are being monitored. 333 8. IANA Considerations 335 IANA has made an early allocation of a new Optional TLV type from 336 MPLS Loss/Delay Measurement TLV Object Registry contained within the 337 Generic Associated Channel (G-ACh) Parameters registry set. IANA is 338 requested to modify the description text as shown below. 340 Code Description Reference 341 131 UDP Return [This] 343 9. Acknowledgements 345 We acknowledge the contribution of Joseph Chin and Rakesh Gandhi, 346 both with Cisco Systems. We thank Loa Andersson, Eric Osborne, 347 Mustapha Aissaoui, Jeffrey Zhang and Ross Callon for their review 348 comments. 350 We thank all who have reviewed this text and provided feedback. 352 10. References 354 10.1. Normative References 356 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 357 DOI 10.17487/RFC0768, August 1980, 358 . 360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 361 Requirement Levels", BCP 14, RFC 2119, 362 DOI 10.17487/RFC2119, March 1997, 363 . 365 [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label 366 Switching (GMPLS) Architecture", RFC 3945, 367 DOI 10.17487/RFC3945, October 2004, 368 . 370 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 371 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 372 2006, . 374 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 375 for Application Designers", BCP 145, RFC 5405, 376 DOI 10.17487/RFC5405, November 2008, 377 . 379 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 380 "MPLS Generic Associated Channel", RFC 5586, 381 DOI 10.17487/RFC5586, June 2009, 382 . 384 [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., 385 Sprecher, N., and S. Ueno, "Requirements of an MPLS 386 Transport Profile", RFC 5654, DOI 10.17487/RFC5654, 387 September 2009, . 389 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 390 Measurement for MPLS Networks", RFC 6374, 391 DOI 10.17487/RFC6374, September 2011, 392 . 394 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 395 "Special-Purpose IP Address Registries", BCP 153, 396 RFC 6890, DOI 10.17487/RFC6890, April 2013, 397 . 399 10.2. Informative References 401 [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, 402 L., and L. Berger, "A Framework for MPLS in Transport 403 Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, 404 . 406 Authors' Addresses 408 Stewart Bryant 409 Independent 411 Email: stewart.bryant@gmail.com 413 Siva Sivabalan 414 Cisco Systems 416 Email: msiva@cisco.com 418 Sagar Soni 419 Cisco Systems 421 Email: sagsoni@cisco.com