idnits 2.17.1 draft-ietf-mpls-rfc6374-udp-return-path-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 (September 25, 2014) is 3499 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 293, 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: March 29, 2015 Cisco Systems 6 September 25, 2014 8 RFC6374 UDP Return Path 9 draft-ietf-mpls-rfc6374-udp-return-path-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 March 29, 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 the distributed system that comprises the Label Switching 63 Router (LSR) as a whole. In such systems the response may arrive via 64 any interface in the LSR and need to internally forwarded to the 65 processor tasked with handling the particular MPLS-PLDM measurement. 66 Currently the MPLS-PLDM protocol does not have any mechanism to 67 deliver the PLDM Response message to particular node within a multi- 68 CPU LSR. 70 The procedure described in this specification describes how the 71 queryer requests delivery of the MPLS-PLDM response over IP to a 72 dynamic UDP port. It makes no other changes to the protocol and thus 73 does not affect the case where the reponse is delivered over a MPLS 74 Associated Channel [RFC5586]. 76 2. Requirements Language 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [RFC2119]. 82 3. Solution Overview 84 This document specifies that, unless configured otherwise, if a UDP 85 Return Object (URO) is present in a MPLS-PLDM Query, the responder 86 MUST use the IP address and UDP port in the URO to reply back to the 87 querier. Multiple UROs MAY be present in a MPLS-PLDM Query 88 indicating that an identical responses SHOULD be sent to each addess- 89 port pair. A responder MAY be designed or configured to only 90 transmit a single response, in which case the response MUST be sent 91 using the parameters specified in the first URO in the querry packet. 93 The procedures defined in this document may be applied to both 94 unidirectional and bidirectional LSPs. In this document, the term 95 bidirectional LSP includes the co-routed bidirectional LSP defined in 96 [RFC3945] and the associated bidirectional LSP that is constructed 97 from a pair of unidirectional LSPs (one for each direction) that are 98 associated with one another at the LSP's ingress/egress points 99 [RFC5654]. The mechanisms defined in this document can apply to both 100 IP/MPLS and to the MPLS Transport Profile (MPLS-TP)[RFC5654], 101 [RFC5921] 103 3.1. UDP Return Object 105 NOTE TO RFC Editor please delete the following paragraph before 106 publication. 108 START DELETE 110 Note to reviewers - We considered a number of approaches to the 111 design. The first was to use the existing address object and a 112 separate UDP object, but concern in the WG was that there may be more 113 than one collector that required this information, and the combined 114 size of the two objects. The next approach considered by the authors 115 was to create a new object by appending a UDP port to the existing 116 generalized address object. However by noting that UDP is only 117 likely to be sent over IP and that it will be a long time before we 118 design a third major version of IP we can compress the object either 119 by having separate IPv4 and an IPv4 objects, or using the address 120 length as the discriminator. The object design below uses the latter 121 approach. The resultant combined UDP port + address object is thus 122 the same size as the original address object. 124 END DELETE 126 The format of the UDP Return Object (URO) is as follows: 128 0 1 2 3 129 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 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | URO TLV Type | Length={6,18} | UDP-Destination-Port | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 ~ Address ~ 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 The Type and Length fields are each 8 bits long. The Length field 137 indicates the size in bytes of the remainder of the object (i.e. is 138 the size of the address in bytes plus 2). When the address is IPv4 139 the length field is thus 6 and when the address is IPv6 the length 140 field is thus 18. The length field therefore acts as both the TLV 141 parsing parameter and the address family type indicator. 143 The UDP Return Object Type (URO TLV Type) has a value of 131. 145 The UDP Destination Port is a UDP Destination port as specified in 146 [RFC0768]. 148 The Address is either an IPv4 or an IPv6 address. 150 The URO MUST NOT appear in a response. 152 4. Theory of Operation 154 This document defines the UDP Return Object to enable the MPLS-PLDM 155 Querier to specify the return path for the MPLS-PLDM reply using IP/ 156 UDP encapsulation. 158 When the MPLS-PLDM Response is requested out-of-band by setting the 159 Control Code of the MPLS-PLDM Query to "Out-of-band Response 160 Requested", and the URO is present, the responder SHOULD send the 161 response back to Querier on the specified destination UDP port at the 162 specified destination IP address contained in the URO. 164 If the URO is expected but is not present in a Query message and an 165 MPLS-PLDM Response is requested out-of-band, the Query message MUST 166 NOT be processed further, and if posisble an "Error - Invalid 167 Message" ([RFC6374] Section 3.1) SHOULD be send to the Querrier and 168 the operator notified via the management system (see Section 4.2 for 169 rurther details. 171 4.1. 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.2. 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 0x1C indicating "Error - Invalid Message" ([RFC6374] Section 3.1) and 200 the response SHOULD be sent over the reverse LSP. The receipt of 201 such a mal-formed request SHOULD be notified to the operator through 202 the management system, taking the normal precautions with respect to 203 the prevention of overload of the error reporting system. 205 4.3. 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.4. 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 has made an early allocation of a new Optional TLV type from 288 MPLS Loss/Delay Measurement TLV Object Registry contained within the 289 g-ach-parameters registry set. IANA is requested to modify the 290 description text as shown below. 292 Code Description Reference 293 131 UDP Return [This] 295 8. Acknowledgements 297 We acknowledge the contribution of Joseph Chin and Rakesh Gandhi, 298 both with Cisco Systems. We thank Loa Andersson, Eric Osborne, 299 Mustapha Aissaoui, and Jeffrey Zhang for their review comments. 301 We thank all who have reviewed this text and provided feedback. 303 9. References 305 9.1. Normative References 307 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 308 August 1980. 310 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 311 Requirement Levels", BCP 14, RFC 2119, March 1997. 313 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 314 (GMPLS) Architecture", RFC 3945, October 2004. 316 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 317 Associated Channel", RFC 5586, June 2009. 319 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 320 and S. Ueno, "Requirements of an MPLS Transport Profile", 321 RFC 5654, September 2009. 323 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 324 Measurement for MPLS Networks", RFC 6374, September 2011. 326 9.2. Informative References 328 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 329 Berger, "A Framework for MPLS in Transport Networks", RFC 330 5921, July 2010. 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