idnits 2.17.1 draft-bryant-mpls-rfc6374-over-udp-00.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 2, 2015) is 3336 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) No issues found here. 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 G. Swallow 4 Intended status: Standards Track S. Sivabalan 5 Expires: September 3, 2015 Cisco Systems 6 March 2, 2015 8 RFC6374 over UDP 9 draft-bryant-mpls-rfc6374-over-udp-00 11 Abstract 13 In draft-bryant-mpls-synonymous-flow-labels the concept of MPLS 14 synonymous flow labels (SFL) was introduced and it was shown how they 15 could be used to support RFC6374 loss measurements. In draft-bryant- 16 mpls-sfl-control the request, lifetime management and withdrawal of 17 SFLs was described. In this memo we show how these two protocols can 18 be run over UDP to support the operation of RFC6374 in systems that 19 do not support the Generic Associated Channel Label (GAL) (RFC5586). 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 3, 2015. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 57 3. Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Querier to Responder . . . . . . . . . . . . . . . . . . 3 59 4. Manageability Considerations . . . . . . . . . . . . . . . . 4 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 63 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 66 1. Introduction 68 In draft-bryant-mpls-synonymous-flow-labels the concept of MPLS 69 synonymous flow labels (SFL) was introduced and it was shown how they 70 could be used to support RFC6374 loss measurements. In draft-bryant- 71 mpls-sfl-control the request, lifetime management and withdrawal of 72 SFLs was described. In this memo we show how these two protocols can 73 be run over UDP to support the operation of RFC6374 in systems that 74 do not support the Generic Associated Channel Label (GAL) [RFC5586]. 76 The approach is to run an Associated Channel Header directly over UDP 77 using the ACH UDP port supplemented by addressing information carried 78 in the ACH payload. This memo explains how the extension of RFC6374 79 as described in draft-bryant-mpls-synonymous-flow-labels and draft- 80 bryant-mpls-sfl-control provide the necessary information to provide 81 mapping between the RFC6374 packet carried over UDP and the MPLS 82 construct being monitored, even when the RFC6374 protocol exchange is 83 entirely out of band relative to the Label Switched Path (LSP), 84 Virtual Private Network (VPN) or Pseudowire (PW) being instrumented. 86 The key to this is the decoupling between the RFC6374 message and the 87 data plane provided through the use of synonymous flow labels (SFL) 88 as described in draft-bryant-mpls-synonymous-flow-labels. 90 Nothing in this memo prevents the use of the ACH UDP port for other 91 types of Associated Channels, but the precise method of doing so is 92 outside the scope of this text. 94 2. Requirements Language 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 98 "OPTIONAL" in this document are to be interpreted as described in 99 [RFC2119]. 101 3. Protocol Stack 103 The protocol stack is shown in Figure 1. It consists of three 104 components, the UDP header, the ACH and either an RFC6374 message or 105 an SFL Control message. 107 0 1 2 3 108 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 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Source Port | Destination Port | UDP 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Length | Checksum | UDP 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 |0 0 0 1|Version| Reserved | Channel Type | ACH 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | | 117 | RFC6374 or SFL Control Payload with SFL TLVs . 118 . . 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 Figure 1: RFC6374 over UDP Protocol Stack 123 3.1. Querier to Responder 125 The following is rather laboured, but it is necessary to demonstrate 126 that all of the required mapping information is carried. 128 Consider the direction Querier to Responder for RFC6374 Messages. 129 The following explains the identifier mapping. 131 1. Destination IP address (carried in the outer IP header (not 132 shown)). This is used to identify the targeted RFC6374 Responder 133 to the IP network. 135 2. Source IP address (carried in the outer IP header (not shown)). 136 This is used to identify the originating RFC6374 Querier to the 137 RFC6374 Responder in order for it to construct the return IP 138 packet. 140 3. UDP Source Port used by the RFC6374 Responder to direct responses 141 to the correct Query process on the RFC6374 Querier. 143 4. UDP Destination Port is used by RFC6374 Querier to direct the 144 message to the correct process on the RFC6374 Responder. 146 5. IP and UDP source and destination information are reversed in the 147 usual way in the ACH Response messages from Responder back to 148 Querier. 150 6. The RFC6374 Session Identifier used by both Querier and Responder 151 to discriminate between multiple RFC6374 sessions running 152 concurrently between the two nodes. 154 7. The SFL from the SFL TLV in the RFC6374 messages is used to 155 identify the MPLS label that is being instrumented. 157 8. The SFL Control Protocol Session identifier used by both Querier 158 and Responder to discriminate between multiple RFC6374 sessions 159 running concurrently between the two nodes and used to bind the 160 SFL control protocol session to the RFC6374 session. 162 Note that a node running the SFL control protocol allocates a unique 163 SFL in response to each SFL request, and thus there is no ambiguity 164 as to which session between which source-destination pair a 165 particular label belongs. 167 Also note that there is no restriction on the use of the same SFL by 168 many nodes since it always known which node allocated it by reference 169 to items 1..8 in the list above. 171 4. Manageability Considerations 173 This may be provided in a future version of this document. 175 5. Security Considerations 177 Great care needs to be taken to ensure that the UDP packets defined 178 in this document do not enter the network from unauthorised sources. 179 This can be achieved by careful address management and the use of 180 appropriate access control at the network's IP entry points. 182 6. IANA Considerations 184 IANA is requested to allocate a UDP port from the user port range: 186 Service Name: ACH over UDP 188 Port Number: TBD 190 Descriptiopn Transport of Associated Channel Headers over UDP 191 Reference This memo 193 7. Acknowledgements 195 TBD 197 8. Normative References 199 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 200 Requirement Levels", BCP 14, RFC 2119, March 1997. 202 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 203 Associated Channel", RFC 5586, June 2009. 205 Authors' Addresses 207 Stewart Bryant 208 Cisco Systems 210 Email: stbryant@cisco.com 212 George Swallow 213 Cisco Systems 215 Email: swallow@cisco.com 217 Siva Sivabalan 218 Cisco Systems 220 Email: msiva@cisco.com