idnits 2.17.1 draft-bryant-pwe3-fr-compare-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 92: '...control word, it MUST set the flags in...' RFC 2119 keyword, line 94: '...control word, it MUST set the Frame Re...' RFC 2119 keyword, line 97: '...ters that implement this document MAY,...' RFC 2119 keyword, line 103: '...CN, and D/E bits MUST NOT be changed f...' RFC 2119 keyword, line 189: '...s, the length field MUST be set to the...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 216 has weird spacing: '... be process...' -- 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 (October 2001) is 8226 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'BRYANT' -- Possible downref: Non-RFC (?) normative reference: ref. 'KAWA' -- Possible downref: Non-RFC (?) normative reference: ref. 'MARTINI' Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Stewart Bryant 2 Internet Draft Lloyd Wood 3 Document: draft-bryant-pwe3-fr-compare-00.txt Cisco Systems Ltd 4 Expires: May 2002 October 2001 6 A Commentary on Approaches to Frame Relay Encapsulation in PWE3 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance 11 with all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This document compares and contrasts four approaches to Frame Relay 31 encapsulation over a pseudo-wire that have been proposed in the 32 Pseudo-Wire Edge-to-Edge (PWE3) IETF working group. This document 33 then shows that the general-purpose encapsulation previously 34 proposed for HDLC, Ethernet and VLAN is also the most efficient 35 approach for Frame Relay. 37 draft-bryant-pwe3-fr-compare-00.txt October 2001 39 Table of Contents 41 Status of this Memo................................................1 42 Abstract...........................................................1 43 1. Overview........................................................2 45 2. The Martini encapsulation.......................................3 46 2.1 Comments on the Martini encapsulation..........................3 47 3. The Kawa encapsulation..........................................4 48 3.1 Comments on the Kawa encapsulation.............................5 49 4. Bryant Optimized Frame-Relay-specific control word..............6 50 4.1 Comments on Bryant Optimized Frame-Relay-specific control word.7 51 5. General Pseudo-wire Payload Encapsulation.......................7 52 5.1 Comments on General Pseudo-wire Payload Encapsulation..........8 54 6. Mapping between the Control Word and the Frame Relay Header.....8 55 6.1 Mapping between Martini control word and Frame Relay header....8 56 6.2 Mapping between Kawa control word and Frame Relay header.......9 57 6.3 Mapping between Bryant optimized Frame-Relay-specific control 58 word and Frame Relay header.......................................10 59 6.4 Mapping between the General Pseudo-wire Payload Encapsulation 60 and Frame Relay...................................................11 62 7. Frame Relay header translation.................................11 63 8. Conclusions....................................................13 64 9. IANA considerations............................................13 65 10. Security considerations.......................................13 66 11. References....................................................14 67 Authors' addresses................................................14 68 Full copyright statement..........................................15 70 1. Overview 72 The design of the pseudo-wire encapsulation header can have 73 considerable impact on the performance of the system using it. 74 Drafts describing four Frame Relay encapsulation approaches have 75 been presented. This document compares and contrasts these 76 approaches and analyses their computational efficiency. From this 77 analysis it is evident that the general-purpose encapsulation 78 proposed for HDLC, Ethernet and VLAN is also the most efficient 79 approach for Frame Relay. 81 draft-bryant-pwe3-fr-compare-00.txt October 2001 83 2. The Martini encapsulation 85 The following relevant text is extracted from section 4.1 (Frame 86 Relay) of [MARTINI] for convenient immediate reference. 88 "A Frame Relay PDU is transported without the Frame Relay header or 89 the FCS. The control word is REQUIRED; however, its use is 90 optional, although desirable. Use of the control word means that the 91 ingress and egress LSRs follow the procedures below. If an ingress 92 LSR chooses not to use the control word, it MUST set the flags in 93 the control word to 0; if an egress LSR chooses to ignore the 94 control word, it MUST set the Frame Relay control bits to 0. 96 "The BECN, FECN, DE and C/R bits are carried across the network in 97 the control word. The edge routers that implement this document MAY, 98 when either adding or removing the encapsulation described herein, 99 change the BECN and/or FECN bits from zero to one in order to 100 reflect congestion in the network that is known to the edge routers, 101 and the D/E bit from zero to one to reflect marking from edge 102 policing of the Frame Relay Committed Information Rate. The BECN, 103 FECN, and D/E bits MUST NOT be changed from one to zero. 105 "The following is an example of a Frame Relay packet: 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 | Rsvd |B|F|D|C| Length | Sequence Number | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Frame Relay PDU | 113 | " | 114 | " | 115 | " | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 " 119 As a reminder, definitions of bits as used in these drafts and in 120 [Q.922] are: 121 B is the BECN (Backward Explicit Congestion Notification) bit 122 F is the FECN (Forward Explicit Congestion Notification) bit 123 D is the DE (Discard Eligibility) bit 124 C is the C/R (Command/Response) bit 126 2.1 Comments on the Martini encapsulation 128 [MARTINI] takes the approach of copying Frame Relay payload- 129 dependent bits to fields in the control word, stripping the Frame 130 Relay header from the Frame Relay PDU, and reconstructing the header 131 at the far end of the pseudo-wire. The reason for this approach is 132 not given in [MARTINI]. 134 draft-bryant-pwe3-fr-compare-00.txt October 2001 136 The [MARTINI] approach to handling Frame Relay headers is 137 inconsistent with the approaches used in the same draft for other 138 encapsulation types. The encapsulation and de-capsulation processes 139 can be made more efficient if the Frame Relay header is transmitted 140 along with its accompanying PDU, in a manner consistent with the 141 HDLC, Ethernet and VLAN encapsulation types. 143 The layout and ordering of the B, F, D and C bits in the control 144 word differ from the layout and ordering of these bits in the Frame 145 Relay header. Resulting necessary bit manipulation in both 146 encapsulation and decapsulation introduces unnecessary processing 147 overhead in any implementation. We will show that this overhead can 148 be avoided. 150 3. The Kawa encapsulation 152 The following relevant text is extracted from section 6.1 of [KAWA] 153 for reference: 155 "FRoPW header structure is shown in Figure 3. 156 0 1 2 3 157 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 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Res |P|F|B|D|C|X|Y| Length | Sequence Number | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 Figure 3 - FRoPW header structure 164 "The meaning of the fields is as follows: 165 Res (bits 0 to 2): Reserved bits. They are set to zero on 166 transmission and ignored on reception. 168 "P - Payload Type (bit 3): 169 If set to zero then the payload field contains user's data else it 170 contains network maintenance data. 172 "X, Y (bits 8 and 9): 173 1 0: First segment of a segmented FRoPW packet 174 0 1: Last segment of a segmented FRoPW packet 175 0 0: Neither the first nor the last segment of a segmented FroPW 176 packet 177 1 1: Complete FRoPW packet 179 "X and Y bits are used for segmentation and re-assembly of FroPW 180 packet fragments when these capabilities are enabled in the two PEs 181 terminating a PW. 183 "Length (bits 10 to 15): 184 The length field is used to pad short FRoPW packets over Ethernet 185 PSN. The length field is used as follows: If the length of the layer 186 2 frame (consisting of layer two control information and layer 2 187 draft-bryant-pwe3-fr-compare-00.txt October 2001 189 payload) is less than 64 bytes, the length field MUST be set to the 190 FRoPW packet length. Otherwise the length field MUST be set to zero. 191 The value of the length field, if non-zero, is used to remove any 192 padding. 194 "Sequence number (Bit 16 to 31): 195 If not used it is set to zero by the sender and ignored by the 196 receiver. Otherwise it specifies the sequence number of a complete 197 FRoPW packet or a fragment. A circular list of sequence numbers is 198 used. A sequence number takes a value from 1 to 65535 (2**16-1). 199 Arithmetic modulo 2**16 is used to generate a new sequence number. 201 "The sequence number must be used when segmentation and re-assembly 202 are enabled between two peer PEs terminating a PSN tunnel. The 203 sequence number may be used to detect out-of-order delivery of FRoPW 204 packets when the PSN does not guarantee in-order delivery." 206 3.1 Comments on the Kawa encapsulation 208 As with the [MARTINI] approach, the Frame Relay payload-dependent 209 bits are copied to fields in the control word, the Frame Relay 210 header is stripped from the Frame Relay PDU, and the header must be 211 reconstructed at the far end of the pseudo-wire. Again, the reason 212 for doing this is not given. 214 The grouping and ordering of the payload-dependent bits in the 215 [KAWA] control word is more consistent with Q.922, allowing them to 216 be processed as a three bit group (FBD) and a single bit (C). This 217 reduces the processing overhead in comparison with [MARTINI]. 218 However, the [KAWA] draft fails to take advantage of the additional 219 performance gains to be made by closely following the layout 220 specified in [Q.922]. 222 We have found the naming and polarity of the fragmentation bits 223 introduced in [KAWA] confusing. Use of the name 'X' for the first 224 segment indicator conflicts with common usage of the symbol 'X' to 225 indicate "don't care" about the value of the bit. 227 The polarity chosen fails to take advantage of the performance 228 optimizations normally available in processor instruction sets. A 229 common case is likely to be that the frame length is greater than 64 230 bytes, but less than the MTU. In the scheme described in [KAWA], 231 this is indicated by setting bits 8..15 to the binary value 232 <11000000>. 234 We propose that the sense of the X and Y bits be reversed, and 235 renamed to notStart (A) and notEnd (B) bits respectively. 237 This is represented in the following two-bit state table: 239 draft-bryant-pwe3-fr-compare-00.txt October 2001 241 A, B (bits 8 and 9): 242 0 0: Complete packet (start and end) 243 0 1: First segment (start and not end) 244 1 1: Continuing segment (not start and not end) 245 1 0: Last segment (not start and end) 247 This leads to the use of an ordered stream: 0{1111}0 , where the 248 common case of an unfragmented frame that is greater than 64 bytes, 249 but less than the MTU, is sent as <00000000>. This is 250 straightforward and optimal to detect in normal software 251 implementations. 253 To provide space for the fragmentation bits, [KAWA] reduces the 254 length of the length field from 8 bits to 6 bits. Some rationale 255 needs to be provided that explains the reason for this approach 256 rather than maintaining 8-bit length compatibility with the other 257 encapsulation drafts, and using an additional two bits from the 258 reserved field instead. 260 The need to fragment a payload for transmission across a pseudo-wire 261 is common to all payload types. It would therefore seem appropriate 262 to move this to a common PWE3 header to be defined, rather than to 263 use it in a specific Frame Relay method and later reinvent it for 264 other payload types. This would restore the length field in [KAWA] 265 to the expected 8 bits. The absence of a fragmentation mechanism in 266 MPLS and IPv6 raises the question of whether fragmentation is a 267 unique problem to PWE3 or a general problem that will need to be 268 addressed by other transport types, such as [GRE]. If it were a 269 general problem it would be better to further abstract the 270 fragmentation support to a separate fragmentation layer above the 271 PSN and below PWE3. 273 The [KAWA] control word specifies the length field as a MUST, 274 indicating that it is compulsory. This is wasteful of resources when 275 the PSN is IP, because the IP payload length will always be present. 277 4. Bryant Optimized Frame-Relay-specific control word 279 The following relevant text is extracted from section 2 (An 280 Optimized Frame-Relay-specific control word) of [BRYANT] for 281 reference: 283 "An optimized Frame-Relay-specific control word would require no 284 bit-manipulation operators to transform to and from the Frame Relay 285 header. Such a control word is presented here: 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | length |C|X|X|X|X|X|F|B|D|X| Sequence Number | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 draft-bryant-pwe3-fr-compare-00.txt October 2001 294 "The meaning of the fields is as follows: 296 "Length (bits 0 to 5): 297 The length field is used to indicate the payload length of a packet 298 that may have been padded during transmission, if that information 299 is not provided by the PSN encapsulation. If the length of the 300 layer-two frame (consisting of layer-two control information and 301 layer-two payload) is less than 64 bytes, the length field MUST be 302 set to the Frame Relay PDU length. Otherwise the length field MUST 303 be set to zero." 305 4.1 Comments on Bryant Optimized Frame-Relay-specific control word 307 In this proposal the first two octets of the control word and the 308 first two octets of a frame-relay header have the same payload 309 specific bit layout, i.e. the CFB and D bits are located at the same 310 positions in both the control word and header, allowing one to be 311 constructed from the other using a read, mask, write operation. 312 The length field is placed in the same location at the unused high- 313 order DLCI bits and the remaining bits in the first two octets are 314 unused. 316 The length field is only used with PSN types that do not provide 317 that information, and is therefore not required when an IP 318 encapsulation is used. 320 5. General Pseudo-wire Payload Encapsulation 322 The following relevant text is extracted from section 3 (General 323 Pseudo-wire Payload Encapsulation) of [BRYANT] for reference: 325 "The most computationally-efficient encapsulation approach is the 326 general pseudo-wire encapsulation approach proposed by [MARTINI] for 327 HDLC, Ethernet and VLAN. The Frame Relay PDU is transported in its 328 entirety, excluding only HDLC flags and the FCS. Bit stuffing is 329 undone. The control word follows the general control word definition 330 in [MARTINI]. The control word is OPTIONAL. If the control word is 331 used then the flag bits in the control word are not used, and MUST 332 be set to 0 when transmitting, and MUST be ignored upon receipt. 334 "If a fragmentation scheme is required within the pseudo-wire 335 protocol layer, then this should be incorporated into the general 336 control word for use by all encapsulation types. A general 337 encapsulation is shown here: 338 0 1 2 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Res |A|B| Length | Sequence Number | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 draft-bryant-pwe3-fr-compare-00.txt October 2001 345 The meaning of the fields is as follows: 347 Res (bits 0 to 5): 348 Reserved bits. These are set to zero on transmission and ignored on 349 reception. 351 A, B (bits 6 and 7): 352 0 0: Complete packet (start and end) 353 0 1: First segment (start and not end) 354 1 1: Continuing segment (not start and not end) 355 1 0: Last segment (not start and end)" 357 Use of the length and sequence number fields is similar to that of 358 the Bryant optimised Frame-relay-specific header discussed in 359 section 4 above, except that we adopt the 8-bit length and position 360 preferred by [MARTINI]. 362 5.1 Comments on General Pseudo-wire Payload Encapsulation 364 This approach treats Frame Relay as a general packet transport and 365 transports and uses an encapsulation common to HDLC, VLAN and 366 Ethernet. The [KAWA] fragmentation scheme is optionally included, 367 with the changes to [KAWA] recommended in this document. 369 Note that this proposal makes no comment about the mapping between 370 L2TP sessions (MPLS labels) and Frame Relay DLCIs. This approach, 371 with the associated computational efficiencies demonstrated below, 372 is valid both when there is a one-to-one relationship between DLCI 373 and L2TP session (MPLS labels), and when multiple DLCIs share a 374 common L2TP session (MPLS label). 376 6. Mapping between the Control Word and the Frame Relay Header 378 This section explores the computational complexity of the mapping 379 between the proposed control words and the Frame Relay header. 381 6.1 Mapping between Martini control word and Frame Relay header 383 This section looks at the issue of mapping between the Martin 384 control work and the Frame Relay header in software. 386 The control word defined in [MARTINI] is: 388 0 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Rsvd |D|B|F|C| Length | Sequence Number | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 The two-octet Frame Relay header in normal IETF (DoD) notation is: 396 draft-bryant-pwe3-fr-compare-00.txt October 2001 398 0 1 399 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | hi dlci |C|0|lo dlci|F|B|D|1| 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 Bits 7 and 15 are the Q.922 EA (Extended Address) bits used for 405 address field extension. In the unextended two-octet header these 406 are defined to be 0 and 1 respectively. 408 Processors rarely have efficient bit manipulation operations, so you 409 cannot normally just assign the bits to their new positions easily. 410 It therefore becomes necessary to isolate each of the DBFC bits in 411 the control word using an AND operation, to use a shift operator to 412 move each bit to its correct position in the Frame Relay header, and 413 then to load the isolated bit into the header buffer using an OR 414 operator. This requires four operations on each of four bits: 416 - Move first octet of control word to temporary location. 417 - AND to isolate bit. 418 - Shift bit to corresponding location in Frame Relay header octet. 419 - Write or OR bit into Frame Relay header. 421 A similar number of operations in needed in constructing the Control 422 Word from the received Frame Relay header. For comparison we can 423 regard this construction as having a cost of: 424 (4 bits * 4 operations) + (4 bits * 4 operations) = 32 operations. 426 Note that we have not included the processing of the DLCI bits 427 (normally an OR operation) in this analysis, since that is an 428 overhead common to all transmission formats. Also note that, for the 429 purposes of Frame Relay header manipulation, the EA bits can 430 normally be included in the pro-forma DLCI definition. 432 6.2 Mapping between Kawa control word and Frame Relay header 434 This section looks at the issue of mapping between the [KAWA] 435 control word and the Frame Relay header in software. The Kawa 436 control word is: 437 0 1 2 3 438 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 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Res |P|F|B|D|C|X|Y| Length | Sequence Number | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 Again for comparison, the two-octet Frame Relay header in normal 444 IETF (DoD) notation is: 445 0 1 446 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | hi dlci |C|0|lo dlci|F|B|D|1| 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 draft-bryant-pwe3-fr-compare-00.txt October 2001 452 In this case we can isolate the FBD bits as group, and knowing that 453 they are in the same position and order in the octet in both Control 454 Word and the Frame Relay header, we can write them directly to the 455 header buffer in three operations: 457 - Move first octet of control word to temporary location. 458 - AND to isolate FBD bits. 459 - Write bits into Frame Relay header. 461 The C bit requires isolation with an AND operator, shifting and 462 writing into the header buffer (4 operations). 464 - Move second octet of control word to temporary location. 465 - AND to isolate C bit. 466 - Shift bit to corresponding location in Frame Relay header octet. 467 - Write C bit into Frame Relay header. 469 This same number of operations is needed in construction of the 470 control word making a comparative cost of: 471 (3 + 4) + (3 + 4) operations = 14 operations. 473 14 operations compares well with the 32 operations needed for the 474 [MARTINI] implementation. 476 Technical considerations suggest that the [KAWA] proposal is 477 superior in allowing a simpler, higher-performance implementation. 478 However, it has been proposed that [KAWA] be changed to follow the 479 [MARTINI] control word. The analysis presented here suggests that 480 this would be a backwards step. 482 6.3 Mapping between Bryant optimized Frame-Relay-specific control word 483 and Frame Relay header 485 The optimized Frame Relay control word described in [BRYANT] is: 487 0 1 2 3 488 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 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | length |C|X|X|X|X|X|F|B|D|X| Sequence Number | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 this must be transformed to : 495 0 1 496 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | hi dlci |C|0|lo dlci|F|B|D|1| 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 draft-bryant-pwe3-fr-compare-00.txt October 2001 502 If two-octet operations are available to the processor, it is simply 503 necessary to isolate the CFB and D bits in the control word through 504 an AND operation and write them into the Frame Relay header. 506 - Move first word of control word to temporary location. 507 - AND to isolate CFBD bits. 508 - Write bits into Frame Relay header. 510 The operation to create the Control Word has similar steps, making a 511 comparative total cost of 6 operations, rising to a comparative cost 512 of 12 operations if only single-octet, rather than word, operators 513 are available. 515 This is the fastest control word design for use with the [MARTINI] 516 and [KAWA] approach of transmitting Frame Relay over pseudo-wire via 517 an intermediate format. 519 6.4 Mapping between the General Pseudo-wire Payload Encapsulation and 520 Frame Relay 522 The general pseudo-wire encapsulation technique also discussed in 523 [BRYANT] transports the Frame Relay header intact, and does not move 524 any of the payload specific bits to the control word. This 525 effectively has a Frame Relay header bit processing cost of zero. 527 7. Frame Relay header translation 529 A common justification for the use of an intermediate format for the 530 transmission of a Frame Relay header is the need to translate the 531 header from one format to another across the pseudo-wire. 533 There are two Frame Relay header formats in common usage: the two- 534 octet version used in the examples in this draft, and the four-octet 535 version. 537 If the intermediate format is used, the encapsulator has to 538 implement two cases (two-octet to intermediate and four-octet to 539 intermediate), and the decapsulator has to implement two cases 540 (intermediate to two-octet, and intermediate to four-octet). If the 541 frame is transmitted across the pseudo-wire un-translated, then 542 there are three translation cases (Nothing, 2->4 and 4->2). This 543 results in a net reduction in translation and implementation 544 complexity, and an increase in performance. 546 It is useful to review the memory organization of the two-octet and 547 four-octet Frame Relay headers, to fully appreciate the complexity 548 of the translation operation. In normal IETF notation, the two- 549 octet frame relay header is (yet again): 551 draft-bryant-pwe3-fr-compare-00.txt October 2001 553 0 1 554 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | hi dlci |C|0|lo dlci|F|B|D|1| 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 and for comparison the four-octet frame relay header is: 561 0 1 2 3 562 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 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | hi dlci |C 0| dlci |F|B|D|0| dlci |0| dlci_lo |0|1| 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 Bit 30 is the D/C bit. This is set to zero to indicate that the last 568 octet contains DLCI, rather than control, information. 570 Note that the two least-significant (leftmost) octets in the header 571 have an almost identical format, the only difference being that the 572 EA bit in bit 15 is a zero to indicate a four-octet header. 574 Translating from a two-byte Frame Relay header to a four-byte frame 575 relay header requires the following operations: 577 - Move first word of the header to temporary location. 578 - AND to clear bit 15 (EA = 0). 579 - Write word into Frame Relay header at new buffer offset. 581 Correct setting of the remaining EA bits (bits 23 and 31) and the 582 DLCI Core indicator (D/C) bit (bit 30) can be considered an integral 583 part of writing the least significant thirteen bits of the DLCI. 584 Translation from a two-octet Frame Relay header to a four-octet 585 Frame relay header has similar complexity: 587 - Move first word of the header to temporary location. 588 - OR to set bit 15 (EA = 0). 589 - Write word into Frame Relay header at new buffer offset. 591 The minimal additional computational cost of translation is 592 therefore one additional branch plus one read plus one write, i.e. 593 branch plus 3 operations. This cost is much lower than the cost 594 Of translating to and from an intermediate format. 596 draft-bryant-pwe3-fr-compare-00.txt October 2001 598 8. Conclusions 600 Based on this analysis the authors make the following 601 recommendations to the IETF PWE3 Working Group: 603 Based on the reduced computational complexity, the simplicity of 604 translation and the compatibility with the VLAN encapsulation type, 605 the pseudo-wire Frame Relay service should transmit the frame as 606 received rather than in an intermediate format, and perform any 607 necessary translations as a local operation during the decapsulation 608 processing. The general-purpose encapsulation presented in [BRYANT] 609 is ideal for this, and should be used. 611 If the use of an intermediate Frame Relay format is objectively 612 judged desirable, the optimised frame-relay-specific intermediate 613 control word proposed by [BRYANT] is computationally more efficient 614 than that proposed by [KAWA] and [MARTINI], and should therefore be 615 adopted. 617 If the use of an intermediate Frame Relay format is objectively 618 judged desirable, and there are also good reasons why the reserved 619 bits are required and why the length field should remain unchanged, 620 then the payload-dependent bit layout proposed in [KAWA] is 621 computationally preferable to that proposed by [MARTINI], so [KAWA] 622 is therefore preferred. 624 The naming and polarity of the fragmentation bits proposed by [KAWA] 625 should be changed to the definitions proposed in this draft to 626 reduce computational complexity. (We understand from recent list 627 discussion that this is in progress.) 629 If a fragmentation mechanism is needed in PWE3, then it should be 630 defined as a general method used by all encapsulation types. The 631 general-purpose encapsulation presented in [BRYANT] is ideal for 632 this, and should be used. 634 9. IANA considerations 636 There are no IANA considerations for this document. 638 10. Security considerations 640 There are no security implications for this document. 642 draft-bryant-pwe3-fr-compare-00.txt October 2001 644 11. References 646 Internet-drafts are works in progress available from 647 http://www.ietf.org/internet-drafts/ 649 [BRYANT] S. Bryant and Wood, L. 'Two Efficient PWE3 Frame Relay 650 Encapsulations', work in progress as an internet-draft: 651 653 [GRE] D. Farinacci et al, 'Generic Routing Encapsulation (GRE)', 654 IETF RFC2784, standards-track. 656 [KAWA] C. Kawa, Malis, A., et al., 'Frame relay over Pseudo-Wire 657 Emulation Edge-to-Edge', work in progress as an internet-draft: 658 660 [MARTINI] L. Martini, Tappan, D., et al. 'Encapsulation Methods for 661 Transport of Layer 2 Frames Over IP and MPLS Networks', work in 662 progress as an internet-draft: 663 665 [Q.922] ITU-T Recommendation Q.922, ISDN Data Link Layer 666 Specification for Frame Mode Bearer Services, ITU, Geneva, 1992. 668 Authors' addresses 670 Stewart Bryant 671 Cisco Systems Ltd 672 4, The Square 673 Stockley Park 674 Uxbridge UB11 1BL Email: stbryant@cisco.com 675 United Kingdom Phone: +44-20-8756-8828 677 Lloyd Wood 678 Cisco Systems Ltd 679 4, The Square 680 Stockley Park 681 Uxbridge UB11 1BL Email: lwood@cisco.com 682 United Kingdom Phone: +44-20-8734-4236 683 draft-bryant-pwe3-fr-compare-00.txt October 2001 685 Full copyright statement 687 Copyright (C) The Internet Society (2001). 688 All Rights Reserved. 690 This document and translations of it may be copied and furnished to 691 others, and derivative works that comment on or otherwise explain it 692 or assist in its implementation may be prepared, copied, published 693 and distributed, in whole or in part, without restriction of any 694 kind, provided that the above copyright notice and this paragraph 695 are included on all such copies and derivative works. However, this 696 document itself may not be modified in any way, such as by removing 697 the copyright notice or references to the Internet Society or other 698 Internet organizations, except as needed for the purpose of 699 developing Internet standards in which case the procedures for 700 copyrights defined in the Internet Standards process must be 701 followed, or as required to translate it into languages other than 702 English. 704 The limited permissions granted above are perpetual and will not be 705 revoked by the Internet Society or its successors or assigns. 707 This document and the information contained herein is provided on an 708 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 709 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 710 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 711 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 712 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.