idnits 2.17.1 draft-ietf-pwe3-ethernet-encap-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 610. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 621. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 628. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 634. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 223: '...mode, each frame MUST contain at least...' RFC 2119 keyword, line 227: '...mode PW, a frame MAY contain an 802.1Q...' RFC 2119 keyword, line 252: '...ransparency may be lost. The OPTIONAL...' RFC 2119 keyword, line 276: '...kets. Sequencing MAY be enabled in the...' RFC 2119 keyword, line 292: '...he VLAN identifier MUST be selected in...' (37 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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: An Optional 16 bit value indicating the requested VLAN ID. This parameter MUST be used by a PE that is incapable of rewriting the 802.1Q Ethernet VLAN tag on output. If the ingress PE receives this request, it MUST rewrite the VLAN ID contained inside the VLAN Tag at the input to match the requested VLAN ID. If this is not possible, and the VLAN ID does not already match the configured ingress VLAN ID, the PW MUST not be enabled. This parameter is applicable only to PW type 0x0004. == 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 on the attachment circuit; 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 (November 2005) is 6730 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: 'VCCV' is mentioned on line 268, but not defined == Missing Reference: 'PW-MIB' is mentioned on line 483, but not defined == Missing Reference: 'L2TPv3' is mentioned on line 906, but not defined == Outdated reference: A later version (-06) exists of draft-ietf-pwe3-cw-01 == Outdated reference: A later version (-15) exists of draft-ietf-pwe3-iana-allocation-08 == Outdated reference: A later version (-17) exists of draft-ietf-pwe3-control-protocol-09 -- Possible downref: Non-RFC (?) normative reference: ref. 'PDU' == Outdated reference: A later version (-14) exists of draft-ietf-pwe3-pw-mib-04 -- Obsolete informational reference (is this intentional?): RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) == Outdated reference: A later version (-10) exists of draft-ietf-pwe3-fragmentation-08 Summary: 4 errors (**), 0 flaws (~~), 12 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Luca Martini 3 Internet Draft Eric C. Rosen 4 Expiration Date: May 2006 Cisco Systems, Inc. 6 Nasser El-Aawar Giles Heron 7 Level 3 Communications, LLC. Tellabs 9 November 2005 11 Encapsulation Methods for Transport of Ethernet Over MPLS Networks 13 draft-ietf-pwe3-ethernet-encap-11.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 An Ethernet Pseudowire (PW) is used to carry Ethernet/802.3 Protocol 40 Data Units over an MPLS network. This enables service providers to 41 offer "emulated" Ethernet services over existing MPLS networks. This 42 document specifies the encapsulation of Ethernet/802.3 PDUs within a 43 pseudo wire. It also specifies the procedures for using a PW to 44 provide a "point-to-point Ethernet" service. 46 Table of Contents 48 1 Specification of Requirements .......................... 2 49 2 Introduction ........................................... 3 50 3 Applicability Statement ................................ 6 51 4 Details Specific to Particular Emulated Services ....... 7 52 4.1 Ethernet Tagged Mode ................................... 7 53 4.2 Ethernet Raw Mode ...................................... 8 54 4.3 Ethernet Specific Interface Parameter LDP Sub-TLV ...... 8 55 4.4 Generic Procedures ..................................... 8 56 4.4.1 Raw Mode vs. Tagged Mode ............................... 9 57 4.4.2 MTU Management on the PE/CE Links ...................... 10 58 4.4.3 Frame Ordering ......................................... 11 59 4.4.4 Frame Error Processing ................................. 11 60 4.4.5 IEEE 802.3x Flow Control Interworking .................. 11 61 4.5 Management ............................................. 11 62 4.6 The Control Word ....................................... 12 63 4.7 QoS Considerations ..................................... 13 64 5 Security Considerations ................................ 13 65 6 PSN MTU Requirements ................................... 14 66 7 IANA Considerations .................................... 14 67 8 Full Copyright Statement ............................... 14 68 9 Intellectual Property Statement ........................ 14 69 10 Normative References ................................... 15 70 11 Informative References ................................. 16 71 12 Editor Information ..................................... 16 72 13 Author Information ..................................... 16 73 14 Significant Contributors ............................... 17 74 Ap A Interoperability Guidelines ............................ 20 75 Ap B QoS Details ............................................ 21 77 1. Specification of Requirements 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in RFC 2119 83 2. Introduction 85 An Ethernet Pseudowire (PW) allows Ethernet/802.3 [802.3] Protocol 86 Data Units (PDUs) to be carried over an Multi Protocol Label Switched 87 [MPLS-ARCH] network. In addressing the issues associated with 88 carrying an Ethernet PDU over a Public Switched Network (PSN), this 89 document assumes that a Pseudowire (PW) has been set up by using a 90 control protocol such as the one as described in [PWE3-CTRL]. The 91 design of Ethernet Pseudowire described in this document conforms to 92 the pseudo wire architecture described in [RFC3985]. It is also 93 assumed in the remainder of this document that the reader is familiar 94 with RFC3985. 96 The PWE3 Ethernet PDU consists of the Destination Address, Source 97 Address, Length/Type, MAC Client Data and padding extracted from a 98 MAC frame as a concatenated octet sequence in their original order 99 [PDU]. 101 In addition to the Ethernet PDU format used within the pseudo wire, 102 this document discusses: 104 - Procedures for using a PW in order to provide a pair of Customer 105 Edge Routers (CE) with an emulated (point-to-point) Ethernet 106 service, including the procedures for the processing of Provider 107 Edge-bound and CE-bound Ethernet PDUs. [RFC3985] 109 - Ethernet-specific QoS and security considerations 111 - Inter-domain transport considerations for Ethernet PW 113 The following two figures describe the reference models which are 114 derived from [RFC3985] to support the Ethernet PW emulated services. 116 |<-------------- Emulated Service ---------------->| 117 | | 118 | |<------- Pseudo Wire ------>| | 119 | | | | 120 | | |<-- PSN Tunnel -->| | | 121 | PW End V V V V PW End | 122 V Service +----+ +----+ Service V 123 +-----+ | | PE1|==================| PE2| | +-----+ 124 | |----------|............PW1.............|----------| | 125 | CE1 | | | | | | | | CE2 | 126 | |----------|............PW2.............|----------| | 127 +-----+ ^ | | |==================| | | ^ +-----+ 128 ^ | +----+ +----+ | | ^ 129 | | Provider Edge 1 Provider Edge 2 | | 130 | | | | 131 Customer | | Customer 132 Edge 1 | | Edge 2 133 | | 134 | | 135 Attachment Circuit (AC) Attachment Circuit (AC) 136 native Ethernet service native Ethernet service 138 Figure 1: PWE3 Ethernet/VLAN Interface Reference Configuration 140 The "emulated service" shown in Figure 1 is, strictly speaking, a 141 bridged LAN; the PEs have MAC interfaces, consume MAC control frames, 142 etc. However, the procedures specified herein only support the case 143 in which there are two CEs on the "emulated LAN". Hence we refer to 144 this service as "emulated point-to-point Ethernet". Specification of 145 the procedures for using pseudo wires to emulate LANs with more than 146 two CEs are out of scope of the current document. 148 +-------------+ +-------------+ 149 | Emulated | | Emulated | 150 | Ethernet | | Ethernet | 151 | (including | Emulated Service | (including | 152 | VLAN) |<==============================>| VLAN) | 153 | Services | | Services | 154 +-------------+ Pseudo Wire +-------------+ 155 |Demultiplexer|<==============================>|Demultiplexor| 156 +-------------+ +-------------+ 157 | PSN | PSN Tunnel | PSN | 158 | MPLS |<==============================>| MPLS | 159 +-------------+ +-------------+ 160 | Physical | | Physical | 161 +-----+-------+ +-----+-------+ 162 Figure 2: Ethernet PWE3 Protocol Stack Reference Model 164 For the purpose of this document, PE1 will be defined as the ingress 165 router, and PE2 as the egress router. A layer 2 PDU will be received 166 at PE1, encapsulated at PE1, transported, decapsulated at PE2, and 167 transmitted out on the attachment circuit of PE2. 169 An Ethernet PW emulates a single Ethernet link between exactly two 170 endpoints. The mechanisms described in this document are agnostic to 171 that which is beneath the "Pseudo Wire" level in Figure 2, concerning 172 itself only with the "Emulated Service" portion of the stack. 174 The following reference model describes the termination point of each 175 end of the PW within the PE: 177 +-----------------------------------+ 178 | PE | 179 +---+ +-+ +-----+ +------+ +------+ +-+ 180 | | |P| | | |PW ter| | PSN | |P| 181 | |<==|h|<=| NSP |<=|minati|<=|Tunnel|<=|h|<== From PSN 182 | | |y| | | |on | | | |y| 183 | C | +-+ +-----+ +------+ +------+ +-+ 184 | E | | | 185 | | +-+ +-----+ +------+ +------+ +-+ 186 | | |P| | | |PW ter| | PSN | |P| 187 | |==>|h|=>| NSP |=>|minati|=>|Tunnel|=>|h|==> To PSN 188 | | |y| | | |on | | | |y| 189 +---+ +-+ +-----+ +------+ +------+ +-+ 190 | | 191 +-----------------------------------+ 192 ^ ^ ^ 193 | | | 194 A B C 196 Figure 3: PW reference diagram 198 The PW terminates at a logical port within the PE, defined at point B 199 in the above diagram. This port provides an Ethernet MAC service that 200 will deliver each Ethernet frame that is received at point A, 201 unaltered, to the point A in the corresponding PE at the other end of 202 the PW. 204 The Native Service Processing (NSP) function includes frame 205 processing that is required for the Ethernet frames that are 206 forwarded to the PW termination point. Such functions may include 207 stripping, overwriting or adding VLAN tags, physical port 208 multiplexing and demultiplexing, PW-PW bridging, L2 encapsulation, 209 shaping, policing, etc. These functions are specific to the ethernet 210 technology , and may not be required for the PW emulation service. 212 The points to the left of A, including the physical layer between the 213 CE and PE, and any adaptation (NSP) functions between it and the PW 214 terminations, are outside of the scope of PWE3 and are not defined 215 here. 217 "PW Termination", between A and B, represents the operations for 218 setting up and maintaining the PW, and for encapsulating and 219 decapsulating the Ethernet frames as necessary to transmit them 220 across the MPLS network. 222 An Ethernet PW operates in one of two modes: "raw mode" or "tagged 223 mode". In tagged mode, each frame MUST contain at least one 802.1Q 224 [802.1Q] VLAN tag, and the tag value is meaningful to the NSPs at the 225 two PW termination points. That is, the two PW termination points 226 must have some agreement (signaled or manually configured) on how to 227 process the tag. On a raw mode PW, a frame MAY contain an 802.1Q VLAN 228 tag, but if it does, the tag is not meaningful to the NSPs, and 229 passes transparently through them. 231 3. Applicability Statement 233 The Ethernet PW emulation allows a service provider to offer a "port 234 to port" Ethernet based service across an MPLS packet switched 235 network (PSN) while the Ethernet VLAN PW emulation allows an 236 "Ethernet VLAN to VLAN" based service across an MPLS packet switched 237 network (PSN). 239 The Ethernet or Ethernet VLAN PW has the following characteristics in 240 relationship to the respective native service: 242 - Ethernet PW connects two Ethernet ACs while Ethernet VLAN PW 243 connects two Ethernet VLAN ACs, supporting bi-directional 244 transport of variable length Ethernet frames. The ingress Native 245 Service Processing (NSP) function strips the preamble and FCS 246 from the Ethernet frame and transports the frame in its entirety 247 across the PW. This is done regardless of the presence of the 248 802.1Q tag in the frame. The egress NSP function receives the 249 Ethernet frame from the PW and regenerates the preamble or FCS 250 before forwarding the frame to the attachment circuit. Since FCS 251 is not being transported across either Ethernet or Ethernet VLAN 252 PWs, payload integrity transparency may be lost. The OPTIONAL 253 methods described in [FCS] can be used to achieve payload 254 integrity transparency on Ethernet or Ethernet VLAN PWs. 256 - For Ethernet VLAN PW, VLAN tag rewrite can be achieved by NSP at 257 the egress PE which is outside the scope of this document. 259 - The Ethernet or Ethernet VLAN PW only supports homogeneous 260 Ethernet frame type across the PW; both ends of the PW must be 261 either tagged or untagged. Heterogeneous frame type support 262 achieved with NSP functionality is outside the scope of this 263 document. 265 - Ethernet port or Ethernet VLAN status notification is provided 266 using the PW Status TLV in the LDP status notification message. 267 Loss of connectivity between PEs can be detected by the LDP 268 session closing, or by using [VCCV] mechanisms. The PE can 269 convey these indications back to its attached Remote System. 271 - The maximum frame size that can be supported is limited by the 272 PSN MTU minus the MPLS header size, unless fragmentation and 273 reassembly is used [FRAG]. 275 - The packet switched network may reorder, duplicate, or silently 276 drop packets. Sequencing MAY be enabled in the Ethernet or 277 Ethernet VLAN PW to detect lost, duplicate, or out-of-order 278 packets on a per-PW basis. 280 - The faithfulness of an Ethernet or Ethernet VLAN PW may be 281 increased by leveraging Quality of Service features of the PEs 282 and the underlying PSN. (see "QoS Considerations" section) 284 4. Details Specific to Particular Emulated Services 286 4.1. Ethernet Tagged Mode 288 The Ethernet frame will be encapsulated according to the procedures 289 defined later in this document for tagged mode. It should be noted 290 that if the VLAN identifier is modified by the egress PE, the 291 Ethernet spanning tree protocol might fail to work properly. If this 292 issue is of significance, the VLAN identifier MUST be selected in 293 such away that it matches on the Attachment Circuits at both ends of 294 the PW. 296 If the PE detects a failure on the Ethernet physical port, or the 297 port is administratively disabled, it MUST send PW status 298 notification message for all PWs associated with the port. 300 This mode uses service-delimiting tags to map input Ethernet frames 301 to respective PWs and is corresponds to PW type 0x0004 "Ethernet 302 Tagged Mode" [IANA]. 304 4.2. Ethernet Raw Mode 306 The Ethernet frame will be encapsulated according to the procedures 307 defined later in this document for raw mode. If the PE detects a 308 failure on the Ethernet input port, or the port is administratively 309 disabled, the PE MUST send an appropriate PW status notification 310 message to the corresponding remote PE. 312 In this mode all Ethernet frames received on the attachment circuit 313 of PE1 will be transmitted to PE2 on a single PW. This service 314 corresponds to PW type 0x0005 "Ethernet" [IANA]. 316 4.3. Ethernet Specific Interface Parameter LDP Sub-TLV 318 This LDP sub-Type Length Value [LDP] specifies interface specific 319 parameters. When applicable, it MUST be used to validate that the 320 PEs, and the ingress and egress ports at the edges of the circuit, 321 have the necessary capabilities to interoperate with each other. The 322 Interface parameter TLV is defined in [PWE3-CTRL], the IANA registry 323 with initial values for interface parameter sub-TLV types is defined 324 in [IANA], but the Ethernet specific interface parameters are 325 specified as follows: 326 - 0x06 Requested VLAN ID Sub-TLV 328 An Optional 16 bit value indicating the requested VLAN ID. This 329 parameter MUST be used by a PE that is incapable of rewriting the 330 802.1Q Ethernet VLAN tag on output. If the ingress PE receives 331 this request, it MUST rewrite the VLAN ID contained inside the 332 VLAN Tag at the input to match the requested VLAN ID. If this is 333 not possible, and the VLAN ID does not already match the 334 configured ingress VLAN ID, the PW MUST not be enabled. This 335 parameter is applicable only to PW type 0x0004. 337 4.4. Generic Procedures 339 When the NSP/Forwarder hands a frame to the PW termination function: 341 - The preamble (if any) and FCS are stripped off. 343 - The control word as defined in the "The Control Word" section is, 344 if necessary, prepended to the resulting frame. The conditions 345 under which the control word is or is not used are specified 346 below. 348 - The proper Pseudowire demultiplexor ( PW Label ) is prepended to 349 the resulting packet. 351 - The proper tunnel encapsulation is prepended to the resulting 352 packet. 354 - The packet is transmitted. 356 The way in which the proper tunnel encapsulation and pseudo wire 357 demultiplexor are chosen depends on the procedures that were used to 358 set up the pseudo wire. 360 The tunnel encapsulation depends on how the MPLS PSN is setup. This 361 can include no label, one label or more labels. The proper pseudo 362 wire demultiplexor is an MPLS label whose value is determined by the 363 PW setup and maintenance protocols. 365 When a packet arrives over a PW, the tunnel encapsulation and PW 366 demultiplexor are stripped off. If the control word is present, it is 367 processed and stripped off. The resulting frame is then handed to the 368 Forwarder/NSP. Regeneration of the FCS is considered to be an NSP 369 responsibility. 371 4.4.1. Raw Mode vs. Tagged Mode 373 When the PE receives an Ethernet frame, and the frame has a VLAN tag, 374 we can distinguish two cases: 376 1. The tag is "service-delimiting". This means that the tag was 377 placed on the frame by some piece of service provider-operated 378 equipment, and the tag is used by the service provider to 379 distinguish the traffic. For example, LANs from different 380 customers might be attached to the same service provider 381 switch, which applies VLAN tags to distinguish one customer's 382 traffic from another's, and then forwards the frames to the PE. 384 2. The tag is not service-delimiting. This means that the tag was 385 placed in the frame by a piece of customer equipment, and is 386 not meaningful to the PE. 388 Whether the tag is service delimiting or not , is determined by local 389 configuration on the PE. 391 If an Ethernet PW is operating in raw mode, service-delimiting tags 392 are NEVER sent over the PW. If a service-delimiting tag is present 393 when the frame is received from attachment circuit by the PE, it MUST 394 be stripped (by the NSP) from the frame before the frame is sent to 395 the PW. 397 If an Ethernet PW is operating in tagged mode, every frame sent on 398 the PW MUST have a service-delimiting VLAN tag. If the frame as 399 received by the PE from the attachment circuit does not have a 400 service-delimiting VLAN tag, the PE must prepend the frame with a 401 dummy VLAN tag before sending the frame on the PW. This is the 402 default operating mode. This is the only REQUIRED mode. 404 In both modes, non-service-delimiting tags are passed transparently 405 across the PW as part of the payload. It should be noted that a 406 single Ethernet packet may contain more then one tag. At most one of 407 these tags may be service-delimiting. In any case the NSP function 408 may only inspect the outer most tag for the purpose of adapting the 409 Ethernet frame to the pseudo wire. 411 In both modes, the service-delimiting tag values have only local 412 significance, i.e., are meaningful only at a particular PE-CE 413 interface. When tagged mode is used, the PE that receives a frame 414 from the PW may rewrite the tag value, or may strip the tag entirely, 415 or may leave the tag unchanged, depending on its configuration. When 416 raw mode is used, the PE that receives a frame may or may not need to 417 add a service-delimiting tag before transmitting the frame on the 418 attachment circuit; however it MUST not rewrite or remove any tags 419 which are already present. 421 The following table illustrates the what operations might be 422 performed at input from the attachment circuit: 424 +-----------------------------------------------------------+ 425 | Tag-> | service delimiting | non service delimiting| 426 |--------+---------------------+----------------------------| 427 | Raw Mode | 1st VLAN Tag Removed| no operation performed| 428 |--------+---------------------+----------------------------| 429 | Tagged Mode | NO OP or Tag Added | Tag Added | 430 +-----------------------------------------------------------+ 432 4.4.2. MTU Management on the PE/CE Links 434 The Ethernet PW MUST NOT be enabled unless it is known that the MTUs 435 of the CE-PE links are the same at both ends of the PW. If an egress 436 router receives an encapsulated layer 2 PDU whose payload length 437 (i.e., the length of the PDU itself without any of the encapsulation 438 headers), exceeds the MTU of the destination layer 2 interface, the 439 PDU MUST be dropped. 441 4.4.3. Frame Ordering 443 In general, applications running over Ethernet do not require strict 444 frame ordering. However the IEEE definition of 802.3 [802.3] requires 445 that frames from the same conversation in the context of link 446 aggregation (clause 43) are delivered in sequence. Moreover, the PSN 447 cannot (in the general case) be assumed to provide or to guarantee 448 frame ordering. An Ethernet PW can, through use of the control word, 449 provide strict frame ordering. If this option is enabled, any frames 450 which get mis-ordered by the PSN will be dropped or reordered by the 451 receiving PW endpoint. If strict frame ordering is a requirement for 452 a particular PW, this option MUST be enabled. 454 4.4.4. Frame Error Processing 456 An encapsulated Ethernet frame traversing a pseudo wire may be 457 dropped, corrupted or delivered out-of-order. As described in [PWE3- 458 REQ], frame-loss, corruption, and out-of-order delivery is considered 459 to be a "generalized bit error" of the pseudo wire. PW frames that 460 are corrupted will be detected at the PSN layer and dropped. 462 At the ingress of the PW the native Ethernet frame error processing 463 mechanisms MUST be enabled. Therefore, if a PE device receives an 464 Ethernet frame containing hardware level CRC errors, framing errors, 465 or a runt condition, the frame MUST be discarded on input. Note that 466 defining this processing is part of the NSP function and is outside 467 the scope of this document. 469 4.4.5. IEEE 802.3x Flow Control Interworking 471 In a standard Ethernet network, the flow control mechanism is 472 optional and typically configured between the two nodes on a point- 473 to-point link (e.g. between the CE and the PE). IEEE 802.3x PAUSE 474 frames MUST NOT be carried across the PW. See Appendix A for notes on 475 CE-PE flow control. 477 4.5. Management 479 The Ethernet PW management model follows the general management 480 defined in [RFC3985] and [PWE3-MIB]. Many common PW management 481 facilities are provided here, with no additional Ethernet specifics 482 necessary. Ethernet-specific parameters are defined in an additional 483 MIB module, [PW-MIB]. 485 4.6. The Control Word 487 When carrying Ethernet over an MPLS backbone, sequentiality may need 488 to be preserved. The OPTIONAL control word along the guidelines of 489 [PWE3-CW] is defined here, and addresses this requirement. 490 Implementations MUST support sending no control word, and MAY support 491 sending a control word. If the control word is not used all the 492 functionality defined in [PWE3-CW] is not available. In particular 493 the PW packet may be mistakenly recognized as an IP packet by PSN 494 devices that use the first nibble in the packet to identify it's 495 content. This problem is only significant if the PSN contain equal 496 cost load sharing links, and a source MAC address starting with 0x4 497 as it first byte is used. 499 A PW carried over an MPLS PSN that uses the contents of the MPLS 500 payload to select the ECMP path SHOULD employ the PW MPLS Control 501 Word, if strict packet ordering is required. 503 In all cases the egress router must be aware of whether the ingress 504 router will send a control word over a specific virtual circuit. This 505 may be achieved by configuration of the routers, or by signaling, as 506 defined in [PWE3-CTRL]. 508 The control word is defined as follows: 510 0 1 2 3 511 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 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 |0 0 0 0| Reserved | Sequence Number | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 In the above diagram the first 4 bits MUST be set to 0 to indicate PW 517 data. The rest of the first 16 bits are reserved for future use. 518 They MUST be set to 0 when transmitting, and MUST be ignored upon 519 receipt. 521 The next 16 bits provide a sequence number that can be used to 522 guarantee ordered frame delivery. The processing of the sequence 523 number field is OPTIONAL. 525 The sequence number space is a 16 bit, unsigned circular space. The 526 sequence number value 0 is used to indicate that the sequence number 527 check algorithm is not used. The sequence number processing algorithm 528 is found in [PWE3-CW]. 530 4.7. QoS Considerations 532 The ingress PE MAY consider the user priority (PRI) field [802.1Q] of 533 the VLAN tag header when determining the value to be placed in a QoS 534 field of the encapsulating protocol (e.g., the EXP fields of the MPLS 535 label stack). In a similar way, the egress PE MAY consider the QoS 536 field of the MPLS (e.g., the EXP fields of the MPLS label stack) 537 protocol when queuing the frame for CE-bound. 539 A PE MUST support the ability to carry the Ethernet PW as a best 540 effort service over the MPLS PSN. PRI bits are kept transparent 541 between PE devices, regardless of the QoS support of the PSN. 543 If an 802.1Q VLAN field is added at the PE, a default PRI setting of 544 zero MUST be supported, a configured default value is recommended, or 545 the value may be mapped from the QoS field of the PSN, as referred to 546 above. 548 A PE may support additional QoS support by means of one or more of 549 the following methods: 551 -i. One COS per PW End Service (PWES), mapped to a single COS PW 552 at the PSN. 553 -ii. Multiple COS per PWES mapped to a single PW with multiple 554 COS at the PSN. 555 -iii. Multiple COS per PWES mapped to multiple PWs at the PSN. 557 Examples of the cases above and details of the service mapping 558 considerations are described in Appendix B. 560 The PW guaranteed rate at the MPLS PSN level is PW service provider 561 policy based on agreement with the customer, and may be different 562 from the Ethernet physical port rate. 564 5. Security Considerations 566 The Ethernet pseudo wire type is subject to all of the general 567 security considerations discussed in [RFC3985][PWE3-CTRL]. 569 The Ethernet pseudo wire is transported on a MPLS PSN, therefore the 570 security of the pseudo wire itself will only be as good as the 571 security of the MPLS PSN. The MPLS PSN can be secured by various 572 methods, as described in [MPLS-ARCH]. 574 Security achieved by access control of MAC addresses is out of scope 575 of this document. Additional security requirements related to the use 576 of PW in a switching (virtual bridging) environment are not discussed 577 here as they are not within the scope of this document. 579 6. PSN MTU Requirements 581 The MPLS PSN MUST be configured with an MTU that is large enough to 582 transport a maximum sized Ethernet frame which has been encapsulated 583 with a control word, a pseudo wire demultiplexor, and a tunnel 584 encapsulation. With MPLS used as the tunneling protocol, for example, 585 this is likely to be 8 or more bytes greater than the largest frame 586 size. The methodology described in [FRAG] MAY be used to fragment 587 encapsulated frames that exceed the PSN MTU. However if [FRAG] is 588 not used and if the ingress router determines that an encapsulated 589 layer 2 PDU exceeds the MTU of the PSN tunnel through which it must 590 be sent, the PDU MUST be dropped. 592 7. IANA Considerations 594 This document has no IANA Actions. 596 8. Full Copyright Statement 598 Copyright (C) The Internet Society (2005). 600 This document is subject to the rights, licenses and restrictions 601 contained in BCP 78, and except as set forth therein, the authors 602 retain all their rights. 604 This document and the information contained herein are provided on an 605 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 606 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 607 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 608 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 609 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 610 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 612 9. Intellectual Property Statement 614 The IETF takes no position regarding the validity or scope of any 615 Intellectual Property Rights or other rights that might be claimed to 616 pertain to the implementation or use of the technology described in 617 this document or the extent to which any license under such rights 618 might or might not be available; nor does it represent that it has 619 made any independent effort to identify any such rights. Information 620 on the procedures with respect to rights in RFC documents can be 621 found in BCP 78 and BCP 79. 623 Copies of IPR disclosures made to the IETF Secretariat and any 624 assurances of licenses to be made available, or the result of an 625 attempt made to obtain a general license or permission for the use of 626 such proprietary rights by implementers or users of this 627 specification can be obtained from the IETF on-line IPR repository at 628 http://www.ietf.org/ipr. 630 The IETF invites any interested party to bring to its attention any 631 copyrights, patents or patent applications, or other proprietary 632 rights that may cover technology that may be required to implement 633 this standard. Please address the information to the IETF at ietf- 634 ipr@ietf.org. 636 10. Normative References 638 [PWE3-CW] "PWE3 Control Word for use over an MPLS PSN", S. Bryant, 639 G. Swallow, D. McPherson, draft-ietf-pwe3-cw-01.txt, ( work in 640 progress ), December 2004. 642 [IANA] "IANA Allocations for pseudo Wire Edge to Edge Emulation 643 (PWE3)" Martini,Townsley, draft-ietf-pwe3-iana-allocation-08.txt 644 (work in progress), April 2004 646 [PWE3-CTRL] "Transport of Layer 2 Frames Over MPLS", Martini L.,et al 647 draft-ietf-pwe3-control-protocol-09.txt, ( work in progress ), 648 September 2004. 650 [MPLS-ARCH] RFC3031, "Multiprotocol Label Switching Architecture." 651 E. Rosen, A. Viswanathan, R. Callon. January 2001. 653 [802.3] IEEE802.3-2005, ISO/IEC 8802-3: 2000 (E), "IEEE Standard 654 for Information technology -- Telecommunications and 655 information exchange between systems -- Local and metropolitan 656 area networks -- Specific requirements -- Part 3: Carrier 657 Sense Multiple Access with Collision Detection (CSMA/CD) 658 Access Method and Physical Layer Specifications", 2005. 660 [802.1Q] ANSI/IEEE Standard 802.1Q-2005, "IEEE Standards for 661 Local and Metropolitan Area Networks: Virtual Bridged 662 Local Area Networks", 2005. 664 [PDU] IEEE Std 802.3, 1998 Edition, "Part 3: Carrier 665 sense multiple access with collision detection (CSMA/CD) 666 access method and physical layer specifications" figure 3.1, 667 1998 669 11. Informative References 671 [RFC3985] RFC3985, "PWE3 Architecture" Bryant, et al., RFC3985. 673 [PWE3-REQ] "Requirements for Pseudo Wire Emulation Edge-to-Edge", 674 Xiao, X., McPherson, D., Pate, P., White, C., Kompella, 675 K., Gill, V., Nadeau, T., draft-ietf-pwe3-requirements-08.txt, 676 (work in progress), September 2003. 678 [PWE3-MIB] "Pseudo Wire (PW) Management Information Base 679 using SMIv2", Zelig, D., Mantin, S., Nadeau, T., Danenberg, 680 D., draft-ietf-pwe3-pw-mib-04.txt, (work in progress), 681 February 2004. 683 [LDP] "LDP Specification." L. Andersson, P. Doolan, N. Feldman, A. 684 Fredette, B. Thomas. January 2001. RFC3036 686 [FRAG] "PWE3 Fragmentation and Reassembly", A. Malis, W. M. Townsley, 687 draft-ietf-pwe3-fragmentation-08.txt ( work in progress ) 688 February 2005 690 [FCS] "PWE3 Frame Check Sequence Retention", A. Malis, D.Allan, 691 N. Del Regno, draft-ietf-pwe3-fcs-retention-04.txt (work in 692 progress) September 2005 694 12. Editor Information 696 Luca Martini 697 Cisco Systems, Inc. 698 9155 East Nichols Avenue, Suite 400 699 Englewood, CO, 80112 700 e-mail: lmartini@cisco.com 702 13. Author Information 704 Nasser El-Aawar 705 Level 3 Communications, LLC. 706 1025 Eldorado Blvd. 707 Broomfield, CO, 80021 708 e-mail: nna@level3.net 709 Giles Heron 710 Tellabs 711 Abbey Place 712 24-28 Easton Street 713 High Wycombe 714 Bucks 715 HP11 1NT 716 UK 717 e-mail: giles.heron@tellabs.com 719 Eric C. Rosen 720 Cisco Systems, Inc. 721 1414 Massachusetts Avenue 722 Boxborough, MA 01719 723 e-mail: erosen@cisco.com 725 14. Significant Contributors 727 Andrew G. Malis 728 Tellabs 729 90 Rio Robles Dr. 730 San Jose, CA 95134 731 e-mail: Andy.Malis@tellabs.com 733 Dan Tappan 734 Cisco Systems, Inc. 735 1414 Massachusetts Avenue 736 Boxborough, MA 01719 737 e-mail: tappan@cisco.com 739 Steve Vogelsang 740 ECI Telecom 741 Omega Corporate Center 742 1300 Omega Drive 743 Pittsburgh, PA 15205 744 e-mail: stephen.vogelsang@ecitele.com 745 Vinai Sirkay 746 Reliance Infocomm 747 Dhirubai Ambani Knowledge City 748 Navi Mumbai 400 709 749 India 750 e-mail: vinai@sirkay.com 752 Vasile Radoaca 753 Nortel Networks 754 600 Technology Park 755 Billerica MA 01821 756 e-mail: vasile@nortelnetworks.com 758 Chris Liljenstolpe 759 Alcatel 760 11600 Sallie Mae Dr. 761 9th Floor 762 Reston, VA 20193 763 e-mail: chris.liljenstolpe@alcatel.com 765 Kireeti Kompella 766 Juniper Networks 767 1194 N. Mathilda Ave 768 Sunnyvale, CA 94089 769 e-mail: kireeti@juniper.net 771 Tricci So 772 Nortel Networks 3500 Carling Ave., 773 Nepean, Ontario, 774 Canada, K2H 8E9. 775 e-mail: tso@nortelnetworks.com 777 XiPeng Xiao 778 Riverstone Networks 779 5200 Great America Parkway 780 Santa Clara, CA 95054 781 e-mail: xxiao@riverstonenet.com 782 Christopher O. Flores 783 T-Systems 784 10700 Parkridge Boulevard 785 Reston, VA 20191 786 USA 787 e-mail: christopher.flores@usa.telekom.de 789 David Zelig 790 Corrigent Systems 791 126, Yigal Alon St. 792 Tel Aviv, ISRAEL 793 e-mail: davidz@corrigent.com 795 Raj Sharma 796 Luminous Netwokrs, Inc. 797 10460 Bubb Road 798 Cupertino, CA 95014 799 e-mail: raj@luminous.com 801 Nick Tingle 802 TiMetra Networks 803 274 Ferguson Drive 804 Mountain View, CA 94043 805 e-mail: nick@timetra.com 807 Sunil Khandekar 808 TiMetra Networks 809 274 Ferguson Drive 810 Mountain View, CA 94043 811 email: sunil@timetra.com 813 Loa Andersson 814 TLA-group 815 e-mail: loa@pi.se 817 Ap A Interoperability Guidelines 819 Configuration Options 821 The following is a list of the configuration options for a point-to- 822 point Ethernet PW based on the reference points of Figure 3: 824 --------------|---------------|---------------|------------------ 825 Service and | Encap on C |Operation at B | Remarks 826 Encap on A | |ingress/egress | 827 --------------|---------------|---------------|------------------ 828 1) Raw | Raw - Same as | | 829 | A | | 830 | | | 831 --------------|---------------|---------------|------------------ 832 2) Tag1 | Tag2 |Optional change| VLAN can be 833 | |of VLAN value | 0-4095 834 | | | Change allowed in 835 | | | both directions 836 --------------|---------------|---------------|------------------ 837 3) No Tag | Tag |Add/remove Tag | Tag can be 838 | |field | 0-4095 839 | | | (note i) 840 | | | 841 --------------|---------------|---------------|------------------ 842 4) Tag | No Tag |Remove/add Tag | (note ii) 843 | |field | 844 | | | 845 | | | 846 --------------|---------------|---------------|------------------ 848 Figure 4: Configuration Options 850 Allowed combinations: 852 Raw and other services are not allowed on the same NSP virtual port 853 (A). All other combinations are allowed, except that conflicting 854 VLANs on (A) are not allowed. Note that in most point-to-point PW 855 application the NSP virtual port is the same entity as the physical 856 port. 858 Notes: 860 -i. Mode #3 MAY be limited to adding VLAN NULL only, since 861 change of VLAN or association to specific VLAN can be done 862 at the PW CE-bound side. 864 -ii. Mode #4 exists in layer 2 switches, but is not recommended 865 when operating with PW since it may not preserve the user's 866 PRI bits. If there is a need to remove the VLAN tag (for 867 TLS at the other end of the PW) it is recommended to use 868 mode #2 with tag2=0 (NULL VLAN) on the PW and use mode #3 at 869 the other end of the PW. 871 IEEE 802.3x Flow Control Considerations 873 If the receiving node becomes congested, it can send a special frame, 874 called the PAUSE frame, to the source node at the opposite end of the 875 connection. The implementation MUST provide a mechanism for 876 terminating PAUSE frames locally (i.e. at the local PE). It MUST 877 operate as follows: PAUSE frames received on a local Ethernet port 878 SHOULD cause the PE device to buffer, or to discard, further Ethernet 879 frames for that port until the PAUSE condition is cleared. 880 Optionally, the PE MAY simply discard PAUSE frames. 882 If the PE device wishes to pause data received on a local Ethernet 883 port (perhaps because its own buffers are filling up or because it 884 has received notification of congestion within the PSN) then it MAY 885 issue a PAUSE frame on the local Ethernet port, but MUST clear this 886 condition when willing to receive more data. 888 Ap B QoS Details 890 Section 3.7 describes various modes for supporting PW QOS over the 891 PSN. Examples of the above for a point to point VLAN service are: 893 - The classification to the PW is based on VLAN field only, 894 regardless of the user PRI bits. The PW is assigned a specific 895 COS (marking, scheduling, etc.) at the tunnel level. 897 - The classification to the PW is based on VLAN field, but the PRI 898 bits of the user is mapped to different COS marking (and network 899 behavior) at the PW level. Examples are and E-LSP in an MPLS 900 network. 902 - The classification to the PW is based on VLAN field and the PRI 903 bits, and frames with different PRI bits are mapped to different 904 PWs. An example is to map a PWES to different L-LSPs in MPLS PSN 905 in order to support multiple COS over an L-LSP capable network, 906 or to multiple L2TPv3 sessions [L2TPv3]. 908 The specific value to be assigned at the PSN for various COS is 909 out of scope for this document. 911 Adaptation of 802.1Q COS to PSN COS 913 It is not required that the PSN will have the same COS definition of 914 COS as defined in [802.1Q], and the mapping of 802.1Q COS to PSN COS 915 is application specific and depends on the agreement between the 916 customer and the PW provider. However, the following principles 917 adopted from 802.1Q table 8-2 MUST be met when applying set of PSN 918 COS based on user's PRI bits. 920 ---------------------------------- 921 |#of available classes of service| 922 -------------||---+---+---+---+---+---+---+---| 923 User || 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 924 Priority || | | | | | | | | 925 =============================================== 926 0 Best Effort|| 0 | 0 | 0 | 1 | 1 | 1 | 1 | 2 | 927 (Default) || | | | | | | | | 928 ------------ ||---+---+---+---+---+---+---+---| 929 1 Background || 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 930 || | | | | | | | | 931 ------------ ||---+---+---+---+---+---+---+---| 932 2 Spare || 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 933 || | | | | | | | | 934 ------------ ||---+---+---+---+---+---+---+---| 935 3 Excellent || 0 | 0 | 0 | 1 | 1 | 2 | 2 | 3 | 936 Effort || | | | | | | | | 937 ------------ ||---+---+---+---+---+---+---+---| 938 4 Controlled || 0 | 1 | 1 | 2 | 2 | 3 | 3 | 4 | 939 Load || | | | | | | | | 940 ------------ ||---+---+---+---+---+---+---+---| 941 5 Interactive|| 0 | 1 | 1 | 2 | 3 | 4 | 4 | 5 | 942 Multimedia || | | | | | | | | 943 ------------ ||---+---+---+---+---+---+---+---| 944 6 Interactive|| 0 | 1 | 2 | 3 | 4 | 5 | 5 | 6 | 945 Voice || | | | | | | | | 946 ------------ ||---+---+---+---+---+---+---+---| 947 7 Network || 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 948 Control || | | | | | | | | 949 ------------ ||---+---+---+---+---+---+---+---| 951 Figure 5: IEEE 802.1Q COS Service Mapping 953 Drop precedence 955 The 802.1P standard does not support drop precedence, therefore from 956 the PW PE-bound point of view there is no mapping required. It is 957 however possible to mark different drop precedence for different PW 958 frames based on the operator policy and required network behavior. 959 This functionality is not discussed further here. 961 PSN QOS support and signaling of QOS is out of scope of this 962 document.