idnits 2.17.1 draft-vkompella-pwe3-hash-label-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 299. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 311. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 318. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 324. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 8) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 18, 2008) is 5913 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 (-04) exists of draft-ietf-mpls-ldp-capabilities-01 == Outdated reference: A later version (-04) exists of draft-ietf-mpls-ldp-interarea-02 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Document Vach Kompella 3 Category: Standards Track Joe Regan 4 Expires: August 2008 Alcatel-Lucent 6 Shane Amante 7 Level 3 Communications 9 February 18, 2008 11 Conversation Hashing for Pseudowires 12 draft-vkompella-pwe3-hash-label-00.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that 17 any applicable patent or other IPR claims of which he or she is 18 aware have been or will be disclosed, and any of which he or she 19 becomes aware will be disclosed, in accordance with Section 6 of 20 BCP 79. 22 Internet-Drafts are working documents of the Internet 23 Engineering Task Force (IETF), its areas, and its working 24 groups. Note that other groups may also distribute working 25 documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other 29 documents at any time. It is inappropriate to use Internet- 30 Drafts as reference material or to cite them other than as "work 31 in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on August 21, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2008). 45 Abstract 46 This draft proposes a method to introduce granularity on the 47 hashing of traffic running over pseudowires. Most forwarding 48 engines are able to hash based on label stacks, so the approach 49 here is to introduce additional labels that do not affect the 50 handling of packets, but which identify a conversation, and can 51 be hashed with granularity. 53 1. Introduction 55 This draft proposes a method to introduce granularity on the 56 hashing of traffic running over pseudowires. Typically, 57 forwarding hardware is capable of looking at some fields in 58 packets to construct hash buckets for conversations or flows. 59 The ingress node is able to look at the un-encapsulated packet 60 and spread flows around. At intermediate nodes, for 61 pseudowires, there is no information on what layer 2 protocol 62 encapsulation is on the packet, so the hardware can only hash on 63 is the label stack. However, the granularity obtained over 64 pseudowires is inadequate for real load-balancing, especially 65 when the pseudowires emulate fat trunks. 67 2. The Solution 69 When two PEs open up a targeted LDP session between them, as 70 part of the Capability exchange between the two peers [LDP-Cap], 71 the Hash Label TLV is exchanged. The Hash Label TLV specifies a 72 set of labels that instruct the receiving PE to POP and continue 73 on to the next label in the stack. 75 Since forwarding engines generate hash buckets based on the 76 label stack, the Hash Label(s) can be used to provide some 77 diversity in the conversations in a pseudowire. 79 Suppose that an LDP session has been established between two 80 peers, P and Q, and Q has signaled ten Hash Labels in the range 81 101 through 110 (inclusive). On receiving a packet from the 82 attachment circuit, node P will hash the packet into one of ten 83 buckets, one for each Hash Label received by P. P will then 84 encapsulate the packet with the PW label at the bottom of stack, 85 add the appropriate Hash Label corresponding to the hash bucket, 86 and finally add the tunnel encapsulation. Assume for the moment 87 that the tunnel encapsulation is another label. 89 At P, the layer 2 fields are visible, and a next hop can be 90 determined out of the multiple (e.g., ECMP or LAG) next hops. 91 However, at an LSR node, the label stack provides more 92 variability, even though the packets belong to the same 93 pseudowire because the Hash Label gives more diversity. 95 The same set of labels used for hashing can be used between Q 96 and any other node that it sets up a targeted LDP session, and 97 the same set of labels can be used across different pseudowires. 99 Note that this solution can be extended, e.g., if P is capable 100 of imposing four labels, and if Q is capable of processing a 101 four label stack, then P can hash the flows into 100 buckets 102 (using two of the hash labels for the conversation diversity). 103 This would also require that the intermediate nodes be capable 104 of hashing a four label stack. 106 The order of the labels must be PW label at the bottom, Router 107 Alert (if present), and then the Hash Label(s). Finally, the 108 tunnel encapsulation comes at the top of the stack, which may be 109 a label (or a pair of labels if the MPLS protocol imposes them, 110 e.g., using facility bypass protection [RFC4090], or inter-area 111 LDP [LDP-Ext]). 113 2.1. Protocol Format 115 We introduce a new Hash Label TLV which has the following 116 format. 118 0 1 2 3 119 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 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 |U|F| Hash Label TLV | Length | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | NumPushLabels | NumPopLabels | NumHashLabels | AllocType | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | MBZ | Label 1 | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | MBZ | Label 2 | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | MBZ | " | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 Hash Label TLV Type. 133 The type of the Hash Label TLV (TBD from IANA). 135 Length. 136 The length of the TLV. 138 NumPushLabels. 140 The number of hash labels the node can push. 142 NumPopLabels. 143 The number of hash labels the node can pop. 145 NumHashLabels. 146 The number of hash labels provided for use. 148 AllocType. 149 The type of allocation scheme. If AllocType = 0, then the 150 labels following the AllocType are a list of labels. If 151 AllocType = 1, then exactly two labels must follow the 152 AllocType, and they provide the lower and upper bound of a range 153 of labels (inclusive). 155 Label 1, Label 2, etc. 156 If AllocType = 0, these are actual labels that may be used 157 as hash labels. If AllocType = 1, then they are the lower and 158 upper bound of a range of hash labels that may be used. 160 3. Packet format with PW hash labels 162 The following is an example of what could happen if hash labels 163 are exchanged between two nodes P and Q, where P sends Q the 164 Hash Label TLV with 10 labels between 101 and 110. 166 The figure below shows the PW and tunnel labels. 168 PW label 2001 169 ------------------------------ 170 | ----- | 171 | ------>| C |------- | 172 | | 4000 ----- 7000 | | 173 | | v v 174 ----- ----- ----- ----- 175 AC1-----| P |----| A |----| B |----| Q |-----AC2 176 ----- ----- ----- ----- 177 | ^ | ^ | ^ 178 | | | | | | 179 --------- ------ ------- 180 3000 5000 6000 181 Tunnel Labels: 182 P->A: 3000 183 P->C: 4000 184 A->B: 5000 185 B->Q: 6000 186 C->B: 7000 187 Q hashes a packet from attachment circuit AC2, on whatever 188 relevant fields define a conversation or flow, and comes up with 189 an index between 1 and 10, say 5. Then Q constructs the packet 190 to P to look like: 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | 6000 (Tunnel Label) | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | 105 (Hash Label) | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | 2001 (PW Label) (BOS) | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Payload | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 When B receives the packet, it will hash the label stack {6000, 203 105, 2001} and come up with one of the next-hops A or C. Say 204 the result is A. The packet from B to A will look like: 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | 5000 (Tunnel Label) | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | 105 (Hash Label) | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | 2001 (PW Label) (BOS) | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Payload | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 P would then receive the following packet from A: 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | 3000 (Tunnel Label) | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | 105 (Hash Label) | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | 2001 (PW Label) (BOS) | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Payload | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 P will pop 3000, find the hash label 105 (action pop), and then 229 process 2001 as the PW label to forward the packet out AC1 with 230 whatever necessary encapsulation is required for that DLC. 232 The rationale for putting the hash label between the PSN tunnel 233 encapsulation and the PW label is that the forwarding engine 234 will not have to process the PW label and then after it has 235 taken the appropriate action, be required to remember the 236 context while it processes the hash labels. 238 4. Future considerations 240 One future application of this method would be to create a basis 241 for hash diversity without having to peek below the label stack 242 for IP traffic carried over LDP LSPs. 244 5. References 246 Normative References 248 Informative References 250 [LDP-Cap] "LDP Capabilities," R. Thomas et al, draft-ietf-mpls- 251 ldp-capabilities-01.txt, work in progress, February 2008. 253 [RFC4090] "Fast Reroute Extensions to RSVP-TE for LSP Tunnels," 254 P. Pan, RFC 4090, May 2005. 256 [LDP-Ext] "LDP extension for Inter-Area LSP," B. Decraene et al, 257 draft-ietf-mpls-ldp-interarea-02.txt, work in progress, February 258 2008. 260 6. Security Considerations 262 No new security issues arise out of the extensions proposed here 263 than exist in the base PWE3 standards. 265 7. IANA Considerations 267 No IANA allocations have been specified yet (but a new TLV type 268 will be forthcoming, as well as changes to the LDP Capability 269 FEC TLV). 271 8. Authors' Addresses 273 Vach Kompella 274 Alcatel-Lucent 275 vach.kompella@alcatel-lucent.com 276 Joe Regan 277 Alcatel-Lucent 278 joe.regan@alcatel-lucent.com 280 Shane Amante 281 Level 3 Communications 282 shane@castlepoint.net 284 9. Full Copyright Statement 286 Copyright (C) The IETF Trust (2008). 288 This document is subject to the rights, licenses and 289 restrictions contained in BCP 78, and except as set forth 290 therein, the authors retain all their rights. 292 This document and the information contained herein are provided 293 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 294 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 295 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 296 ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 297 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 298 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 299 OR FITNESS FOR A PARTICULAR PURPOSE. 301 10. Intellectual Property 303 The IETF takes no position regarding the validity or scope of 304 any Intellectual Property Rights or other rights that might be 305 claimed to pertain to the implementation or use of the 306 technology described in this document or the extent to which any 307 license under such rights might or might not be available; nor 308 does it represent that it has made any independent effort to 309 identify any such rights. Information on the procedures with 310 respect to rights in RFC documents can be found in BCP 78 and 311 BCP 79. 313 Copies of IPR disclosures made to the IETF Secretariat and any 314 assurances of licenses to be made available, or the result of an 315 attempt made to obtain a general license or permission for the 316 use of such proprietary rights by implementers or users of this 317 specification can be obtained from the IETF on-line IPR 318 repository at http://www.ietf.org/ipr. 320 The IETF invites any interested party to bring to its attention 321 any copyrights, patents or patent applications, or other 322 proprietary rights that may cover technology that may be 323 required to implement this standard. Please address the 324 information to the IETF at ietf-ipr@ietf.org. 326 11. Acknowledgments 328 Funding for the RFC Editor function is provided by the IETF 329 Administrative Support Activity (IASA).