idnits 2.17.1 draft-ietf-pwe3-ethernet-encap-02.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 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 2 instances of too long lines in the document, the longest one being 20 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 204: '...mode, each frame MUST contain an 802.1...' RFC 2119 keyword, line 208: '... frame MAY contain an 802.1Q VLAN ta...' RFC 2119 keyword, line 223: '... MUST signal that the PW will is tra...' RFC 2119 keyword, line 224: '... case all frames in a PW MUST have the...' RFC 2119 keyword, line 232: '... The Ethernet PW MUST NOT be enabled u...' (33 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (February 2003) is 7731 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 274, but not defined == Missing Reference: 'PWE3-MIB' is mentioned on line 281, but not defined == Unused Reference: 'PW-MIB' is defined on line 461, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-pwe3-control-protocol-01 -- Possible downref: Normative reference to a draft: ref. 'PWE3-ARCH' -- No information found for draft-pwe3-requirements - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PWE3-REQ' -- Possible downref: Normative reference to a draft: ref. 'PWE3-FRAME' -- Possible downref: Normative reference to a draft: ref. 'PW-MIB' == Outdated reference: A later version (-01) exists of draft-zelig-pw-enet-mib-00 -- Possible downref: Normative reference to a draft: ref. 'PW-ENET-MIB' == Outdated reference: A later version (-15) exists of draft-ietf-l2tpext-l2tp-base-03 Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Luca Martini 3 Internet Draft Nasser El-Aawar 4 Expiration Date: August 2003 Level 3 Communications, LLC. 6 Giles Heron Eric C. Rosen 7 PacketExchange Ltd. Cisco Systems, Inc. 9 February 2003 11 Encapsulation Methods for Transport of Ethernet Frames Over IP/MPLS Networks 13 draft-ietf-pwe3-ethernet-encap-02.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 An Ethernet Pseudowire (PW) is used to carry Ethernet/802.3 Protocol 38 Data Units over an IP or MPLS network. This enables service providers 39 to offer "emulated" ethernet services over existing IP or MPLS 40 networks. This document specifies the encapsulation of Ethernet/802.3 41 PDUs within a pseudowire. It also specifies the procedures for using 42 a PW to provide a "point-to-point ethernet" service. 44 Table of Contents 46 1 Specification of Requirements .......................... 2 47 2 Introduction ........................................... 2 48 3 Requirements for Ethernet Pseudo-Wires Emulating Point-to-Point Ethernet Links 4 49 3.1 Frame Processing at the PW Endpoints ................... 6 50 3.1.1 Encapsulation .......................................... 6 51 3.1.2 Tagged Mode ............................................ 6 52 3.1.3 MTU Management on the PE/CE Links ...................... 6 53 3.1.4 Frame Ordering ......................................... 6 54 3.1.5 Frame Error Processing ................................. 7 55 3.1.6 IEEE 802.3x Flow Control Interworking .................. 7 56 3.2 PW Setup and Maintenance ............................... 7 57 3.3 Management ............................................. 7 58 3.4 The Control Word ....................................... 8 59 3.4.1 Setting the sequence number ............................ 8 60 3.4.2 Processing the sequence number ......................... 9 61 3.5 QoS Considerations ..................................... 9 62 3.6 Security Considerations ................................ 10 63 3.7 PSN MTU Requirements ................................... 10 64 4 Intellectual Property Disclaimer ....................... 11 65 5 References ............................................. 11 66 6 Author Information ..................................... 12 67 Appendix A - Interoperability Guidelines ............... 15 68 Appendix B - QoS Details ............................... 16 70 1. Specification of Requirements 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in RFC 2119 76 2. Introduction 78 An Ethernet Pseudowire (PW) allows Ethernet/802.3 Protocol Data Units 79 (PDUs) to be carried over an IP network or an MPLS network. In 80 addressing the issues associated with carrying an Ethernet PDU over a 81 PSN, this document assumes that a Pseudowire (PW) has been set up by 82 some means outside the scope of this document. This may be via manual 83 configuration, or a signaling protocol such as that defined in 84 [PWE3-CTRL] or [L2TPv3]. As described in [PWE3-FRAME], this PW may be 85 tunneled through an MPLS, IPv4 or IPv6 PSN. 87 In addition to the Ethernet PDU format used within the pseudowire, 88 this document discusses: 90 - Procedures for using a PW in order to provide a pair of CEs with 91 an emulated (point-to-point) ethernet service, including the 92 procedures for the processing of PE-bound and CE-bound ethernet 93 PDUs. [PWE3-FRAME] 95 - Ethernet-specific QoS and security considerations 97 - Inter-domain transport considerations for Ethernet PW 99 The following two figures describe the reference models which are 100 derived from [PWE3-FRAME] to support the Ethernet PW emulated 101 services. 103 Native |<----- Pseudo Wire ---->| Native 104 Ethernet | | Ethernet 105 or | |<-- PSN Tunnel -->| | or 106 VLAN V V V V VLAN 107 Service +----+ +----+ Service 108 +----+ | | PE1|==================| PE2| | +----+ 109 | |----------|............PW1.............|----------| | 110 | CE1| | | | | | | |CE2 | 111 | |----------|............PW2.............|----------| | 112 +----+ | | |==================| | | +----+ 113 ^ +----+ +----+ | ^ 114 | Provider Edge 1 Provider Edge 2 | 115 | | 116 |<-------------- Emulated Service ---------------->| 118 Figure 1: PWE3 Ethernet/VLAN Interface Reference Configuration 120 The "emulated service" shown in Figure 1 is, strictly speaking, a 121 bridged LAN; the PEs have MAC interfaces, consume MAC control frames, 122 etc. However, the procedures specified herein only support the case 123 in which there are two CEs on the "emulated LAN". Hence we refer to 124 this service as "emulated point-to-point ethernet". Specification of 125 the procedures for using pseudowires to emulate LANs with more than 126 two CEs are out of scope of the current document. 128 +-------------+ +-------------+ 129 | Emulated | | Emulated | 130 | Ethernet | | Ethernet | 131 | (including | Emulated Service | (including | 132 | VLAN) |<==============================>| VLAN) | 133 | Services | | Services | 134 +-------------+ Pseudo Wire +-------------+ 135 |Demultiplexer|<==============================>|Demultiplexor| 136 +-------------+ +-------------+ 137 | PSN | PSN Tunnel | PSN | 138 | MPLS or IP |<==============================>| MPLS or IP | 139 +-------------+ +-------------+ 140 | Physical | | Physical | 141 +-----+-------+ +-----+-------+ 143 Figure 2: Ethernet PWE3 Protocol Stack Reference Model 145 For the purpose of this document, PE1 will be defined as the ingress 146 router, and PE2 as the egress router. A layer 2 PDU will be received 147 at PE1, encapsulated at PE1, transported, decapsulated at PE2, and 148 transmitted out of PE2. 150 3. Requirements for Ethernet Pseudo-Wires Emulating Point-to-Point 151 Ethernet Links 153 An Ethernet PW emulates a single Ethernet link between exactly two 154 endpoints. The mechanisms described in this document are agnostic to 155 that which is beneath the "Pseudo Wire" level in Figure 2, concerning 156 itself only with the "Emulated Service" portion of the stack. 158 The following reference model describes the termination point of each 159 end of the PW within the PE: 161 +-----------------------------------+ 162 | PE | 163 +---+ +-+ +-----+ +------+ +------+ +-+ 164 | | |P| | | |PW ter| | PSN | |P| 165 | |<==|h|<=| NSP |<=|minati|<=|Tunnel|<=|h|<== From PSN 166 | | |y| | | |on | | | |y| 167 | C | +-+ +-----+ +------+ +------+ +-+ 168 | E | | | 169 | | +-+ +-----+ +------+ +------+ +-+ 170 | | |P| | | |PW ter| | PSN | |P| 171 | |==>|h|=>| NSP |=>|minati|=>|Tunnel|=>|h|==> To PSN 172 | | |y| | | |on | | | |y| 173 +---+ +-+ +-----+ +------+ +------+ +-+ 174 | | 175 +-----------------------------------+ 176 ^ ^ 177 | | 178 A B 180 Figure 3: PW reference diagram 182 The PW terminates at a logical port within the PE, defined at point A 183 in the above diagram. This port provides an Ethernet MAC service that 184 will deliver each Ethernet frame that is received at point A, 185 unaltered, to the point A in the corresponding PE at the other end of 186 the PW. 188 The "NSP" function includes frame processing that is required for the 189 Ethernet frames that are forwarded to the PW termination point. Such 190 functions may include stripping, overwriting or adding VLAN tags, 191 physical port multiplexing and demultiplexing, PW-PW bridging, L2 192 encapsulation, shaping, policing, etc. 194 The points to the left of A, including the physical layer between the 195 CE and PE, and any adaptation (NSP) functions between it and the PW 196 terminations, are outside of the scope of PWE3 and are not defined 197 here. 199 "PW Termination", between A and B, represents the operations for 200 setting up and maintaining the PW, and for encapsulating and 201 decapsulating the Ethernet frames according to the PSN type in use. 203 An ethernet PW can operate in one of two modes: "raw mode" or "tagged 204 mode". In tagged mode, each frame MUST contain an 802.1Q VLAN tag, 205 and the tag value is meaningful to the NSPs at the two PW endpoints. 206 That is, the two endpoints must have some agreement (signaled or 207 manually configured) on how to process the tag. On a raw mode PW, a 208 frame MAY contain an 802.1Q VLAN tag, but if it does, the tag is not 209 meaningful to the NSPs, and passes transparently through them. 211 3.1. Frame Processing at the PW Endpoints 213 3.1.1. Encapsulation 215 The entire Ethernet frame without any preamble or FCS is transported 216 as a single frame over the Pseudowire. Note that when using the 217 signaling procedures defined in [PWE3-CRTL] or [L2TPv3], a "Raw Mode" 218 PW should be signaled as being of type "Ethernet". 220 3.1.2. Tagged Mode 222 The ethernet frame may contain an 802.1Q tag, in this case the PE 223 MUST signal that the PW will is transporting ethernet frames 224 including 802.1Q tags. In this case all frames in a PW MUST have the 225 same 802.1Q tag value. Note that the tag may be overwritten by the 226 NSP function at ingress or at egress. Note that when using the 227 signaling procedures defined in [PWE3-CRTL] or [L2TPv3], a "Tagged 228 Mode" PW should be signaled as being of type "Ethernet VLAN". 230 3.1.3. MTU Management on the PE/CE Links 232 The Ethernet PW MUST NOT be enabled unless it is known that the MTUs 233 of the CE-PE links are the same at both ends of the PW. 235 3.1.4. Frame Ordering 237 In general, applications running over Ethernet do not require strict 238 frame ordering. However the IEEE definition of 802.3 [802.3] requires 239 that frames from the same conversation are delivered in sequence. 240 Moreover, the PSN cannot (in the general case) be assumed to provide 241 or to guarantee frame ordering. An ethernet PW can, through use of 242 the control word, provide strict frame ordering. If this option is 243 enabled, any frames which get misordered by the PSN will be dropped 244 by the receiving PW endpoint. If strict frame ordering is a 245 requirement for a particular PW, this option MUST be enabled. 247 3.1.5. Frame Error Processing 249 An encapsulated Ethernet frame traversing a psuedo-wire may be 250 dropped, corrupted or delivered out-of-order. As described in [PWE3- 251 REQ], frame-loss, corruption, and out-of-order delivery is considered 252 to be a "generalized bit error" of the psuedo-wire. PW frames that 253 are corrupted will be detected at the PSN layer and dropped. 255 At the ingress of the PW the native Ethernet frame error processing 256 mechanisms MUST be enabled. Therefore, if a PE device receives an 257 Ethernet frame containing hardware level CRC errors, framing errors, 258 or a runt condition, the frame MUST be discarded on input. Note that 259 defining this processing is part of the NSP function and is outside 260 the scope of this draft. 262 3.1.6. IEEE 802.3x Flow Control Interworking 264 In a standard gigabit Ethernet network, the flow control mechanism is 265 optional and typically configured between the two nodes on a point- 266 to-point link (e.g. between the CE and the PE). IEEE 802.3x PAUSE 267 frames MUST NOT be carried across the PW. See Appendix A for notes on 268 CE-PE flow control. 270 3.2. PW Setup and Maintenance 272 This document assumes that a mechanism exists to set up the ethernet 273 PW. Maintenance of the PW (e.g. keepalives, status updates, etc) is 274 generally tied closely to the PW Setup mechanisms. [PWE3-CTRL] and 275 [L2TPv3] define two mechanisms for setup and maintenance of Ethernet 276 PWs. 278 3.3. Management 280 The Ethernet PW management model follows the general management 281 defined in [PWE3-FRAME] and [PWE3-MIB]. Many common PW management 282 facilities are provided here, with no additional Ethernet specifics 283 necessary. Ethernet-specific parameters are defined in an additional 284 MIB module, [PW-ENET-MIB]. 286 As specified in [PWE3-FRAME], an implementation SHOULD support the 287 generic and specific PW MIB modules for PW set-up and monitoring. 288 Other mechanisms for PW set up (command line interface for example) 289 MAY be supported. 291 3.4. The Control Word 293 When carrying Ethernet over an IP or MPLS backbone sequentiality may 294 need to be preserved. The OPTIONAL control word defined here 295 addresses this requirement. Implementations MUST support sending no 296 control word, and MAY support sending a control word. 298 In all cases the egress router must be aware of whether the ingress 299 router will send a control word over a specific virtual circuit. 300 This may be achieved by configuration of the routers, or by 301 signaling, for example as defined in [PWE3-CRTL]. 303 The control word is defined as follows: 305 0 1 2 3 306 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 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Reserved | Sequence Number | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 In the above diagram the first 16 bits are reserved for future use. 312 They MUST be set to 0 when transmitting, and MUST be ignored upon 313 receipt. 315 The next 16 bits provide a sequence number that can be used to 316 guarantee ordered frame delivery. The processing of the sequence 317 number field is OPTIONAL. 319 The sequence number space is a 16 bit, unsigned circular space. The 320 sequence number value 0 is used to indicate an unsequenced frame. 322 3.4.1. Setting the sequence number 324 For a given PW, and a pair of routers PE11 and PE2, if PE11 supports 325 frame sequencing then the following procedures should be used: 327 - the initial frame transmitted on the PW MUST use sequence number 328 1 329 - subsequent frames MUST increment the sequence number by one for 330 each frame 331 - when the transmit sequence number reaches the maximum 16 bit 332 value (65535) the sequence number MUST wrap to 1 334 If the transmitting router PE1 does not support sequence number 335 processing, then the sequence number field in the control word MUST 336 be set to 0. 338 3.4.2. Processing the sequence number 340 If a router PE2 supports receive sequence number processing, then the 341 following procedures should be used: 343 When a PW is initially set up, the "expected sequence number" 344 associated with it MUST be initialized to 1. 346 When a frame is received on that PW, the sequence number should be 347 processed as follows: 349 - if the sequence number on the frame is 0, then the frame passes 350 the sequence number check 352 - otherwise if the frame sequence number >= the expected sequence 353 number and the frame sequence number - the expected sequence 354 number < 32768, then the frame is in order. 356 - otherwise if the frame sequence number < the expected sequence 357 number and the expected sequence number - the frame sequence 358 number >= 32768, then the frame is in order. 360 - otherwise the frame is out of order. 362 If a frame passes the sequence number check, or is in order then, it 363 can be delivered immediately. If the frame is in order, then the 364 expected sequence number should be set using the algorithm: 366 expected_sequence_number := frame_sequence_number + 1 mod 2**16 367 if (expected_sequence_number = 0) then expected_sequence_number := 1; 369 Packets which are received out of order MAY be dropped or reordered 370 at the discretion of the receiver. 372 If a router PE2 does not support receive sequence number processing, 373 then the sequence number field MAY be ignored. 375 3.5. QoS Considerations 377 The ingress PE MAY consider the user priority (PRI) field [802.1Q] of 378 the VLAN tag header when determining the value to be placed in a QoS 379 field of the encapsulating protocol (e.g., the EXP fields of the MPLS 380 label stack or the DSCP of an IP packet). In a similar way, the 381 egress PE MAY consider the QoS field of the PSN's encapsulating 382 protocol when queuing the frame for CE-bound. 384 A PE MUST support the ability to carry the Ethernet PW as a best 385 effort service over the PSN. PRI bits are kept transparent between 386 PE devices, regardless of the QoS support of the PSN. 388 If an 802.1Q VLAN field is added at the PE, a default PRI setting of 389 zero MUST be supported, a configured default value is recommended, or 390 the value may be mapped from the QoS field of the PSN, as referred to 391 above. 393 A PE may support additional QoS support by means of one or more of 394 the following methods: 396 -i. One COS per PW End Service (PWES), mapped to a single COS PW 397 at the PSN. 398 -ii. Multiple COS per PWES mapped to a single PW with multiple 399 COS at the PSN. 400 -iii. Multiple COS per PWES mapped to multiple PWs at the PSN. 402 Examples of the cases above and details of the service mapping 403 considerations are described in Appendix B. 405 The PW guaranteed rate at the PSN level is PW provider policy based 406 on agreement with the customer, and may be different from the 407 Ethernet physical port rate. 409 3.6. Security Considerations 411 The ethernet pseudowire type is subject to all of the general 412 security considerations discussed in [PWE3-ARCH]. 414 Security achieved by access control of MAC addresses is out of scope 415 of this document. Additional security requirements related to the use 416 of PW in a switching (virtual bridging) environment are not discussed 417 here as they are not within the scope of this draft. 419 3.7. PSN MTU Requirements 421 The PSN MUST be configured with an MTU that is large enough to 422 transport a maximum sized ethernet frame which has been encapsulated 423 with a control word, a pseudowire demultiplexor, and a tunnel 424 encapsulation. If MPLS is used as the tunneling protocol, for 425 example, this is likely to be 8 or more bytes greater than the 426 largest frame size. Other tunneling protocols may have longer headers 427 and require larger MTUs. If the ingress router determines that an 428 encapsulated layer 2 PDU exceeds the MTU of the tunnel through which 429 it must be sent, the PDU MUST be dropped. If an egress router 430 receives an encapsulated layer 2 PDU whose payload length (i.e., the 431 length of the PDU itself without any of the encapsulation headers), 432 exceeds the MTU of the destination layer 2 interface, the PDU MUST be 433 dropped. 435 4. Intellectual Property Disclaimer 437 This document is being submitted for use in IETF standards 438 discussions. 440 5. References 442 [PWE3-CRTL] "Transport of Layer 2 Frames Over MPLS", 443 Martini, L., et al., draft-ietf-pwe3-control-protocol-01.txt, 444 ( work in progress ), February 2003. 446 [PWE3-ARCH] "Protocol Layering in PWE3" 447 Bryant, et al., draft-ietf-pwe3-protocol-layer-00.txt 448 ( work in progress ), November 2002. 450 [PWE3-REQ] "Requirements for Pseudo Wire Emulation Edge-to-Edge 451 (PWE3)", Xiao, X., McPherson, D., Pate, P., White, C., 452 Kompella, K., Gill, V., Nadeau, T., 453 draft-pwe3-requirements-03.txt, ( work in progress ), June 2002. 455 [PWE3-FRAME] "Framework for Pseudo Wire Emulation Edge-to-Edge 456 (PWE3)", Pate, P., Xiao, X., So, T., Malis, A., Nadeau, T., 457 White, C., Kompella, K., Johnson, T., Bryant, S., 458 draft-pate-pwe3-framework-03.txt, ( work in progress ), 459 June 2002. 461 [PW-MIB] "Pseudo Wire (PW) Management Information Base using SMIv2", 462 Zelig, D., Mantin, S., Nadeau, T., Danenberg, D., 463 draft-zelig-pw-mib-02.txt, ( work in progress), February 2002. 465 [PW-ENET-MIB] "Ethernet Pseudo Wire (PW) Management Information 466 Base", Zelig, D., Nadeau, T., draft-zelig-pw-enet-mib-00.txt, 467 ( work in progress ) February 2002. 469 [802.3] IEEE, ISO/IEC 8802-3: 2000 (E), "IEEE Standard for 470 Information technology -- Telecommunications and information 471 exchange between systems -- Local and metropolitan area networks 472 -- Specific requirements -- Part 3: Carrier Sense Multiple 473 Access with Collision Detection (CSMA/CD) Access Method and 474 Physical Layer Specifications", 2000. 476 [802.1Q] ANSI/IEEE Standard 802.1Q, "IEEE Standards for Local and 477 Metropolitan Area Networks: Virtual Bridged Local Area 478 Networks", 1998. 480 [L2TPv3] J. Lau, M. Townsley, A. Valencia, G. Zorn, I. Goyret, 481 G. Pall, A. Rubens, B. Palter, Layer Two Tunneling Protocol 482 (Version 3) "L2TPv3", work in progress, 483 draft-ietf-l2tpext-l2tp-base-03.txt, June 2002. 485 6. Author Information 487 Luca Martini 488 Level 3 Communications, LLC. 489 1025 Eldorado Blvd. 490 Broomfield, CO, 80021 491 e-mail: luca@level3.net 493 Nasser El-Aawar 494 Level 3 Communications, LLC. 495 1025 Eldorado Blvd. 496 Broomfield, CO, 80021 497 e-mail: nna@level3.net 499 Giles Heron 500 PacketExchange Ltd. 501 The Truman Brewery 502 91 Brick Lane 503 LONDON E1 6QL 504 United Kingdom 505 e-mail: giles@packetexchange.net 507 Dan Tappan 508 Cisco Systems, Inc. 509 250 Apollo Drive 510 Chelmsford, MA, 01824 511 e-mail: tappan@cisco.com 513 Eric Rosen 514 Cisco Systems, Inc. 515 250 Apollo Drive 516 Chelmsford, MA, 01824 517 e-mail: erosen@cisco.com 518 Steve Vogelsang 519 Laurel Networks, Inc. 520 Omega Corporate Center 521 1300 Omega Drive 522 Pittsburgh, PA 15205 523 e-mail: sjv@laurelnetworks.com 525 Andrew G. Malis 526 Vivace Networks, Inc. 527 2730 Orchard Parkway 528 San Jose, CA 95134 529 e-mail: Andy.Malis@vivacenetworks.com 531 Vinai Sirkay 532 Vivace Networks, Inc. 533 2730 Orchard Parkway 534 San Jose, CA 95134 535 e-mail: sirkay@technologist.com 537 Vasile Radoaca 538 Nortel Networks 539 600 Technology Park 540 Billerica MA 01821 541 e-mail: vasile@nortelnetworks.com 543 Chris Liljenstolpe 544 Cable & Wireless 545 11700 Plaza America Drive 546 Reston, VA 20190 547 e-mail: chris@cw.net 549 Kireeti Kompella 550 Juniper Networks 551 1194 N. Mathilda Ave 552 Sunnyvale, CA 94089 553 e-mail: kireeti@juniper.net 555 Tricci So 556 e-mail: tricciso@yahoo.ca 557 XiPeng Xiao 558 Redback Networks 559 300 Holger Way, 560 San Jose, CA 95134 561 e-mail: xipeng@redback.com 563 Chris Flores 564 Austin, Texas 565 e-mail: chris_flores@hotmail.com 567 David Zelig 568 Corrigent Systems 569 126, Yigal Alon St. 570 Tel Aviv, ISRAEL 571 e-mail: davidz@corrigent.com 573 Raj Sharma 574 Luminous Netwokrs, Inc. 575 10460 Bubb Road 576 Cupertino, CA 95014 577 e-mail: raj@luminous.com 579 Nick Tingle 580 TiMetra Networks 581 274 Ferguson Drive 582 Mountain View, CA 94043 583 e-mail: nick@timetra.com 585 Sunil Khandekar 586 TiMetra Networks 587 274 Ferguson Drive 588 Mountain View, CA 94043 589 email: sunil@timetra.com 591 Loa Andersson 592 Utfors 593 P.O. Box 525, 594 SE-169 29 Solna, Sweden 595 e-mail: loa.andersson@utfors.se 597 Appendix A - Interoperability Guidelines 599 Configuration Options 601 The following is a list of the configuration options for a point-to- 602 point Ethernet PW based on the reference points of Figure 3: 604 --------------|---------------|---------------|------------------ 605 Service and | Encap on C |Operation at B | Remarks 606 Encap on A | |ingress/egress | 607 --------------|---------------|---------------|------------------ 608 1) Raw | Raw - Same as | | 609 | A | | 610 | | | 611 --------------|---------------|---------------|------------------ 612 2) Tag1 | Tag2 |Optional change| VLAN can be 613 | |of VLAN value | 0-4095 614 | | | Change allowed in 615 | | | both directions 616 --------------|---------------|---------------|------------------ 617 3) No Tag | Tag |Add/remove Tag | Tag can be 618 | |field | 0-4095 619 | | | (note i) 620 | | | 621 --------------|---------------|---------------|------------------ 622 4) Tag | No Tag |Remove/add Tag | (note ii) 623 | |field | 624 | | | 625 | | | 626 --------------|---------------|---------------|------------------ 628 Figure 4: Configuration Options 630 Allowed combinations: 632 Raw and other services are not allowed on the same physical port (A). 633 All other combinations are allowed, except that conflicting VLANs on 634 (A) are not allowed. 636 Notes: 638 -i. Mode #3 MAY be limited to adding VLAN NULL only, since 639 change of VLAN or association to specific VLAN can be done 640 at the PW CE-bound side. 642 -ii. Mode #4 exists in layer 2 switches, but is not recommended 643 when operating with PW since it may not preserve the user's 644 PRI bits. If there is a need to remove the VLAN tag (for 645 TLS at the other end of the PW) it is recommended to use 646 mode #2 with tag2=0 (NULL VLAN) on the PW and use mode #3 at 647 the other end of the PW. 649 IEEE 802.3x Flow Control Considerations 651 If the receiving node becomes congested, it can send a special frame, 652 called the PAUSE frame, to the source node at the opposite end of the 653 connection. The implementation MUST provide a mechanism for 654 terminating PAUSE frames locally (i.e. at the local PE). It MUST 655 operate as follows: 657 PAUSE frames received on a local Ethernet port SHOULD cause the PE 658 device to buffer, or to discard, further Ethernet frames for that 659 port until the PAUSE condition is cleared. Optionally, the PE MAY 660 simply discard PAUSE frames. 662 If the PE device wishes to pause data received on a local Ethernet 663 port (perhaps because its own buffers are filling up or because it 664 has received notification of congestion within the PSN) then it MAY 665 issue a PAUSE frame on the local Ethernet port, but MUST clear this 666 condition when willing to receive more data. 668 Appendix B - QoS Details 670 Section 3.7 describes various modes for supporting PW QOS over the 671 PSN. Examples of the above for a point to point VLAN service are: 673 - The classification to the PW is based on VLAN field only, 674 regardless of the user PRI bits. The PW is assigned a specific 675 COS (marking, scheduling, etc.) at the tunnel level. 677 - The classification to the PW is based on VLAN field, but the PRI 678 bits of the user is mapped to different COS marking (and network 679 behavior) at the PW level. Examples are DiffServ coding in case 680 of IP PSN, and E-LSP in MPLS PSN. 682 - The classification to the PW is based on VLAN field and the PRI 683 bits, and frames with different PRI bits are mapped to different 684 PWs. An example is to map a PWES to different L-LSPs in MPLS PSN 685 in order to support multiple COS over an L-LSP capable network, 686 or to multiple L2TPv3 sessions [L2TPv3]. 688 The specific value to be assigned at the PSN for various COS is 689 out of scope for this document. 691 Adaptation of 802.1Q COS to PSN COS 693 It is not required that the PSN will have the same COS definition of 694 COS as defined in [802.1Q], and the mapping of 802.1Q COS to PSN COS 695 is application specific and depends on the agreement between the 696 customer and the PW provider. However, the following principles 697 adopted from 802.1Q table 8-2 MUST be met when applying set of PSN 698 COS based on user's PRI bits. 700 ---------------------------------- 701 |#of available classes of service| 702 -------------||---|---|---|---|---|---|---|---| 703 User || 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 704 Priority || | | | | | | | | 705 =============================================== 706 0 Best Effort|| 0 | 0 | 0 | 1 | 1 | 1 | 1 | 2 | 707 (Default) || | | | | | | | | 708 ------------ ||---|---|---|---|---|---|---|---| 709 1 Background || 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 710 || | | | | | | | | 711 ------------ ||---|---|---|---|---|---|---|---| 712 2 Spare || 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 713 || | | | | | | | | 714 ------------ ||---|---|---|---|---|---|---|---| 715 3 Excellent || 0 | 0 | 0 | 1 | 1 | 2 | 2 | 3 | 716 Effort || | | | | | | | | 717 ------------ ||---|---|---|---|---|---|---|---| 718 4 Controlled || 0 | 1 | 1 | 2 | 2 | 3 | 3 | 4 | 719 Load || | | | | | | | | 720 ------------ ||---|---|---|---|---|---|---|---| 721 5 Interactive|| 0 | 1 | 1 | 2 | 3 | 4 | 4 | 5 | 722 Multimedia || | | | | | | | | 723 ------------ ||---|---|---|---|---|---|---|---| 724 6 Interactive|| 0 | 1 | 2 | 3 | 4 | 5 | 5 | 6 | 725 Voice || | | | | | | | | 726 ------------ ||---|---|---|---|---|---|---|---| 727 7 Network || 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 728 Control || | | | | | | | | 729 ------------ ||---|---|---|---|---|---|---|---| 731 Figure 5: IEEE 802.1Q COS Service Mapping 733 Drop precedence 735 The 802.1P standard does not support drop precedence, therefore from 736 the PW PE-bound point of view there is no mapping required. It is 737 however possible to mark different drop precedence for different PW 738 frames based on the operator policy and required network behavior. 739 This functionality is not discussed further here. 741 PSN QOS support and signaling of QOS is out of scope of this 742 document.