idnits 2.17.1 draft-ietf-pwe3-cw-06.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 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 361. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 334. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 341. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 347. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (Oct 2005) is 6730 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'RFC2119' is mentioned on line 53, but not defined == Missing Reference: 'VCCV' is mentioned on line 67, but not defined ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT PWE3 Control Word for use over an MPLS PSN Oct 2005 4 Network Working Group S. Bryant 5 Internet Draft G. Swallow 6 Expiration Date: April 2006 L. Martini 7 Cisco Systems 8 D. McPherson 9 Arbor Networks 11 October 2005 13 PWE3 Control Word for use over an MPLS PSN 15 draft-ietf-pwe3-cw-06.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet-Drafts as 32 reference material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Abstract 42 This document describes the preferred design of a PWE3 Control Word 43 to be use over an MPLS packet switched network, and the Pseudo Wire 44 Associated Channel Header. The design of these fields is chosen so 45 that an MPLS Label Switching Router performing MPLS payload 46 inspection will not confuse a PWE3 payload with an IP payload. 48 Conventions used in this document 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in RFC 2119 [RFC2119]. 54 1. Introduction 56 The standard MPLS encapsulations have no explicit protocol 57 identifier. In order for a pseudo wire (PW) [RFC3985] to operate 58 correctly over an MPLS packet switched network (PSN) that performs 59 MPLS payload inspection, a PW packet must not appear to a label 60 switching router (LSR) as if it were an IP packet [BCP]. An example 61 of an LSR that performs MPLS payload inspection is one that is 62 performing equal-cost multiple-path load-balancing (ECMP) [RFC2992]. 63 If ECMP were performed on PW packets, the packets in the PW may not 64 all follow the same path through the PSN. This may result in 65 misordered packet delivery to the egress PE. The inability to ensure 66 that all packets belonging to a PW follow the same path may also 67 prevent the PW OAM [VCCV] mechanism from correctly monitoring the 68 PW. 70 This draft specifies how a PW header is used to distinguish a PW 71 payload from an IP payload carried over an MPLS PSN. It then 72 describes the preferred design of a PW Control Word to be use over 73 an MPLS PSN, and the Pseudo Wire Associated Channel Header. 75 2. Avoiding ECMP 77 A PW that is carried over an MPLS PSN that uses the contents of the 78 MPLS payload to select the ECMP path may be subjected to packet 79 misordering [BCP]. In cases where the application using the PW is 80 sensitive to packet misordering, or where packet misordering will 81 disrupt the operation of the PW, it is necessary to prevent the PW 82 being subjected to ECMP. 84 All IP packets [RFC791][RFC1883] start with a version number that is 85 checked by LSRs performing MPLS payload inspection. To prevent the 86 incorrect processing of packets carried within a PW, PW packets 87 carried over an MPLS PSN MUST NOT start with the value 4 (IPv4) or 88 the value 6 (IPv6) in the first nibble [BCP], as those are assumed 89 to carry normal IP payloads. 91 This document defines a PW header and two general formats of that 92 header. These two formats are the PW MPLS Control Word (PWMCW) which 93 is used for data passing across the PW, and a PW Associated Channel 94 Header (PWACH) that can be used for functions such as OAM. 96 If the first nibble of a PW packet carried over an MPLS PSN has a 97 value of 0, it starts with a PWMCW. If the first nibble of a packet 98 carried over an MPLS PSN has a value of 1, it starts with a PWACH. 99 The use of any other first nibble value for a PW packet carried over 100 an MPLS PSN is deprecated. 102 If a PW is sensitive to packet misordering and is being carried over 103 an MPLS PSN that uses the contents of the MPLS payload to select the 104 ECMP path, it MUST employ a mechanism which prevents packet 105 misordering. A suitable mechanism is the PWMCW described in Section 106 3 for data, and the PWACH described in Section 4 for channel 107 associated traffic. 109 The PWMCW or the PWACH MUST immediately follow the bottom of the 110 MPLS label stack. 112 3. Generic PW MPLS Control Word 114 The Generic PW MPLS Control Word (PWMCW) is shown in Figure 1. 116 0 1 2 3 117 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 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 |0 0 0 0| Specified by PW Encapsulation | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 Figure 1: Generic PW MPLS Control Word 124 The PW set-up protocol or configuration mechanism determines whether 125 a PW uses a PWMCW. Bits 0..3 differ from the first four bits of an 126 IP packet [BCP] and hence provide the necessary MPLS payload 127 discrimination. 129 When a PWMCW is used, it MUST adhere to the Generic format 130 illustrated in Figure 1 above. To provide consistency between the 131 designs of different types of PW, it SHOULD also use the following 132 preferred format: 134 0 1 2 3 135 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 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 |0 0 0 0| Flags |FRG| Length | Sequence Number | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 Figure 2: Preferred PW MPLS Control Word 142 The meaning of the fields of the Preferred PW MPLS Control Word 143 (Figure 2) is as follows: 145 Flags (bits 4 to 7): 147 These bits MAY be used by for per-payload signaling. Their 148 semantics MUST be defined in the PW specification. 150 FRG (bits 8 and 9): 152 These bits are used when fragmenting a PW payload. Their use 153 is described in [FRAG] which is currently a work in progress. 154 When the PW is of a type that will never need payload 155 fragmentation, these bits may be used as general purpose 156 flags. 158 Length (bits 10 to 15): 160 When the PSN path between the PEs includes an Ethernet, the 161 PW packet arriving at the CE-bound PE from the PSN may 162 include padding appended by the Ethernet Data Link Layer. The 163 CE-bound PE uses the length field to determine the size of 164 the padding added by the PSN, and hence extract the PW 165 payload from the PW packet. 167 If the MPLS payload is less than 64 bytes, the length field 168 MUST be set to the length of the PW payload plus the length 169 of the PWMCW. Otherwise it MUST be set to zero. 171 Sequence number (Bit 16 to 31): 173 The sequence number implements the sequencing function 174 [RFC3985]. The use of this field is described in Section 4. 176 4. Sequencing 178 The sequence number mechanism is PW specific. The PW encapsulation 179 specification MAY define a sequence number mechanism to be used, or 180 it may indicate that the mechanism described here is to be used. A 181 pseudo-code description of this mechanism is given in non-normative 182 Appendix 1. 184 The sequence number mechanism described here uses a circular 185 unsigned 16 bit number space that excludes the value zero. 187 4.1 Setting the Sequence Number 189 For a given PW, and a pair of routers PE1 and PE2, if PE1 supports 190 frame sequencing and frame sequencing is enabled for the PW, then 191 the following procedures MUST be used: 193 o The initial frame transmitted on the PW MUST be sent with 194 sequence number one. 196 o Subsequent frames MUST increment the sequence number by one for 197 each frame. 199 o The sequence number that follows 65535 (maximum unsigned 16 bit 200 number) is one. 202 If the transmitting router PE1 does not support sequence number 203 processing, or frame sequencing is disabled, then the sequence 204 number field in the control word MUST be set to zero for all frames 205 transmitted on the PW. 207 4.2 Processing the sequence number 209 If a router PE2 supports receive sequence number processing, and 210 frame sequencing is enabled for this PW, then the following 211 procedure is used: 213 When a PW is initially set up, the "expected sequence number" 214 associated with it MUST be initialized to one. 216 When a frame is received on that PW, the sequence number SHOULD be 217 processed as follows: 219 o If the sequence number on the frame is zero, the sequence 220 integrity of the packets cannot be determined. In this case, the 221 received frame is considered to be in order. 223 o Otherwise if the frame sequence number equals the expected 224 sequence number, the frame is in order. 226 o Otherwise if the frame sequence number is greater than the 227 expected sequence number, and the frame sequence number minus 228 the expected sequence number is less than 32768, the frame is 229 within the allowed receive sequence number window. The 230 implementation MAY treat the packet as is in order. 232 o Otherwise if the frame sequence number is less than the expected 233 sequence number and the expected sequence number minus the frame 234 sequence number is greater than or equal to 32768, the frame is 235 within the allowed receive sequence number window. The 236 implementation MAY treat the packet as is in order. 238 o Otherwise the frame is out of order. 240 If the frame is in order, it can be delivered immediately. 242 If the frame sequence number was not zero, then the expected 243 sequence number is set to the frame sequence number plus one. The 244 expected sequence number that follows 65535 (maximum unsigned 16 bit 245 number) is one. 247 Frames which are received out of order MAY either be dropped or 248 reordered. The choice between dropping or re-ordering an out of 249 sequence frame is at the discretion of the receiver. 251 If a PE negotiated not to use receive sequence number processing, 252 and it received a non zero sequence number, then it SHOULD send a PW 253 status message indicating a receive fault, and disable the PW. 255 5. PW Associated Channel 257 For some PW features, an associated channel is required. An 258 associated channel is a channel that is multiplexed over the PW so 259 that it follows exactly the same path through the PSN as the PW. 260 Note that the use of the term "channel" is not a "PW channel type" 261 as used in subsection 5.1.2 of [RFC3985] 263 When MPLS is used as the PSN, the PW Associated Channel (PWAC) is 264 identified by the following header: 266 0 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 |0 0 0 1|Version| Reserved | Channel Type | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Figure 3: PW Associated Channel Header 274 The meanings of the fields in the PW Associated Channel Header 275 (PWACH) (Figure 3) are: 277 Version: 279 This is the version number of the PWACH. This specification 280 defines version 0. 282 Reserved: 284 MUST be sent as 0, and ignored on reception. 286 Channel Type: 288 The PW Associated Channel Type is defined in the IANA PW 289 Associated Channel Type registry [IANA]. 291 Bits 0..3 MUST be 0001. This allows the packet to be distinguished 292 from an IP packet [BCP] and from a PW data packet. 294 6. IANA considerations 296 IANA needs to set up a registry of "Pseudowire Associated Channel 297 Types". These are 16-bit values. Registry entries are assigned by 298 using the "IETF Consensus" policy defined in [RFC2434]. The value 299 0X21 indicates that the Associated Channel carries an IPv4 packet. 301 7. Security Considerations 303 An application using a PW Associated Channel must be aware that the 304 channel can potentially be misused. Any application using the 305 Associated Channel MUST therefore fully consider the resultant 306 security issues, and provide mechanisms to prevent an attacker from 307 using this as a mechanism to disrupt the operation of the PW or the 308 PE, and to stop this channel from being used as a conduit to deliver 309 packets elsewhere. The selection of a suitable security mechanism 310 for an application using a PW Associated Channel is outside the 311 scope of this document. 313 If a PW has been configured to operate without a CW, the PW 314 Associated Channel Type mechanism described in the document MUST NOT 315 be used. This is to prevent user payloads being fabricated in such a 316 way that they mimic the PW Associated Channel Header, and thereby 317 provide a method of attacking the application that is using the 318 Associated Channel. 320 8. Acknowledgements 322 The authors wish to thank David Allan, Thomas Nadeau, Yaakov Stein, 323 and Mark Townsley for their input to this work. 325 9. Intellectual Property Statement 327 The IETF takes no position regarding the validity or scope of any 328 Intellectual Property Rights or other rights that might be claimed 329 to pertain to the implementation or use of the technology described 330 in this document or the extent to which any license under such 331 rights might or might not be available; nor does it represent that 332 it has made any independent effort to identify any such rights. 333 Information on the procedures with respect to rights in RFC 334 documents can be found in BCP 78 and BCP 79. 336 Copies of IPR disclosures made to the IETF Secretariat and any 337 assurances of licenses to be made available, or the result of an 338 attempt made to obtain a general license or permission for the use 339 of such proprietary rights by implementers or users of this 340 specification can be obtained from the IETF on-line IPR repository 341 at http://www.ietf.org/ipr. 343 The IETF invites any interested party to bring to its attention any 344 copyrights, patents or patent applications, or other proprietary 345 rights that may cover technology that may be required to implement 346 this standard. Please address the information to the IETF at 347 ietf-ipr@ietf.org. 349 10. Full copyright statement 351 Copyright (C) The Internet Society (2005). This document is subject 352 to the rights, licenses and restrictions contained in BCP 78, and 353 except as set forth therein, the authors retain all their rights. 355 This document and the information contained herein are provided on 356 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 357 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 358 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 359 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 360 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 361 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 363 11. Normative References 365 Internet-drafts are works in progress available from 366 http://www.ietf.org/internet-drafts/ 368 [RFC791] RFC-791: DARPA Internet Program, Protocol 369 Specification, ISI, September 1981. 371 [RFC1883] RFC-1883: Internet Protocol, Version 6 (IPv6), S. 372 Deering, et al, December 1995 374 12. Informative References 376 Internet-drafts are works in progress available from 377 379 [BCP] Swallow, G. et al, "Avoiding Equal Cost Multipath 380 Treatment in MPLS Networks", Internet Draft 381 , July 2005, Work 382 in Progress. 384 [FRAG] Malis, A., Townsley, M., "PWE3 Fragmentation and 385 Reassembly", Internet Draft, , September 2005, Work in 387 Progress. 389 [IANA] Martini, L., Townsley M., "IANA Allocations for 390 pseudo Wire Edge to Edge Emulation (PWE3) ", 391 Internet Draft, , September 2005, Work in Progress. 394 [RFC2434] RFC-2434: Guidelines for Writing an IANA 395 Considerations Section in RFCs, Narten, T., 396 Alvestrand, H., October 1998 398 [RFC2992] RFC-2992: Analysis of an Equal-Cost Multi-Path 399 Algorithm, C. Hopps, November 2000 401 [RFC3985] RFC-3985: PWE3 Architecture, Bryant, S. ed., Pate, 402 P. ed., March 2005 404 13. Authors' Addresses 406 Stewart Bryant 407 Cisco Systems, 408 250, Longwater, 409 Green Park, 410 Reading, RG2 6GB, 411 United Kingdom. Email: stbryant@cisco.com 413 Luca Martini 414 Cisco Systems, Inc. 415 9155 East Nichols Avenue, Suite 400 416 Englewood, CO, 80112 Email: lmartini@cisco.com 418 Danny McPherson 419 Arbor Networks, Inc. Email: danny@arbor.net 421 George Swallow 422 Cisco Systems, Inc. 423 1414 Massachusetts Ave 424 Boxborough, MA 01719 Email: swallow@cisco.com 426 14. Appendix 1 Sequence Number Processing 428 This appendix is non-normative. 430 This appendix provides a pseudo-code description of the sequence 431 number processing mechanism described in Section 4.2. 433 unsigned16 RECEIVED /* frame sequence number 434 unsigned16 EXPECTED = 1 /* expected sequence number 435 /* initialized to one 436 boolean sequencingDisabled 437 boolean dropOutOfOrder /* policy on in-window out of sequence 438 /* frames 440 updateExpected() 441 begin 442 EXPECTED := RECEIVED + 1; 443 /* Because EXPECTED is an unsigned16 it will wrap 444 /* from 65535 to 0 445 /* zero is skipped 446 if (EXPECTED = 0) 447 EXPECTED := 1; 448 return; 449 end; 450 On receipt of a PW packet from PSN: 451 begin 452 if (RECEIVED = 0) then begin 453 processFrame(); 454 return; 455 end; 457 if (sequencingDisabled) then begin 458 /* A frame was received with non-zero sequence number, but 459 /* sequencing is disabled 460 indicateReceiveFault(); 461 disablePW(); 462 return; 463 end; 465 /* The received sequence is the expected sequence number 466 if ((RECEIVED = EXPECTED) then begin 467 /* packet is in order 468 processFrame(); 469 updateExpected(); 470 return; 471 end; 473 /* Test for received sequence number is greater than 474 /* the expected sequence number and is within the 475 /* allowed receive sequence number window 476 if ((RECEIVED > EXPECTED) and 477 ((RECEIVED - EXPECTED) < 32768) then begin 478 /* frame is in the window, but there are late/missing 479 /* frames 480 if (dropOutOfOrder) then begin 481 /* policy is to receive immediately, dropping 482 /* out of sequence frames 483 processFrame(); 484 updateExpected(); 485 return; 486 end else begin 487 /* policy is to wait for late packets 488 processMissingFrames(); 489 return; 490 end; 491 end; 493 /* Test for the received sequence is less than the 494 /* expected sequence number and is within the allowed 495 /* receive sequence number window 496 if ((RECEIVED < EXPECTED) and 497 ((EXPECTED - RECEIVED) >= 32768) then begin 498 /* frame is in the window, but there are late/missing 499 /* frames 500 if (dropOutOfOrder) then begin 501 /* policy is to receive immediately, dropping 502 /* out of sequence frames 503 processFrame(); 504 updateExpected(); 505 return; 506 end else begin 507 /* policy is to wait for late packets 508 processMissingFrames(); 509 return; 510 end; 511 end; 513 /* Received packet was outside the allowed receive 514 /* sequence number window 515 processOutOfWindow(); 516 end;