idnits 2.17.00 (12 Aug 2021) /tmp/idnits38882/draft-bryant-pwe3-fr-encap-01.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. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([LAYER]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 102 has weird spacing: '...Edge to att...' -- 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 (March 2002) is 7365 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) == Missing Reference: 'Q922' is mentioned on line 308, but not defined == Unused Reference: 'Q933' is defined on line 250, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'KAWA' -- Possible downref: Non-RFC (?) normative reference: ref. 'LAYER' -- Possible downref: Non-RFC (?) normative reference: ref. 'MARTINI' -- Possible downref: Non-RFC (?) normative reference: ref. 'Q933' -- Possible downref: Non-RFC (?) normative reference: ref. 'TOWNSLEY' Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Stewart Bryant 3 Document: Lloyd Wood 4 Expires: September 2002 George Wilkie 5 Cisco Systems 7 March 2002 9 A Proposed Frame Relay Encapsulation for PWE3 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress. 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt The list of 27 Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This draft describes a pseudo-wire emulation edge-to-edge (PWE3) 33 frame relay encapsulation that conforms to the PWE3 Protocol Layering 34 proposed by Bryant et al [LAYER], and discuses the services required 35 from the underlaying PWE3 layers. 37 Table of Contents 39 1. Introduction............................................. 2 41 2. Terminology.............................................. 2 43 3. PW Encapsulation......................................... 3 44 3.1 Payload Convergence Sub-layer........................ 3 45 3.2 Payload Independent PW Encapsulation Layers.......... 4 47 4. PSN Tunnel Layer Requirements............................ 5 48 4.1 Multiplexing......................................... 5 49 4.2 Segmentation and Reassembly.......................... 5 50 4.3 Length and Delivery................................... 5 52 5. Control Plane............................................ 6 54 6. IANA considerations...................................... 6 56 7. Security................................................. 6 58 Appendix A: Intermediate Formats Considered Harmful.......... 7 60 1. Introduction 62 A frame relay pseudo-wire allows frame relay protocol control 63 information and payloads to be carried over a Packet Switched 64 Network. This draft describes how our preferred frame relay 65 encapsulation is carried over the proposed PWE3 protocol layering 66 model [LAYER], and discusses the services required from the 67 underlying PWE3 layers. 69 2. Terminology 71 The following definitions are used in t his document: 73 BECN Backward Explicit Congestion Notification 74 bit in frame relay header. 76 Customer Edge (CE) A device where one end of a service 77 originates and terminates. The CE is not 78 aware that it is using an emulated service 79 rather than a native service. 81 DE Discard Eligibility bit in frame relay header. 83 Native Service Processing of the data received by the PE 84 Processing (NSP) from the CE before presentation to the PW 85 for transmission across the core. 87 FECN Forward Explicit Congestion Notification 88 bit in frame relay header. 90 Packet Switched A network using IP or MPLS as the mechanism 91 Network (PSN) of packet forwarding. 93 Protocol Data The unit of data output to, or received 94 Unit (PDU) from, the network by a protocol layer. 96 Provider Edge (PE) A device that provides PWE3 to a CE. 98 Pseudo Wire (PW) A connection between two PEs carried over 99 PSN. 101 Pseudo Wire A mechanism that emulates the essential 102 Emulation Edge to attributes of service (such as a T1 leased 103 Edge (PWE3) line or frame relay) over a PSN. 105 PSN Tunnel A tunnel across a PSN inside which one or 106 more PWs can be carried. 108 PWE3 Payload The protocol sub-layers within PWE3 109 Independent responsible for sequencing and timing. 110 Sub-layers 112 3. PW Encapsulation 114 3.1 Payload Convergence Sub-layer 116 Frame Relay uses the PWE3 generic packet payload service [LAYER], 117 employing the principle of minimum intervention. The native frame 118 relay PDU is transported as received, excluding only HDLC flags and 119 the frame-check sequence (FCS). Bit stuffing is undone. (This 120 contrasts with the proposal of Kawa et al [KAWA], which uses an 121 intermediate PW format.) 123 If the underlying PSN provides a congestion notification service, the 124 congestion state must to be passed up to the Payload Convergence 125 Sub-layer by the intermediate layers. The Payload Convergence Sub- 126 layer may set the frame relay Forward Explicit Congestion 127 Notification (FECN) bit if the packet has experienced congestion 128 traveling across the PSN to the destination PE. It may also set the 129 Backward Explicit Congestion Notification (BECN) bit on frame relay 130 packets on the reverse path of the same PW. 132 The encapsulation layer may request the use of different PSN QoS 133 settings, depending on the setting of the Discard Eligibility (DE) 134 bit in the frame relay header. 136 The Emulated Service (as defined in figure 1 of [LAYER]) is 137 responsible for providing the following frame relay service policies. 139 o CIR (Committed Information Rate) or throughput. 140 o Bc (Committed burst size). 141 o Be (Excess Burst Size). 142 o Maximum frame size. 144 Typically, the NSP would be responsible for policing the traffic to 145 CIR, Bc, Be before passing to the PW. Some indication of the 146 committed burst size (which should get guaranteed delivery) and the 147 excess burst size (which may be delivered with lower probability) 148 would be provided by the NSP to the PW. The PW and the remote NSP are 149 then responsible for ensuring that committed traffic arrives at the 150 remote CE. In other implementations, typically those operating over a 151 high bandwidth core, all the service policy processing could be 152 delegated to the destination PE. 154 If the frame relay PDU conforms to the maximum frame size, but the PW 155 encapsulated frame relay PDU exceeds the PSN maximum PDU length, the 156 segmentation and reassembly considerations described in [LAYER] are 157 followed. 159 3.2 Payload Independent PW Encapsulation Layers 161 Frame Relay requires the use of sequencing from the payload 162 independent encapsulation layer to maintain packet order, which is an 163 invariant of Frame Relay networks. 165 In some cases, the protocol carried over the frame relay VC is known 166 to be insensitive to packet order (for example if the traffic is 167 KNOWN to be IP), in which case there may be a desire to reduce the 168 overhead associated with the transmission and receive processing of 169 ordered packets. The use of the sequencing service is therefore 170 optional. 172 The encapsulation of frame relay has no timed delivery or clock 173 recovery requirements. It therefore does not use the PWE3 Timing 174 Sublayer. 176 4. PSN Tunnel Layer Requirements 178 4.1 Multiplexing 180 The frame relay Encapsulation Layer depends on the multiplexing 181 functionality in the PSN Tunnel Layer to provide multiple PWs between 182 PEs. There are two types of frame relay PW: 184 o Trunks, in which multiple frame relay VCs are sent over the PW. 185 The normal usage of this is where all traffic on a physical 186 interface to the PE is sent over the PW to a corresponding 187 physical interface on the destination PE. 189 A PE may contain an NSP that provides a frame relay switch 190 function, and presents a frame relay trunk to the PW 191 Encapsulation Layer via a virtual interface. 193 o Single DLCI, in which the PW carries just the traffic of a 194 single VC. 196 4.2 Segmentation and Reassembly 198 It is desirable that the MTU of the frame-relay packets received from 199 the CE is constrained so that the packets can be carried over the PSN 200 without fragmentation. If this is not possible, the segmentation and 201 reassembly service of the underlying PSN is used. 203 4.3 Length and Delivery 205 The underlying PSN is responsible for determining the correct length 206 of a frame relay PDU and delivering the PDU to the PSN Tunnel Layer. 208 5. Control Plane 210 Mechanisms are needed to set up and tear down frame relay PWs and to 211 carry PVC status across the PW. 213 An example of the necessary extensions needed to support a frame 214 relay PW across an L2TP PSN tunnel is given in [TOWNSLEY]. 216 Aspects of the PW control plane specific to frame relay form a work 217 area that needs further study. 219 6. IANA considerations 221 IANA considerations are for further study. 223 7. Security 225 PWE3 provides no means of protecting the contents or delivery of the 226 PDU's on behalf of the native service. PWE3 may, however, leverage 227 security mechanisms provided by the PSN Tunnel Layer. 229 A more detailed discussion of PW security is give in [LAYER]. 231 References 233 Internet-drafts are works in progress available from 234 236 [KAWA] Kawa et al, Frame relay over Pseudo-Wire Emulation Edge-to-Edge, 237 , work in progress 239 [LAYER] Bryant et al, Protocol Layering in PWE3, 240 , work in progress 242 [MARTINI] L. Martini, Tappan, D., et al. 'Encapsulation Methods for 243 Transport of Layer 2 Frames Over IP and MPLS Networks', work in 244 progress as an internet-draft: 245 , work in progress 247 [Q.922] ITU-T Recommendation Q.922, ISDN Data Link Layer 248 Specification for Frame Mode Bearer Services, ITU, Geneva, 1992. 250 [Q933] ITU-T Recommendation Q.933, ISDN Signaling Specification 251 for Frame Mode Bearer Services, Geneva, October 1995. 253 [TOWNSLEY] Townsley et al, Frame-Relay Pseudo-Wire Extensions 254 for L2TP , work in progress 256 Appendix A: Intermediate Formats Considered Harmful 258 The design of the pseudo-wire encapsulation header can have 259 considerable impact on the performance of the system using it. 260 The most computationally-efficient encapsulation approach is the 261 use of the PWE3 generic packet payload service [LAYER], which 262 is the approach that we propose in this draft. This approach 263 conforms to the principle of minimum intervention, and is 264 is similar to the general pseudo-wire encapsulation approach 265 proposed by [MARTINI] for HDLC, Ethernet and VLAN. 267 This appendix analyses the computational efficiency gain of the 268 generic packet approach, and demonstrates the relative 269 efficiency of the generic packet approach. 271 A.1 The Martini Frame Relay Encapsulation 273 [MARTINI] takes the approach of copying the frame relay payload- 274 dependent bits to fields in a the control word, stripping the frame 275 Relay header from the fame Relay PDU, and reconstructing the header 276 at the far end of the pseudo-wire. The reason for this approach is 277 not given in [MARTINI]. 279 The layout and ordering of the B, F, D and C bits in the control 280 word differ from the layout and ordering of these bits in the frame 281 Relay header. This results in unnecessary bit manipulation in both 282 encapsulation and decapsulation and introduces unnecessary processing 283 overhead in any implementation. 285 The control word defined in [MARTINI] is: 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 | Rsvd |D|B|F|C| Length | Sequence Number | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 The two-octet frame relay header in normal IETF (DoD) notation is: 295 0 1 296 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | hi dlci |C|0|lo dlci|F|B|D|1| 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 where: 302 C = FR frame C/R (command/response) bit [Q.922]. 304 F = FECN (Forward Explicit Congestion Notification) bit [Q.922]. 306 B = BECN (Backward Explicit Congestion Notification) bit [Q.922]. 308 D = DE indicates the Discard Eligibility [Q922]. 310 Frame relay header bits 7 and 15 are the Q.922 EA (Extended Address) 311 bits used for address field extension. In the unextended two-octet 312 header these are defined to be 0 and 1 respectively. 314 Processors rarely have efficient bit manipulation operations, so you 315 cannot normally just assign the bits to their new positions easily. 316 It therefore becomes necessary to isolate each of the DBFC bits in 317 the control word using an AND operation, to use a shift operator to 318 move each bit to its correct position in the frame relay header, and 319 then to load the isolated bit into the header buffer using an OR 320 operator. This requires four operations on each of four bits: 322 - Move first octet of control word to temporary location. 323 - AND to isolate bit. 324 - Shift bit to corresponding location in frame relay header octet. 325 - Write or OR bit into frame relay header. 327 A similar number of operations in needed in constructing the Control 328 Word from the received frame relay header. For comparison we can 329 regard this construction as having a cost of: (4 bits * 4 330 operations) + (4 bits * 4 operations) = 32 operations. 332 Note that we have not included the processing of the DLCI bits 333 (normally an OR operation) in this analysis, since that is an 334 overhead common to all transmission formats. Also note that, for the 335 purposes of frame relay header manipulation, the EA bits can normally 336 be included in the pro-forma DLCI definition. 338 A.2 The Kawa encapsulation 340 As with the [MARTINI] approach, the frame relay payload-dependent 341 bits are copied to fields in a control word, the frame relay header 342 is stripped from the frame relay PDU, and the header is reconstructed 343 at the far end of the pseudo-wire. Again, the reason for doing this 344 is not given. It has been proposed that [KAWA] be changed to follow 345 the [MARTINI] control word, but at the time of writing this updated 346 approach has not yet been published. 348 The grouping and ordering of the payload-dependent bits in the [KAWA] 349 control word is more consistent with Q.922, allowing them to be 350 processed as a three bit group (FBD) and a single bit (C). This 351 reduces the processing overhead in comparison with [MARTINI]. 352 However, the [KAWA] draft fails to take advantage of the additional 353 performance gains to be made by closely following the layout 354 specified in [Q.922]. 356 The Kawa control word is: 358 0 1 2 3 359 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 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Res |P|F|B|D|C|X|Y| Length | Sequence Number | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Again for comparison, the two-octet frame relay header in normal IETF 365 (DoD) notation is: 367 0 1 368 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | hi dlci |C|0|lo dlci|F|B|D|1| 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 In this case we can isolate the FBD bits as group, and knowing that 374 they are in the same position and order in the octet in both Control 375 Word and the frame relay header, we can write them directly to the 376 header buffer in three operations: 378 - Move first octet of control word to temporary location. 379 - AND to isolate FBD bits. 380 - Write bits into frame relay header. 382 The C bit requires isolation with an AND operator, shifting and 383 writing into the header buffer (4 operations). 385 - Move second octet of control word to temporary location. 386 - AND to isolate C bit. 387 - Shift bit to corresponding location in frame relay header octet. 388 - Write C bit into frame relay header. 390 This same number of operations is needed in construction of the 391 control word making a comparative cost of: (3 + 4) + (3 + 4) 392 operations = 14 operations. 394 14 operations compares well with the 32 operations needed for the 395 [MARTINI] implementation. 397 A.3 Cost of using PWE3 Generic Packet Payload 399 The use of the general pseudo-wire encapsulation technique as 400 proposed in this document has a frame relay header bit processing 401 cost of zero. It is therefore the most processor-efficient approach. 403 A.4 Frame Relay Header Translation 405 A common justification for the use of an intermediate format for the 406 transmission of a frame relay datagram across a PW is the need to 407 translate the header from one format to another. 409 There are two frame relay header formats in common use: the two- 410 octet version used in the examples in this draft, and the four-octet 411 version. 413 If the intermediate format is used, the encapsulator has to implement 414 two cases (two-octet to intermediate and four-octet to intermediate), 415 and the decapsulator has to implement two cases (intermediate to 416 two-octet, and intermediate to four-octet). If the frame is 417 transmitted across the pseudo-wire un-translated, then there are 418 three translation cases (Nothing, 2->4 and 4->2). This results in a 419 net reduction in translation and implementation complexity, and an 420 increase in performance. 422 It is useful to review the memory organization of the two-octet and 423 four-octet frame relay headers, to fully appreciate the complexity of 424 the translation operation. In normal IETF notation, the two-octet 425 frame relay header is: 427 0 1 428 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | hi dlci |C|0|lo dlci|F|B|D|1| 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 and the four-octet frame relay header is 435 0 1 2 3 436 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 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | hi dlci |C|0| dlci |F|B|D|0| dlci |0| dlci_lo |0|1| 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 Bit 30 is the D/C bit. This is set to zero to indicate that the last 442 octet contains DLCI, rather than control, information. 444 As can be seen by inspecting these definitions, the translation of a 445 two-octet frame relay header to a four-octet frame relay header is a 446 relatively simple operation requiring. 448 - Move first word of the header to temporary location. 449 - AND to clear bit 15 (EA = 0). 450 - Write word into frame relay header at new buffer offset. 452 Correct setting of the remaining EA bits (bits 23 and 31) and the 453 DLCI Core indicator (D/C) bit (bit 30) can be considered an integral 454 part of writing the least significant thirteen bits of the DLCI. 456 Translation from a two-octet frame relay header to a four-octet frame 457 relay header has similar complexity: 459 - Move first word of the header to temporary location. 460 - OR to set bit 15 (EA = 0). 461 - Write word into frame relay header at new buffer offset. 463 Given the simplicity of the frame relay header translation process, 464 they would seem to be no justification for the use of an intermediate 465 PW format for the frame relay header. 467 Authors' Addresses 469 Stewart Bryant 470 Cisco Systems, 471 4, The Square, 472 Stockley Park, 473 Uxbridge UB11 1BL, Email: stbryant@cisco.com 474 United Kingdom. Phone: +44-20-8756-8828 476 George Wilkie 477 Cisco Systems 478 96 Commercial Street, 479 Leith, 480 Edinburgh, EH6 6LX 481 United Kingdom Email: gwilkie@cisco.com 483 Lloyd Wood 484 Cisco Systems, 485 4, The Square, 486 Stockley Park, 487 Uxbridge UB11 1BL, Email: lwood@cisco.com 488 United Kingdom. Phone: +44-20-8734-4236 489 Full copyright statement 491 Copyright (C) The Internet Society (2002). All Rights Reserved. 493 This document and translations of it may be copied and furnished to 494 others, and derivative works that comment on or otherwise explain it 495 or assist in its implementation may be prepared, copied, published 496 and distributed, in whole or in part, without restriction of any 497 kind, provided that the above copyright notice and this paragraph are 498 included on all such copies and derivative works. However, this 499 document itself may not be modified in any way, such as by removing 500 the copyright notice or references to the Internet Society or other 501 Internet organizations, except as needed for the purpose of 502 developing Internet standards in which case the procedures for 503 copyrights defined in the Internet Standards process must be 504 followed, or as required to translate it into languages other than 505 English. 507 The limited permissions granted above are perpetual and will not be 508 revoked by the Internet Society or its successors or assigns. 510 This document and the information contained herein is provided on an 511 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 512 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 513 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 514 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 515 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.