idnits 2.17.1 draft-ietf-pwe3-ethernet-encap-06.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 == The page length should not exceed 58 lines per page, but there was 19 longer pages, the longest (page 6) being 70 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 19 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 208: '...mode, each frame MUST contain an 802.1...' RFC 2119 keyword, line 212: '... frame MAY contain an 802.1Q VLAN ta...' RFC 2119 keyword, line 266: '... the CE by the PE, it MUST be stripped...' RFC 2119 keyword, line 270: '... the PW MUST have a service-delimiti...' RFC 2119 keyword, line 274: '... is the only REQUIRED mode....' (36 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: In both modes, the service-delimiting tag values have only local significance, i.e., are meaningful only at a particular PE-CE interface. When tagged mode is used, the PE that receives a frame from the PW may rewrite the tag value, or may strip the tag entirely, or may leave the tag unchanged, depending on its configuration. When raw mode is used, the PE that receives a frame may or may not need to add a service-delimiting tag before transmitting the frame to the CE; however it MUST not rewrite or remove any tags which are already present. -- 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 (April 2004) is 7317 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: 'PWE3-CTRL' is mentioned on line 333, but not defined == Missing Reference: 'PWE3-MIB' is mentioned on line 340, but not defined == Outdated reference: A later version (-17) exists of draft-ietf-pwe3-control-protocol-05 ** Downref: Normative reference to an Informational draft: draft-ietf-pwe3-arch (ref. 'PWE3-ARCH') ** Downref: Normative reference to an Informational draft: draft-ietf-pwe3-requirements (ref. 'PWE3-REQ') == Outdated reference: A later version (-14) exists of draft-ietf-pwe3-pw-mib-04 == Outdated reference: A later version (-15) exists of draft-ietf-l2tpext-l2tp-base-12 Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Luca Martini 2 Internet Draft Eric C. Rosen 3 Expiration Date: October 2004 Cisco Systems, Inc. 5 Nasser El-Aawar Giles Heron 6 Level 3 Communications, LLC. Tellabs 8 April 2004 10 Encapsulation Methods for Transport of Ethernet Frames Over IP/MPLS Networks 12 draft-ietf-pwe3-ethernet-encap-06.txt 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 An Ethernet Pseudowire (PW) is used to carry Ethernet/802.3 Protocol 37 Data Units over an IP or MPLS network. This enables service providers 38 to offer "emulated" ethernet services over existing IP or MPLS 39 networks. This document specifies the encapsulation of Ethernet/802.3 40 PDUs within a pseudowire. It also specifies the procedures for using 41 a PW to provide a "point-to-point ethernet" service. 43 Table of Contents 45 1 Specification of Requirements .......................... 2 46 2 Introduction ........................................... 2 47 3 Requirements for Ethernet PWs Emulating P2P Ethernet Links .4 48 3.1 Frame Processing at the PW Endpoints ................... 6 49 3.1.1 Generic Procedures ..................................... 6 50 3.1.2 Raw Mode vs. Tagged Mode ............................... 6 51 3.1.3 MTU Management on the PE/CE Links ...................... 7 52 3.1.4 Frame Ordering ......................................... 7 53 3.1.5 Frame Error Processing ................................. 8 54 3.1.6 IEEE 802.3x Flow Control Interworking .................. 8 55 3.2 PW Setup and Maintenance ............................... 8 56 3.3 Management ............................................. 8 57 3.4 The Control Word ....................................... 9 58 3.4.1 Setting the sequence number ............................ 9 59 3.4.2 Processing the sequence number ......................... 10 60 3.5 QoS Considerations ..................................... 11 61 3.6 Security Considerations ................................ 11 62 3.7 PSN MTU Requirements ................................... 12 63 4 Intellectual Property Disclaimer ....................... 12 64 5 References ............................................. 12 65 6 Author Information ..................................... 13 66 Appendix A - Interoperability Guidelines ............... 16 67 Appendix B - QoS Details ............................... 17 69 1. Specification of Requirements 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in RFC 2119 75 2. Introduction 77 An Ethernet Pseudowire (PW) allows Ethernet/802.3 Protocol Data Units 78 (PDUs) to be carried over an IP network or an MPLS network. In 79 addressing the issues associated with carrying an Ethernet PDU over a 80 PSN, this document assumes that a Pseudowire (PW) has been set up by 81 some means outside the scope of this document. This may be via manual 82 configuration, or a signaling protocol such as that defined in 83 [PWE3-CTRL] or [L2TPv3]. As described in [PWE3-ARCH], this PW may be 84 tunneled through an MPLS, IPv4 or IPv6 PSN. 86 In addition to the Ethernet PDU format used within the pseudowire, 87 this document discusses: 89 - Procedures for using a PW in order to provide a pair of CEs with 90 an emulated (point-to-point) ethernet service, including the 91 procedures for the processing of PE-bound and CE-bound ethernet 92 PDUs. [PWE3-ARCH] 94 - Ethernet-specific QoS and security considerations 96 - Inter-domain transport considerations for Ethernet PW 98 The following two figures describe the reference models which are 99 derived from [PWE3-ARCH] to support the Ethernet PW emulated 100 services. 102 |<-------------- Emulated Service ---------------->| 103 | | 104 | |<------- Pseudo Wire ------>| | 105 | | | | 106 | | |<-- PSN Tunnel -->| | | 107 | PW End V V V V PW End | 108 V Service +----+ +----+ Service V 109 +-----+ | | PE1|==================| PE2| | +-----+ 110 | |----------|............PW1.............|----------| | 111 | CE1 | | | | | | | | CE2 | 112 | |----------|............PW2.............|----------| | 113 +-----+ ^ | | |==================| | | ^ +-----+ 114 ^ | +----+ +----+ | | ^ 115 | | Provider Edge 1 Provider Edge 2 | | 116 | | | | 117 Customer | | Customer 118 Edge 1 | | Edge 2 119 | | 120 | | 121 native ethernet service native ethernet service 123 Figure 1: PWE3 Ethernet/VLAN Interface Reference Configuration 125 The "emulated service" shown in Figure 1 is, strictly speaking, a 126 bridged LAN; the PEs have MAC interfaces, consume MAC control frames, 127 etc. However, the procedures specified herein only support the case 128 in which there are two CEs on the "emulated LAN". Hence we refer to 129 this service as "emulated point-to-point ethernet". Specification of 130 the procedures for using pseudowires to emulate LANs with more than 131 two CEs are out of scope of the current document. 133 +-------------+ +-------------+ 134 | Emulated | | Emulated | 135 | Ethernet | | Ethernet | 136 | (including | Emulated Service | (including | 137 | VLAN) |<==============================>| VLAN) | 138 | Services | | Services | 139 +-------------+ Pseudo Wire +-------------+ 140 |Demultiplexer|<==============================>|Demultiplexor| 141 +-------------+ +-------------+ 142 | PSN | PSN Tunnel | PSN | 143 | MPLS or IP |<==============================>| MPLS or IP | 144 +-------------+ +-------------+ 145 | Physical | | Physical | 146 +-----+-------+ +-----+-------+ 148 Figure 2: Ethernet PWE3 Protocol Stack Reference Model 150 For the purpose of this document, PE1 will be defined as the ingress 151 router, and PE2 as the egress router. A layer 2 PDU will be received 152 at PE1, encapsulated at PE1, transported, decapsulated at PE2, and 153 transmitted out of PE2. 155 3. Requirements for Ethernet PWs Emulating P2P Ethernet Links 157 An Ethernet PW emulates a single Ethernet link between exactly two 158 endpoints. The mechanisms described in this document are agnostic to 159 that which is beneath the "Pseudo Wire" level in Figure 2, concerning 160 itself only with the "Emulated Service" portion of the stack. 162 The following reference model describes the termination point of each 163 end of the PW within the PE: 165 +-----------------------------------+ 166 | PE | 167 +---+ +-+ +-----+ +------+ +------+ +-+ 168 | | |P| | | |PW ter| | PSN | |P| 169 | |<==|h|<=| NSP |<=|minati|<=|Tunnel|<=|h|<== From PSN 170 | | |y| | | |on | | | |y| 171 | C | +-+ +-----+ +------+ +------+ +-+ 172 | E | | | 173 | | +-+ +-----+ +------+ +------+ +-+ 174 | | |P| | | |PW ter| | PSN | |P| 175 | |==>|h|=>| NSP |=>|minati|=>|Tunnel|=>|h|==> To PSN 176 | | |y| | | |on | | | |y| 177 +---+ +-+ +-----+ +------+ +------+ +-+ 178 | | 179 +-----------------------------------+ 180 ^ ^ ^ 181 | | | 182 A B C 184 Figure 3: PW reference diagram 186 The PW terminates at a logical port within the PE, defined at point A 187 in the above diagram. This port provides an Ethernet MAC service that 188 will deliver each Ethernet frame that is received at point A, 189 unaltered, to the point A in the corresponding PE at the other end of 190 the PW. 192 The "NSP" function includes frame processing that is required for the 193 Ethernet frames that are forwarded to the PW termination point. Such 194 functions may include stripping, overwriting or adding VLAN tags, 195 physical port multiplexing and demultiplexing, PW-PW bridging, L2 196 encapsulation, shaping, policing, etc. 198 The points to the left of A, including the physical layer between the 199 CE and PE, and any adaptation (NSP) functions between it and the PW 200 terminations, are outside of the scope of PWE3 and are not defined 201 here. 203 "PW Termination", between A and B, represents the operations for 204 setting up and maintaining the PW, and for encapsulating and 205 decapsulating the Ethernet frames according to the PSN type in use. 207 An ethernet PW can operate in one of two modes: "raw mode" or "tagged 208 mode". In tagged mode, each frame MUST contain an 802.1Q VLAN tag, 209 and the tag value is meaningful to the NSPs at the two PW endpoints. 210 That is, the two endpoints must have some agreement (signaled or 211 manually configured) on how to process the tag. On a raw mode PW, a 212 frame MAY contain an 802.1Q VLAN tag, but if it does, the tag is not 213 meaningful to the NSPs, and passes transparently through them. 215 3.1. Frame Processing at the PW Endpoints 217 3.1.1. Generic Procedures 219 When the NSP/Forwarder hands a frame to the PW endpoint: 221 - The preamble (if any) and FCS are stripped off. 223 - The control word as defined in the "The Control Word" section is, 224 if necessary, prepended to the resulting frame. The conditions 225 under which the control word is or is not used are specified 226 below. 228 - The proper Pseudowire demultiplexor is prepended to the resulting 229 packet. 231 - The proper tunnel encapsulation is prepended to the resulting 232 packet. 234 - The packet is transmitted. 236 The way in which the proper tunnel encapsulation and pseudowire 237 demultiplexor are chosen depends on the procedures that were used to 238 set up the pseudowire. 240 When a packet arrives over a PW, the tunnel encapsulation and PW 241 demultiplexor are stripped off. If the control word is present, any 242 processing required by control word is performed, and the control 243 word is stripped off. The resulting is then handed to the 244 Forwarder/NSP. Regeneration of the FCS is considered to be an NSP 245 responsibility. 247 3.1.2. Raw Mode vs. Tagged Mode 249 When the PE receives an ethernet frame from a CE, and the frame has a 250 VLAN tag, we can distinguish two cases: 252 1. The tag is "service-delimiting". This means that the tag was 253 placed on the frame by some piece of provider-operated 254 equipment, and the tag is used by the provider to distinguish 255 the traffic. For example, LANs from different customers might 256 be attached to the same provider switch, which applies VLAN 257 tags to distinguish one customer's traffic from another's, and 258 then forwards the frames to the PE. 260 2. The tag is not service-delimiting. This means that the tag was 261 placed in the frame by the CE (or other piece of customer 262 equipment), and is not meaningful to the PE. 264 If an ethernet PW is operating in raw mode, service-delimiting tags 265 are NEVER sent over the PW. If a service-delimiting tag is present 266 when the frame is received from the CE by the PE, it MUST be stripped 267 (by the NSP) from the frame before the frame is sent to the PW. 269 If an ethernet PW is operating in tagged mode, every frame sent on 270 the PW MUST have a service-delimiting VLAN tag. If the frame as 271 received by the PE from the CE does not have a service-delimiting 272 VLAN tag, the PE must prepend the frame with a dummy VLAN tag before 273 sending the frame on the PW. This is the default operating mode. This 274 is the only REQUIRED mode. 276 In both modes, non-service-delimiting tags are passed transparently 277 across the PW as part of the payload. 279 In both modes, the service-delimiting tag values have only local 280 significance, i.e., are meaningful only at a particular PE-CE 281 interface. When tagged mode is used, the PE that receives a frame 282 from the PW may rewrite the tag value, or may strip the tag entirely, 283 or may leave the tag unchanged, depending on its configuration. When 284 raw mode is used, the PE that receives a frame may or may not need to 285 add a service-delimiting tag before transmitting the frame to the CE; 286 however it MUST not rewrite or remove any tags which are already 287 present. 289 3.1.3. MTU Management on the PE/CE Links 291 The Ethernet PW MUST NOT be enabled unless it is known that the MTUs 292 of the CE-PE links are the same at both ends of the PW. 294 3.1.4. Frame Ordering 296 In general, applications running over Ethernet do not require strict 297 frame ordering. However the IEEE definition of 802.3 [802.3] requires 298 that frames from the same conversation are delivered in sequence. 299 Moreover, the PSN cannot (in the general case) be assumed to provide 300 or to guarantee frame ordering. An ethernet PW can, through use of 301 the control word, provide strict frame ordering. If this option is 302 enabled, any frames which get misordered by the PSN will be dropped 303 by the receiving PW endpoint. If strict frame ordering is a 304 requirement for a particular PW, this option MUST be enabled. 306 3.1.5. Frame Error Processing 308 An encapsulated Ethernet frame traversing a psuedo-wire may be 309 dropped, corrupted or delivered out-of-order. As described in [PWE3- 310 REQ], frame-loss, corruption, and out-of-order delivery is considered 311 to be a "generalized bit error" of the psuedo-wire. PW frames that 312 are corrupted will be detected at the PSN layer and dropped. 314 At the ingress of the PW the native Ethernet frame error processing 315 mechanisms MUST be enabled. Therefore, if a PE device receives an 316 Ethernet frame containing hardware level CRC errors, framing errors, 317 or a runt condition, the frame MUST be discarded on input. Note that 318 defining this processing is part of the NSP function and is outside 319 the scope of this draft. 321 3.1.6. IEEE 802.3x Flow Control Interworking 323 In a standard gigabit Ethernet network, the flow control mechanism is 324 optional and typically configured between the two nodes on a point- 325 to-point link (e.g. between the CE and the PE). IEEE 802.3x PAUSE 326 frames MUST NOT be carried across the PW. See Appendix A for notes on 327 CE-PE flow control. 329 3.2. PW Setup and Maintenance 331 This document assumes that a mechanism exists to set up the ethernet 332 PW. Maintenance of the PW (e.g. keepalives, status updates, etc) is 333 generally tied closely to the PW Setup mechanisms. [PWE3-CTRL] and 334 [L2TPv3] define two mechanisms for setup and maintenance of Ethernet 335 PWs. 337 3.3. Management 339 The Ethernet PW management model follows the general management 340 defined in [PWE3-ARCH] and [PWE3-MIB]. Many common PW management 341 facilities are provided here, with no additional Ethernet specifics 342 necessary. Ethernet-specific parameters are defined in an additional 343 MIB module, [PW-MIB]. 345 As specified in [PWE3-ARCH], an implementation SHOULD support the 346 generic and specific PW MIB modules for PW set-up and monitoring. 347 Other mechanisms for PW set up (command line interface for example) 348 MAY be supported. 350 3.4. The Control Word 352 When carrying Ethernet over an IP or MPLS backbone sequentiality may 353 need to be preserved. The OPTIONAL control word defined here 354 addresses this requirement. Implementations MUST support sending no 355 control word, and MAY support sending a control word. 357 In all cases the egress router must be aware of whether the ingress 358 router will send a control word over a specific virtual circuit. 359 This may be achieved by configuration of the routers, or by 360 signaling, for example as defined in [PWE3-CRTL]. 362 The control word is defined as follows: 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 |0 0 0 0| Reserved | Sequence Number | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 In the above diagram the first 4 bits MUST be set to 0 to indicate PW 371 data. The rest of the first 16 bits are reserved for future use. 372 They MUST be set to 0 when transmitting, and MUST be ignored upon 373 receipt. 375 The next 16 bits provide a sequence number that can be used to 376 guarantee ordered frame delivery. The processing of the sequence 377 number field is OPTIONAL. 379 The sequence number space is a 16 bit, unsigned circular space. The 380 sequence number value 0 is used to indicate that the sequence number 381 check alghorithm is not used. 383 3.4.1. Setting the sequence number 385 For a given PW, and a pair of routers PE1 and PE2, if PE1 supports 386 frame sequencing then the following procedures should be used: 388 - the initial frame transmitted on the PW MUST use sequence number 389 1 390 - subsequent frames MUST increment the sequence number by one for 391 each frame 392 - when the transmit sequence number reaches the maximum 16 bit 393 value (65535) the sequence number MUST wrap to 1 395 If the transmitting router PE1 does not support sequence number 396 processing, then the sequence number field in the control word MUST 397 be set to 0. 399 3.4.2. Processing the sequence number 401 If a router PE2 supports receive sequence number processing, then the 402 following procedures should be used: 404 When a PW is initially set up, the "expected sequence number" 405 associated with it MUST be initialized to 1. 407 When a frame is received on that PW, the sequence number should be 408 processed as follows: 410 - if the sequence number on the frame is 0, then the frame passes 411 the sequence number check 413 - otherwise if the frame sequence number >= the expected sequence 414 number and the frame sequence number - the expected sequence 415 number < 32768, then the frame is in order. 417 - otherwise if the frame sequence number < the expected sequence 418 number and the expected sequence number - the frame sequence 419 number >= 32768, then the frame is in order. 421 - otherwise the frame is out of order. 423 If a frame passes the sequence number check, or is in order then, it 424 can be delivered immediately. If the frame is in order, then the 425 expected sequence number should be set using the algorithm: 427 expected_sequence_number := frame_sequence_number + 1 mod 2**16 428 if (expected_sequence_number = 0) then expected_sequence_number := 1; 430 Packets which are received out of order MAY be dropped or reordered 431 at the discretion of the receiver. 433 If a router PE2 does not support receive sequence number processing, 434 then the sequence number field MAY be ignored. 436 3.5. QoS Considerations 438 The ingress PE MAY consider the user priority (PRI) field [802.1Q] of 439 the VLAN tag header when determining the value to be placed in a QoS 440 field of the encapsulating protocol (e.g., the EXP fields of the MPLS 441 label stack or the DSCP of an IP packet). In a similar way, the 442 egress PE MAY consider the QoS field of the PSN's encapsulating 443 protocol when queuing the frame for CE-bound. 445 A PE MUST support the ability to carry the Ethernet PW as a best 446 effort service over the PSN. PRI bits are kept transparent between 447 PE devices, regardless of the QoS support of the PSN. 449 If an 802.1Q VLAN field is added at the PE, a default PRI setting of 450 zero MUST be supported, a configured default value is recommended, or 451 the value may be mapped from the QoS field of the PSN, as referred to 452 above. 454 A PE may support additional QoS support by means of one or more of 455 the following methods: 457 -i. One COS per PW End Service (PWES), mapped to a single COS PW 458 at the PSN. 459 -ii. Multiple COS per PWES mapped to a single PW with multiple 460 COS at the PSN. 461 -iii. Multiple COS per PWES mapped to multiple PWs at the PSN. 463 Examples of the cases above and details of the service mapping 464 considerations are described in Appendix B. 466 The PW guaranteed rate at the PSN level is PW provider policy based 467 on agreement with the customer, and may be different from the 468 Ethernet physical port rate. 470 3.6. Security Considerations 472 The ethernet pseudowire type is subject to all of the general 473 security considerations discussed in [PWE3-ARCH]. 475 Security achieved by access control of MAC addresses is out of scope 476 of this document. Additional security requirements related to the use 477 of PW in a switching (virtual bridging) environment are not discussed 478 here as they are not within the scope of this draft. 480 3.7. PSN MTU Requirements 482 The PSN MUST be configured with an MTU that is large enough to 483 transport a maximum sized ethernet frame which has been encapsulated 484 with a control word, a pseudowire demultiplexor, and a tunnel 485 encapsulation. If MPLS is used as the tunneling protocol, for 486 example, this is likely to be 8 or more bytes greater than the 487 largest frame size. Other tunneling protocols may have longer headers 488 and require larger MTUs. If the ingress router determines that an 489 encapsulated layer 2 PDU exceeds the MTU of the tunnel through which 490 it must be sent, the PDU MUST be dropped. If an egress router 491 receives an encapsulated layer 2 PDU whose payload length (i.e., the 492 length of the PDU itself without any of the encapsulation headers), 493 exceeds the MTU of the destination layer 2 interface, the PDU MUST be 494 dropped. 496 4. Intellectual Property Disclaimer 498 This document is being submitted for use in IETF standards 499 discussions. 501 5. References 503 [PWE3-CRTL] "Transport of Layer 2 Frames Over MPLS", 504 Martini, L., et al., draft-ietf-pwe3-control-protocol-05.txt, 505 ( work in progress ), May 2003. 507 [PWE3-ARCH] "PWE3 Architecture" 508 Bryant, et al., draft-ietf-pwe3-arch-07.txt 509 ( work in progress ), March 2003. 511 [PWE3-REQ] "Requirements for Pseudo Wire Emulation Edge-to-Edge 512 (PWE3)", Xiao, X., McPherson, D., Pate, P., White, C., 513 Kompella, K., Gill, V., Nadeau, T., 514 draft-ietf-pwe3-requirements-08.txt, ( work in progress ), 515 September 516 2003. 518 [PW-MIB] "Pseudo Wire (PW) Management Information Base using SMIv2", 519 Zelig, D., Mantin, S., Nadeau, T., Danenberg, D., 520 draft-ietf-pwe3-pw-mib-04.txt, ( work in progress), February 521 2004. 523 [802.3] IEEE, ISO/IEC 8802-3: 2000 (E), "IEEE Standard for 524 Information technology -- Telecommunications and information 525 exchange between systems -- Local and metropolitan area networks 526 -- Specific requirements -- Part 3: Carrier Sense Multiple 527 Access with Collision Detection (CSMA/CD) Access Method and 528 Physical Layer Specifications", 2000. 530 [802.1Q] ANSI/IEEE Standard 802.1Q, "IEEE Standards for Local and 531 Metropolitan Area Networks: Virtual Bridged Local Area 532 Networks", 1998. 534 [L2TPv3] J. Lau, M. Townsley, A. Valencia, G. Zorn, I. Goyret, 535 G. Pall, A. Rubens, B. Palter, Layer Two Tunneling Protocol 536 (Version 3) "L2TPv3", work in progress, 537 draft-ietf-l2tpext-l2tp-base-12.txt, March 2004. 539 6. Author Information 541 Luca Martini 542 Cisco Systems, Inc. 543 9155 East Nichols Avenue, Suite 400 544 Englewood, CO, 80112 545 e-mail: lmartini@cisco.com 547 Nasser El-Aawar 548 Level 3 Communications, LLC. 549 1025 Eldorado Blvd. 550 Broomfield, CO, 80021 551 e-mail: nna@level3.net 553 Giles Heron 554 Tellabs 555 Abbey Place 556 24-28 Easton Street 557 High Wycombe 558 Bucks 559 HP11 1NT 560 UK 561 e-mail: giles.heron@tellabs.com 563 Dan Tappan 564 Cisco Systems, Inc. 565 1414 Massachusetts Avenue 566 Boxborough, MA 01719 567 e-mail: tappan@cisco.com 568 Eric C. Rosen 569 Cisco Systems, Inc. 570 1414 Massachusetts Avenue 571 Boxborough, MA 01719 572 e-mail: erosen@cisco.com 574 Steve Vogelsang 575 Laurel Networks, Inc. 576 Omega Corporate Center 577 1300 Omega Drive 578 Pittsburgh, PA 15205 579 e-mail: sjv@laurelnetworks.com 581 Andrew G. Malis 582 Tellabs 583 90 Rio Robles Dr. 584 San Jose, CA 95134 585 e-mail: Andy.Malis@tellabs.com 587 Vinai Sirkay 588 Reliance Infocomm 589 Dhirubai Ambani Knowledge City 590 Navi Mumbai 400 709 591 India 592 e-mail: vinai@sirkay.com 594 Vasile Radoaca 595 Nortel Networks 596 600 Technology Park 597 Billerica MA 01821 598 e-mail: vasile@nortelnetworks.com 600 Chris Liljenstolpe 601 Cable & Wireless 602 11700 Plaza America Drive 603 Reston, VA 20190 604 e-mail: chris@cw.net 605 Kireeti Kompella 606 Juniper Networks 607 1194 N. Mathilda Ave 608 Sunnyvale, CA 94089 609 e-mail: kireeti@juniper.net 611 Tricci So 612 e-mail: tricciso@yahoo.ca 614 XiPeng Xiao 615 Riverstone Networks 616 5200 Great America Parkway 617 Santa Clara, CA 95054 618 e-mail: xxiao@riverstonenet.com 620 Christopher O. Flores 621 T-Systems 622 10700 Parkridge Boulevard 623 Reston, VA 20191 624 USA 625 e-mail: christopher.flores@usa.telekom.de 627 David Zelig 628 Corrigent Systems 629 126, Yigal Alon St. 630 Tel Aviv, ISRAEL 631 e-mail: davidz@corrigent.com 633 Raj Sharma 634 Luminous Netwokrs, Inc. 635 10460 Bubb Road 636 Cupertino, CA 95014 637 e-mail: raj@luminous.com 639 Nick Tingle 640 TiMetra Networks 641 274 Ferguson Drive 642 Mountain View, CA 94043 643 e-mail: nick@timetra.com 644 Sunil Khandekar 645 TiMetra Networks 646 274 Ferguson Drive 647 Mountain View, CA 94043 648 email: sunil@timetra.com 650 Loa Andersson 651 TLA-group 652 e-mail: loa@pi.se 654 Appendix A - Interoperability Guidelines 656 Configuration Options 658 The following is a list of the configuration options for a point-to- 659 point Ethernet PW based on the reference points of Figure 3: 661 --------------|---------------|---------------|------------------ 662 Service and | Encap on C |Operation at B | Remarks 663 Encap on A | |ingress/egress | 664 --------------|---------------|---------------|------------------ 665 1) Raw | Raw - Same as | | 666 | A | | 667 | | | 668 --------------|---------------|---------------|------------------ 669 2) Tag1 | Tag2 |Optional change| VLAN can be 670 | |of VLAN value | 0-4095 671 | | | Change allowed in 672 | | | both directions 673 --------------|---------------|---------------|------------------ 674 3) No Tag | Tag |Add/remove Tag | Tag can be 675 | |field | 0-4095 676 | | | (note i) 677 | | | 678 --------------|---------------|---------------|------------------ 679 4) Tag | No Tag |Remove/add Tag | (note ii) 680 | |field | 681 | | | 682 | | | 683 --------------|---------------|---------------|------------------ 685 Figure 4: Configuration Options 687 Allowed combinations: 689 Raw and other services are not allowed on the same NSP virtual port 690 (A). All other combinations are allowed, except that conflicting 691 VLANs on (A) are not allowed. Note that in most point-to-point PW 692 application the NSP virtual port is the same entity as the physical 693 port. 695 Notes: 697 -i. Mode #3 MAY be limited to adding VLAN NULL only, since 698 change of VLAN or association to specific VLAN can be done 699 at the PW CE-bound side. 701 -ii. Mode #4 exists in layer 2 switches, but is not recommended 702 when operating with PW since it may not preserve the user's 703 PRI bits. If there is a need to remove the VLAN tag (for 704 TLS at the other end of the PW) it is recommended to use 705 mode #2 with tag2=0 (NULL VLAN) on the PW and use mode #3 at 706 the other end of the PW. 708 IEEE 802.3x Flow Control Considerations 710 If the receiving node becomes congested, it can send a special frame, 711 called the PAUSE frame, to the source node at the opposite end of the 712 connection. The implementation MUST provide a mechanism for 713 terminating PAUSE frames locally (i.e. at the local PE). It MUST 714 operate as follows: 716 PAUSE frames received on a local Ethernet port SHOULD cause the PE 717 device to buffer, or to discard, further Ethernet frames for that 718 port until the PAUSE condition is cleared. Optionally, the PE MAY 719 simply discard PAUSE frames. 721 If the PE device wishes to pause data received on a local Ethernet 722 port (perhaps because its own buffers are filling up or because it 723 has received notification of congestion within the PSN) then it MAY 724 issue a PAUSE frame on the local Ethernet port, but MUST clear this 725 condition when willing to receive more data. 727 Appendix B - QoS Details 729 Section 3.7 describes various modes for supporting PW QOS over the 730 PSN. Examples of the above for a point to point VLAN service are: 732 - The classification to the PW is based on VLAN field only, 733 regardless of the user PRI bits. The PW is assigned a specific 734 COS (marking, scheduling, etc.) at the tunnel level. 736 - The classification to the PW is based on VLAN field, but the PRI 737 bits of the user is mapped to different COS marking (and network 738 behavior) at the PW level. Examples are DiffServ coding in case 739 of IP PSN, and E-LSP in MPLS PSN. 741 - The classification to the PW is based on VLAN field and the PRI 742 bits, and frames with different PRI bits are mapped to different 743 PWs. An example is to map a PWES to different L-LSPs in MPLS PSN 744 in order to support multiple COS over an L-LSP capable network, 745 or to multiple L2TPv3 sessions [L2TPv3]. 747 The specific value to be assigned at the PSN for various COS is 748 out of scope for this document. 750 Adaptation of 802.1Q COS to PSN COS 752 It is not required that the PSN will have the same COS definition of 753 COS as defined in [802.1Q], and the mapping of 802.1Q COS to PSN COS 754 is application specific and depends on the agreement between the 755 customer and the PW provider. However, the following principles 756 adopted from 802.1Q table 8-2 MUST be met when applying set of PSN 757 COS based on user's PRI bits. 759 ---------------------------------- 760 |#of available classes of service| 761 -------------||---+---+---+---+---+---+---+---| 762 User || 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 763 Priority || | | | | | | | | 764 =============================================== 765 0 Best Effort|| 0 | 0 | 0 | 1 | 1 | 1 | 1 | 2 | 766 (Default) || | | | | | | | | 767 ------------ ||---+---+---+---+---+---+---+---| 768 1 Background || 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 769 || | | | | | | | | 770 ------------ ||---+---+---+---+---+---+---+---| 771 2 Spare || 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 772 || | | | | | | | | 773 ------------ ||---+---+---+---+---+---+---+---| 774 3 Excellent || 0 | 0 | 0 | 1 | 1 | 2 | 2 | 3 | 775 Effort || | | | | | | | | 776 ------------ ||---+---+---+---+---+---+---+---| 777 4 Controlled || 0 | 1 | 1 | 2 | 2 | 3 | 3 | 4 | 778 Load || | | | | | | | | 779 ------------ ||---+---+---+---+---+---+---+---| 780 5 Interactive|| 0 | 1 | 1 | 2 | 3 | 4 | 4 | 5 | 781 Multimedia || | | | | | | | | 782 ------------ ||---+---+---+---+---+---+---+---| 783 6 Interactive|| 0 | 1 | 2 | 3 | 4 | 5 | 5 | 6 | 784 Voice || | | | | | | | | 785 ------------ ||---+---+---+---+---+---+---+---| 786 7 Network || 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 787 Control || | | | | | | | | 788 ------------ ||---+---+---+---+---+---+---+---| 790 Figure 5: IEEE 802.1Q COS Service Mapping 792 Drop precedence 794 The 802.1P standard does not support drop precedence, therefore from 795 the PW PE-bound point of view there is no mapping required. It is 796 however possible to mark different drop precedence for different PW 797 frames based on the operator policy and required network behavior. 798 This functionality is not discussed further here. 800 PSN QOS support and signaling of QOS is out of scope of this 801 document.