idnits 2.17.1 draft-bryant-mpls-oam-udp-return-02.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 (July 3, 2014) is 3575 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 299, but not defined Summary: 0 errors (**), 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 S. Sivabalan 4 Intended status: Standards Track S. Soni 5 Expires: January 4, 2015 Cisco Systems 6 July 3, 2014 8 MPLS Performance Measurement UDP Return Path 9 draft-bryant-mpls-oam-udp-return-02 11 Abstract 13 This document specifies the proceedure to be used by the Packet Loss 14 and Delay Measurement for MPLS Networks protocol defined in RFC6374 15 when sending and processing MPLS performance management out-of-band 16 responses for delay and loss measurements over an IP/UDP return path. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 4, 2015. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 1. Introduction 52 This document describes how Packet Loss and Delay Measurement for 53 MPLS Networks protocol (MPLS-PLDM) [RFC6374] out-of-band responses 54 can be delivered to the Querier using UDP/IP. 56 The use of UDP may be required to support data path management such 57 as passage through firewalls, or to provide the necessary 58 multiplexing needed in bistatic operation where the querier and the 59 collector are not co-located and the collector is gathering the 60 response information for a number of responders. In a highly scaled 61 system some MPLS-PLDM sessions may be off-loaded to a specific node 62 within a the distributed system that comprises the LSR as a whole. 63 In such systems the response may arrive via any interface in the LSR 64 and need to internally forwarded to the processor tasked with 65 handling the particular MPLS-PLDM measurement. Currently the MPLS- 66 PLDM protocol does not have any mechanism to deliver the PLDM 67 Response message to particular node within a multi-CPU LSR. 69 The procedure described in this specification describes how the 70 queryer requests delivery of the MPLS-PLDM response over IP to a 71 dynamic UDP port. It makes no other changes to the protocol and thus 72 does not affect the case where the reponse is delivered over a MPLS 73 Associated Channel [RFC5586]. 75 2. Requirements Language 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [RFC2119]. 81 3. Solution Overview 83 This document specifies that, unless configured otherwise, if a UDP 84 Return Object (URO) is present in a MPLS-PLDM Query, the responder 85 MUST use the IP address and UDP port in the URO to reply back to the 86 querier. Multiple UROs MAY be present in a MPLS-PLDM Query 87 indicating that an identical responses SHOULD be sent to each addess- 88 port pair. A responder MAY be designed or configured to only 89 transmit a single response, in which case the response MUST be sent 90 using the parameters specified in the first URO in the querry packet. 92 The procedures defined in this document may be applied to both 93 unidirectional tunnels and bidirectional LSPs. In this document, the 94 term bidirectional LSP includes the co-routed bidirectional LSP 95 defined in [RFC3945] and the associated bidirectional LSP that is 96 constructed from a pair of unidirectional LSPs (one for each 97 direction) that are associated with one another at the LSP's ingress/ 98 egress points [RFC5654]. The mechanisms defined in this document can 99 apply to both IP/MPLS and the MPLS Transport Profile (MPLS-TP). 101 3.1. UDP Return Object 103 [Note to reviewers - to be deleted before publication - We considered 104 a number of approaches to the design. The first was to use the 105 existing address object and a separate UDP object, but concern in the 106 WG was that there may be more than one collector that required this 107 information, and the combined size of the two objects. The next 108 approach considered by the authors was to create a new object by 109 appending a UDP port to the existing generalized address object. 110 However by noting that UDP is only likely to be sent over IP and that 111 it will be a long time before we design a third major version of IP 112 we can compress the object either by having separate IPv4 and an IPv4 113 objects, or using the address length as the discriminator. The 114 object design below uses the latter approach. The resultant combined 115 UDP port + address object is thus the same size as the original 116 address object.] 118 The format of the UDP Return Object (URO) is as follows: 120 0 1 2 3 121 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 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | URO TLV Type | Length={6,18} | UDP-Destination-Port | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 ~ Address ~ 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 The Type and Length fields are each 8 bits long, and the Length field 129 indicates the size in bytes of the remainder of the object (i.e. is 130 the size of the address in bytes plus 2). When the address is IPv4 131 the length field is thus 6 and when the address is IPv6 the length 132 field is thus 18. The length field therefore acts as both the TLV 133 parsing parameter and the address family type indicator. 135 The UDP Return Object Type (URO TLV Type) has a value of . 137 The UDP Destination Port is a UDP Destination port as specified in 138 [RFC0768]. 140 The Address is either an IPv4 or an IPv6 address. 142 The URO MUST NOT appear in a response. 144 4. Theory of Operation 146 This document defines the UDP Return Object to enable the MPLS-PLDM 147 Querier to specify the return path for the MPLS-PLDM reply using IP/ 148 UDP encapsulation. 150 When the MPLS-PLDM Response is requested out-of-band by setting 151 Control Code of the MPLS-PLDM Query to "Out-of-band Response 152 Requested", and the URO is present, the responder SHOULD send the 153 response back to Querier on the specified destination UDP port at the 154 specified destination IP address as received in the URO. 156 If the URO is expected but is not present in Query message and an 157 MPLS-PLDM Response is requested out-of-band, the Query message MUST 158 NOT be processed further. If received over a bidirectional LSP, the 159 control code of the Response message MUST be set to "Error - Missing 160 TLV" and a Response SHOULD be sent over the reverse LSP. The receipt 161 of such a mal-formed request SHOULD be notified to the operator 162 through the management system, taking the normal precautions with 163 respect to the prevention of overload of the error reporting system. 165 4.1. Missing TLV 167 The control code "Missing TLV", which is classified as an Error 168 response code, indicates that the operation failed because one or 169 more required TLV Objects was not sent in the query message. 171 4.2. Sending an MPLS-PM Query 173 When sending an MPLS-PLDM Query message, in addition to the rules and 174 procedures defined in [RFC6374]; the Control Code of the MPLS-PLDM 175 Query MUST be set to "Out-of-band Response Requested", and a URO MUST 176 be carried in the MPLS-PLDM Query message. 178 If the Querier uses the UDP port to de-multiplexing of the response 179 for different measurement type, there MUST be a different UDP port 180 for each measurement type (Delay, loss and delay-loss combined). 182 An implementation MAY use multiple UDP ports for same measurement 183 type to direct the response to the correct management process in the 184 LSR. 186 4.3. Receiving an MPLS PM Query Request 188 The processing of MPLS-PLDM query messages as defined in [RFC6374] 189 applies in this document. In addition, when an MPLS-PLDM Query 190 request is received, with the Control Code of the MPLS-PLDM Query set 191 to "Out-of-band Response Requested" with a URO present, then the 192 Responder SHOULD use that IP address and UDP port to send MPLS-PLDM 193 response back to Querier. 195 If an Out-of-band response is requested and the Address object or the 196 URO is missing, the Query SHOULD be dropped in the case of a 197 unidirectional LSP. If both these TLVs are missing on a 198 bidirectional LSP, the control code of Response message should set to 199 "Invalid Message" and the response SHOULD be sent over the reverse 200 LSP. The receipt of such a mal-formed request SHOULD be notified to 201 the operator through the management system, taking the normal 202 precautions with respect to the prevention of overload of the error 203 reporting system. 205 4.4. Sending an MPLS-PM Response 207 As specified in [RFC6374] the MPLS-PLDM Response can be sent over 208 either the reverse MPLS LSP for a bidirectional LSP or over an IP 209 path. It MUST NOT be sent other than in response to an MPLS-PLDM 210 Query message. 212 When the requested return path is an IP forwarding path and this 213 method is in use, the destination IP address and UDP port MUST be 214 copied from the URO. The source IP address and the source UDP port 215 of Response packet is left to discretion of the Responder subject to 216 the normal management and security considerations. The packet format 217 for the MPLS-PLDM response after the UDP header is as specified in 218 [RFC6374]. As shown in Figure 1 the Associate Channel Header (ACH) 219 [RFC5586] is not incuded. The information provided by the ACH is not 220 needed since the correct binding between the Querry and Response 221 messages is achieved though the UDP Port and the Session Indentifier 222 contained in the RFC6374 message. 224 +----------------------------------------------------------+ 225 | IP Header | 226 . Source Address = Responders IP Address | 227 . Destination Addess = URO.Address | 228 . Protocol = UDP . 229 . . 230 +----------------------------------------------------------+ 231 | UDP Header | 232 . Source Port = As chosen by Responder . 233 . Destination Port = URO.UDP-Destination-Port . 234 . . 235 +----------------------------------------------------------+ 236 | Message as specified in RFC6374 | 237 . . 238 +----------------------------------------------------------+ 240 Figure 1: Response packet Format 242 If the return path is an IP path, only one-way delay or one-way loss 243 measurement can be carried out. In this case timestamps 3 and 4 MUST 244 be zero as specified in [RFC6374]. 246 4.5. Receiving an MPLS-PM Response 248 If the response was received over UDP/IP and an out-of-band response 249 was expected, the Response message SHOULD be directed to the 250 appropriate measurement process as determined by the destination UDP 251 Port, and processed using the corresponding measurement type 252 procedure specified in [RFC6374]. 254 If the Response was received over UDP/IP and an out-of-band response 255 was not requested, that response should be dropped and the event 256 SHOULD be notified to the operator through the management system, 257 taking the normal precautions with respect to the prevention of 258 overload of the error reporting system. 260 5. Manageability Considerations 262 The manageability considerations described in Section 7 of [RFC6374] 263 are applicable to this specification. Additional manageability 264 considerations are noted within the elements of procedure of this 265 document. 267 Nothing in this document precludes the use of a configured UDP/IP 268 return path in a deployment in which configuration is preferred to 269 signalling. In these circumstances the URO MAY be omitted from the 270 MPLS-PLDM messages. 272 6. Security Considerations 274 The MPLS-PLDM system is not intended to be deployed on the public 275 Internet. It is intended for deployment in well manages private and 276 service provider networks. The security considerations described in 277 Section 8 of [RFC6374] are applicable to this specification and the 278 reader's attention is drawn to the last two paragraphs. 279 Cryptographic measures may be enhanced by the correct configuration 280 of access control lists and firewalls. 282 There is no additional exposure of information to pervasive 283 monitoring systems observing LSPs that are being monitored. 285 7. IANA Considerations 287 IANA is requested to assign a new Optional TLV type from MPLS Loss/ 288 Delay Measurement TLV Object Registry contained within the g-ach- 289 parameters registry set. 290 Code Description Reference 291 TBD Return UDP Port [This] 293 The TLV 131 is recommended. 295 IANA is requested to assign a new response code in the MPLS Loss/ 296 Delay Measurement Control Code Registry contained within the g-ach- 297 parameters registry set. 298 Code Description Reference 299 TBD Missing TLV [This] 301 The response code 0x1E is recommended. 303 8. Acknowledgements 305 We acknowledge the contribution of Joseph Chin and Rakesh Gandhi, 306 both with Cisco Systems. We thank Loa Andersson, Eric Osborne, 307 Mustapha Aissaoui, and Jeffrey Zhang for their review comments. 309 We thank all who have reviewed this text and provided feedback. 311 9. Normative References 313 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 314 August 1980. 316 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 317 Requirement Levels", BCP 14, RFC 2119, March 1997. 319 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 320 (GMPLS) Architecture", RFC 3945, October 2004. 322 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 323 Associated Channel", RFC 5586, June 2009. 325 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 326 and S. Ueno, "Requirements of an MPLS Transport Profile", 327 RFC 5654, September 2009. 329 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 330 Measurement for MPLS Networks", RFC 6374, September 2011. 332 Authors' Addresses 334 Stewart Bryant 335 Cisco Systems 337 Email: stbryant@cisco.com 339 Siva Sivabalan 340 Cisco Systems 342 Email: msiva@cisco.com 344 Sagar Soni 345 Cisco Systems 347 Email: sagsoni@cisco.com