idnits 2.17.1 draft-kumar-softwire-uet-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 date (February 18, 2013) is 4085 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) == Outdated reference: A later version (-08) exists of draft-ietf-6man-udpchecksums-07 ** Obsolete normative reference: RFC 5512 (Obsoleted by RFC 9012) == Outdated reference: A later version (-12) exists of draft-ietf-6man-udpzero-10 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 softwire C. Pignataro 3 Internet-Draft N. Kumar 4 Intended status: Standards Track P. Mohapatra 5 Expires: August 22, 2013 C. Filsfils 6 Cisco Systems, Inc. 7 February 18, 2013 9 UDP Entropy Tunnel for Softwire 10 draft-kumar-softwire-uet-00 12 Abstract 14 This document describes a method for encapsulatation of tunneled 15 packets within UDP in order to provide per-flow entropy for load- 16 balancing. The method is targeted for use with softwire mesh 17 deployments that include routers which have support for load- 18 balancing based on UDP ports and not fields in L2TPv3 or GRE. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 22, 2013. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 56 3. UDP Entropy Tunnel Encapsulation . . . . . . . . . . . . . . . 3 57 4. Procedure to use UDP Entropy Tunnel Encapsulation . . . . . . . 4 58 4.1. Ingress node procedure . . . . . . . . . . . . . . . . . . 5 59 4.2. Egress node procedure . . . . . . . . . . . . . . . . . . . 5 60 5. Entropy ID Sub-TLV . . . . . . . . . . . . . . . . . . . . . . 6 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 63 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 7 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 66 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 [RFC5565] explains how routing information in BGP and data packets in 72 L2TPv3 or GRE are tunneled from one edge of an IPv4 network, over 73 IPv6, to another IPv4 network or from one edge of an IPv6 network, 74 over IPv4, to another IPv6 network. [RFC5640] describes how to 75 encode and load-balance specific flows by utilizing the L2TPv3 76 Session ID or GRE Key field. While implementations and deployments 77 exist, not as many routers support the per-hop behavior described in 78 [RFC5640] compared to routers that support load-balancing based on 79 UDP ports. 81 In cases where [RFC5640] is not supported on the intervening network 82 where tunneled packets traverse and where load-balancing is 83 desirable, UDP may be used in order to encode additional entropy for 84 routers to perform more granular load-balancing. In addition to 85 entropy information for more granular load-balancing, use of the "UDP 86 Entropy Tunnel" encapsulation defined in this document allows egress 87 devices to identify additional information about the type of softwire 88 packet being carried. 90 UET encapsulation defined in this document appends Entropy ID 91 assigned and advertised by tunnel tailend node to Protocol ID and 92 encode the same as Destination port of UDP while using the source 93 port field to carry Entropy value. Each edge node is expected to 94 assign a minimum of one Entropy ID which makes the ingress node to 95 maintain one Entropy ID per egress node. 97 This document does not aim to deprecate or replace [RFC5640], but to 98 provide an alternative when there is no specific support for load- 99 balancing based on L2TPv3, GRE, or other softwire encapsulation 100 types. 102 2. Requirements notation 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 3. UDP Entropy Tunnel Encapsulation 110 This section defines the UDP Entropy Tunnel encapsulation format as 111 below: 113 0 1 2 3 114 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 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Source Port (entropy value) | E-ID | P-ID | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | UDP Length | UDP Checksum | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | | 121 ~ Softwire Tunnel (Variable) ~ 122 | | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 Source Port 126 Resulting Entropy value (using any hashing algorithm) 127 is populated in this field. 129 E-ID 130 Entropy Identifier, used to identify UDP Entropy 131 Tunnel. 133 P-ID 134 Protocol Identifier, used to identify the softwire 135 service. 137 UDP Length 138 As defined in [RFC0768] 140 UDP Checksum 141 Set to zero. 143 4. Procedure to use UDP Entropy Tunnel Encapsulation 145 Below is a sample toplogy where softwire tunnel is used to deliver 146 payload between Client network, 148 +--------+ +--------+ +--------+ +--------+ 149 | Client | | Ingress| _ _ _ _ _ | Egress | | Client | 150 | Network|====| Node |()_ _ _ _ _()| Node |====| Network| 151 +--------+ +--------+ softwire +--------+ +--------+ 153 4.1. Ingress node procedure 155 Any Ingress node on sending traffic through softwire tunnel and if no 156 Entropy ID is received from remote endpoint via BGP or other 157 encapsulation signaling protocol, MUST NOT use UDP Entropy tunnel. 159 Any Ingress node on sending traffic through softwire tunnel and if an 160 Entropy ID is received from remote endpoint via BGP or other 161 encapsulation signaling protocol, MUST encapsulate with UDP Entropy 162 tunnel as below: 164 o Generate Entropy value using any hashing algorithm and populate 165 the Source port with the value. 167 o Copy the "Entropy ID" value received from remote endpoint to E-ID 168 field. 170 o Populate the P-ID field with Softwire encapsulation protocol (e.g, 171 L2TPv3, GRE-in-IP, IP-in-IP etc.) 173 o Set the UDP checksum value as zero as described in 174 [I-D.ietf-6man-udpchecksums] and [I-D.ietf-6man-udpzero]. 176 The Ingress node further adds IP header to the above encapsulated UDP 177 based UDP Entropy tunnel header and send across the core to egress 178 node. 180 4.2. Egress node procedure 182 When any node is enabled with UDP based entropy, it assigns a locally 183 significant 8 bits Entropy ID. While any signaling protocol can be 184 used to advertise this assigned Entropy ID to other nodes, Section 5 185 of this document describes one mechanism using Tunnel Encapsulation 186 Attribute [RFC5512]. 188 At the egress node, if the E-ID (See Section 3) of the UDP packet 189 matches locally assigned Entropy ID, MUST use P-ID field (See Section 190 3) to identify the Softwire encapsulation protocol. 192 When any node receives UDP Entropy Tunnel encapsulated packet and if 193 P-ID field doesnt match any of the locally configured softwire 194 service MUST drop the packet. 196 When any node receives traffic over softwire tunnel without UDP 197 Entropy Tunnel encapsulation MUST decapsulate the softwire 198 encapsulation and process the packet further. 200 5. Entropy ID Sub-TLV 202 Any node that is enabled with UDP based entropy, MUST inlcude Entropy 203 ID Sub-TLV (Type = 6) in Tunnel Encapsulation Attribute [RFC5512]. 204 This Sub-TLV is of 4 octets length and can be used with any Tunnel 205 type proposed in [RFC5512] or any new tunnel type proposed in future. 207 The Entropy ID carried in this Sub-TLV is a 1 octet value and is 208 locally significant to the assigning edge node. While it is a local 209 matter, this document recommends to assign a single Entropy ID for 210 all Softwire transport enabled and advertise the same with all tunnel 211 type. Considering the number of available softwire transport 212 options, 8 bit of Entropy ID is sufficient to handle single Entropy 213 ID for all softwire transport or Entropy ID per softwire transport 214 implementations. 216 This document also strongly recommends to continue advertise Load- 217 balancing Block Sub-TLV [RFC5640] along with Entropy ID Sub-TLV. If 218 an ingress node does not support Entropy ID Sub-TLV, softwire load 219 balancing for L2TPv3-over-IP or GRE can be acheived by procedure 220 specified in [RFC5640]. 222 The encoding of the Sub-TLV is as below: 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Reserved | Entropy ID | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Reserved 231 Reserved for future use. 233 Entropy ID 234 Entropy Identifier, used to identify UDP Entropy 235 Tunnel. 237 6. IANA Considerations 239 IANA is requested to assign Sub-TLV type = 6 for Entropy-ID Sub-TLV, 240 in the BGP Tunnel Encapsulation Attribute Sub-TLVs registry. 242 7. Security Considerations 244 Same security considerations described in [RFC5512], [RFC5640], and 245 [I-D.ietf-6man-udpchecksums] are applicable. 247 8. Acknowledgement 249 The authors would like to thank Mark Townsley for his review and 250 comments. 252 9. References 254 9.1. Normative References 256 [I-D.ietf-6man-udpchecksums] 257 Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 258 UDP Checksums for Tunneled Packets", 259 draft-ietf-6man-udpchecksums-07 (work in progress), 260 January 2013. 262 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 263 August 1980. 265 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 266 Requirement Levels", BCP 14, RFC 2119, March 1997. 268 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 269 Subsequent Address Family Identifier (SAFI) and the BGP 270 Tunnel Encapsulation Attribute", RFC 5512, April 2009. 272 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 273 Framework", RFC 5565, June 2009. 275 [RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load- 276 Balancing for Mesh Softwires", RFC 5640, August 2009. 278 9.2. Informative References 280 [I-D.ietf-6man-udpzero] 281 Fairhurst, G. and M. Westerlund, "Applicability Statement 282 for the use of IPv6 UDP Datagrams with Zero Checksums", 283 draft-ietf-6man-udpzero-10 (work in progress), 284 January 2013. 286 Authors' Addresses 288 Carlos Pignataro 289 Cisco Systems, Inc. 290 7200 Kit Creek Road 291 Research Triangle Park, NC 27709-4987 292 US 294 Email: cpignata@cisco.com 296 Nagendra Kumar 297 Cisco Systems, Inc. 298 Cessna Business Park, Outer Ring Road 299 Bangalore, KARNATAKA 560108 300 INDIA 302 Email: naikumar@cisco.com 304 Pradosh Mohapatra 305 Cisco Systems, Inc. 306 170 Tasman Drive 307 San Jose, CA 95134 308 US 310 Email: pmohapat@cisco.com 312 Clarence Filsfils 313 Cisco Systems, Inc. 314 Brussels 1000 315 BELGIUM 317 Email: cfilsfil@cisco.com