idnits 2.17.1 draft-vkompella-pwe3-ethernet-pw-bis-00.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 576. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 587. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 594. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 600. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4448]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (July 2008) is 5756 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) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) -- No information found for draft-balus-l2vpn-vpls-802 - is the name correct? == Outdated reference: A later version (-04) exists of draft-sajassi-l2vpn-vpls-pbb-interop-02 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Document Vach Kompella 2 Category: Standards Track Florin Balus 3 Expires: August 2008 Alcatel-Lucent 5 Andrew Malis 6 Verizon 8 July 2008 10 Generic Ethernet Pseudowire 11 draft-vkompella-pwe3-ethernet-pw-bis-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 21, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This draft proposes a simpler approach to handling various 45 encapsulations of Ethernet packets over a pseudowire, over the 46 existing Ethernet Pseudowire definition in [RFC4448]. 48 Conventions used in this document 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in [RFC2119]. 54 1. Introduction 56 In this draft, we describe a methodology for encapsulating Ethernet 57 packets in pseudowires that eliminates the need for multiple 58 encapsulation formats and pseudowire code-points when Ethernet 59 formats change. From a service provider perspective it simplifies 60 the introduction of new technology by minimizing the required 61 network upgrades. This draft extends the concepts already published 62 in [RFC4448]. 64 [RFC4448] defines two different pseudowire types for Ethernet 65 packets, one where the packet transported over the pseudowire must 66 have a service delimiting VLAN tag (Ethernet tagged type), and the 67 other where it does not need to have one (Ethernet type) as per 68 [IANA PWE3]. The original justification for the tagged PW type came 69 from the need to accommodate routers that could not handle standard 70 Ethernet functions like imposing, stripping or rewriting VLAN tags. 72 This draft has been written in response to the following statements 73 from [RFC4448] and consequent concerns that as new Ethernet formats 74 (such as Provider Backbone Bridging, PBB I-tag [802.1ah]) are 75 defined, that corresponding pseudowires have to be defined: 77 - For an Ethernet VLAN PW, VLAN tag rewrite can be achieved by 78 NSP at the egress PE, which is outside the scope of this 79 document ([RFC4448], Section 3). 81 - The Ethernet or Ethernet VLAN PW only supports homogeneous 82 Ethernet frame type across the PW; both ends of the PW must be 83 either tagged or untagged. Heterogeneous frame type support 84 achieved with NSP functionality is outside the scope of this 85 document ([RFC4448], Section 3). 87 This document proposes a Generic Ethernet PW (GE-PW) that extends 88 the definition of Ethernet PWs and their usage in the existing 89 L2VPNs (VPWS, VPLS) and simplifies the development of future 90 solutions that require transport of Ethernet frames over a 91 pseudowire. 93 2. The Generalized Ethernet Pseudowire 95 To define the Generalized Ethernet Pseudowire (GE-PW) we need to 96 describe the following functions: 98 - the packets eligible to be placed in a GE-PW 99 - the processing functions outside the scope of the GE-PW 100 - the processing functions within the scope of the GE-PW 102 2.1. Eligible Packets in the GE-PW 104 Any ethernet packet defined by the IEEE is an eligible packet for 105 the GE-PW, regardless of the type of tags it contains - e.g. IEEE 106 802.1Q, 802.1ad, 802.1ah tags. The Ethernet header is defined with a 107 set of well defined code points that can be used by the NSP to 108 identify the type of tag and the following header fields and to 109 process the frame accordingly. 111 A new Interface Parameter sub-TLV is defined to describe the 112 capabilities of the NSP function to adapt different ethernet 113 encapsulations as packets arrive from the pseudowire and are 114 delivered to the attachment circuit. Section 4 describes the 115 applicability and the format for the new sub-TLV. 117 2.2. Processing outside the scope of the GE-PW 119 When an ethernet packet is received on an attachment circuit (AC), 120 it may be processed before being passed to the PW termination 121 function. This processing is done by the NSP function which has the 122 responsibility of removing service delimiting encapsulations on the 123 packet, and identifying the PW that the packet is bound for. 125 When a packet arrives on a PW, the PW service label is used to 126 identify the particular service instance and subsequently the NSP 127 function that is applied to the ethernet packet at the egress PE. 128 The NSP function puts on the appropriate ethernet encapsulation 129 before passing the packet on to the attachment circuit(s) associated 130 with the NSP. 132 The processing of the Ethernet frames at the ingress and egress NSPs 133 are outside the scope of the GE-PW. 135 2.3. Processing within the scope of the GE-PW 137 A packet passed to the PW termination function by the ingress NSP at 138 the ingress PE is encapsulated with the appropriate PW label and is 139 passed to the PSN function for encapsulation and transport to the 140 egress PE. A packet arriving on a pseudowire egress has its PW label 141 popped, and the resulting packet is passed to the appropriate NSP 142 instance. 144 3. Detailed processing steps 146 There are four main processing points in using a pseudowire: the 147 ingress NSP function, the ingress PW termination function, the 148 egress PW termination function, and the egress NSP function. 150 Although just the PW termination functions are relevant for GE-PW, 151 this section discusses how the GE-PW can be used with different 152 types of existing NSPs to emulate existing and future services. 154 In order to more clearly illustrate how a GE-PW may be used to 155 provide pseudowire services, we introduce the following terms. 156 These terms are to be used as a guideline to understanding the 157 behavior of a GE-PW, and in no way define an implementation: 159 - In-NSP(packet, options): the ingress NSP function, includes the 160 ingress attachment circuit (AC) function 161 - In-PW(packet, options): the ingress PW termination function 162 - Out-PW(packet, options): the egress PW termination function 163 - Out-NSP(packet, options): the egress NSP function, includes the 164 egress AC function 166 In addition, we define the pseudowire context (PWC) as the construct 167 which has, at ingress, the following information: 169 - the incoming encapsulation of the packet 170 - the In-NSP function to be applied on the packet 171 - the In-PW termination function to be applied 172 - the ingress PSN encapsulation information to be applied 174 and at egress: 176 - the Out-PW termination function to be applied 177 - the Out-NSP function to be applied on the packet 178 - the outgoing encapsulation of the packet on the attachment 179 circuit 181 Using the above functions, we will define actions at the various 182 stages of the packet through the network that affect its behavior. 183 In particular, we will show the capabilities in describing the two 184 existing Ethernet pseudowires, and introduction of a number of 185 standard VLL service types that are enabled as a consequence of 186 implementing the GE-PW methods. 188 As the packet arrives from the customer, at the In-NSP function, the 189 NSP may remove the FCS and any extraneous packet header information 190 that is locally significant [RFC4448]. The optional method described 191 in [RFC4720] can be used to achieve payload integrity transparency. 192 In particular, the function of the In-NSP is to render the packet 193 ready for consumption by the remote Out-NSP function. In other 194 words, the In-NSP must replace, remove or impose VLAN tags, PBB I- 195 tag or any required Ethernet headers so that the packet is 196 recognizable by the egress NSP. It performs also functions specific 197 to the type of native service that is rendered at the ingress PE, 198 for example MAC switching, MAC learning, packet replication for 199 VPLS. Finally, the In-NSP function also identifies the pseudowire 200 that is associated with the attachment circuit over which the packet 201 arrived. If, for example, the packet arrived on a VLAN tagged port, 202 and the VLAN tag identifies the attachment circuit, then the In-NSP 203 is responsible for recovering the VLAN tag and identifying the 204 attachment circuit. It is out of the scope of this document to 205 define how attachment circuits are represented and associated with 206 pseudowires. 208 The resulted Ethernet frame, as delivered by the In-NSP is not 209 modified in any way by the In-PW function. The In-PW termination 210 simply imposes the PW encapsulation for the packet. This may be 211 introducing the optional control word and its fields, depending on 212 how the pseudowire was configured and which options were negotiated. 213 Following this step, the PW label for the packet is imposed. 214 Subsequently, the appropriate forwarding engine component imposes 215 the PSN encapsulation. How the PSN encapsulation is determined and 216 imposed for a particular pseudowire is out of the scope of this 217 document. 219 Once the packet is delivered to the network, the PSN encapsulation 220 directs the packet towards the egress endpoint of the pseudowire. 221 At the egress, the PSN encapsulation is removed. Following this, 222 the packet is delivered to the Out-PW termination function. The 223 Out-PW function removes the PW encapsulation. This involves 224 removing both the PW label and the optional control word (if 225 negotiated and present). In addition, the PW label is used to 226 identify an Out-NSP function associated with one or more attachment 227 circuit(s) that is/are the outgoing interface(s) to the customer. 228 The packet is handed to the Out-NSP function which will complete 229 processing and hand the packet to the egress attachment circuit. 231 The Out-NSP function has the responsibility for processing the 232 packet in order to prepare it for the egress attachment circuit. 234 This would involve, e.g., the insertion, deletion or replacement of 235 different Ethernet tags or other Ethernet encapsulation so that it 236 can accommodate different types of ACs, for example port, tagged 237 with one VLAN, tagged with multiple VLANs (QinQ [802.1ad]) or PBB I- 238 tags. 240 There are a number of functions that are out of the scope of this 241 specification. The primary reason they are out of scope is that 242 they are implementation dependent, and do not relate to the standard 243 definition of the Generalized Ethernet Pseudowire (GE-PW). For 244 example, whether the incoming attachment circuit has a pointer to 245 the In-NSP function or an index into a table, or how the pseudowire 246 is identified within the forwarding engine are not material to the 247 definition of the GE-PW. The definition of what the NSP function has 248 to perform is also a matter of local configuration. 250 4. Control Plane 252 All the PW Setup and Maintenance procedures described in [RFC4447] 253 apply to the GE-PW. There is no need for a new PW type. The Ethernet 254 type (0x0005) may be used [IANA PWE3] as the new GE-PW procedures 255 are backwards compatible with an existing implementation using 256 Ethernet type PW - see section 6. The function of an Ethernet tagged 257 PW can be also emulated in the NSPs with a GE-PW. 259 There might be some network scenarios where the required NSP 260 capabilities need to be signaled between PEs. This might be the case 261 for certain implementations that need to know what kind of NSP they 262 need to instantiate for certain PW. Also in some scenarios the 263 Service Providers might need to make sure the capabilities of the 264 related NSPs match. 266 An optional NSP capabilities sub-TLV for the Interface Parameters 267 TLV is defined to allow the signaling of NSP capabilities between 268 Layer 2 PEs. 270 The NSP Capabilities sub-TLV MAY be included in the related LDP 271 messages for PW setup and maintenance if the transmitting PE needs 272 to verify that the remote NSP is capable of performing certain 273 functionality. Note that there are cases when the NSP 274 functionalities do not need to match. For example in a PBB 275 deployment using HVPLS, a PBB BEB may be connected via an Ethernet 276 PW to a PBB BCB [PBB-VPLS]. The NSP for the PBB BEB performs full 277 PBB functions (I and B-components) while the NSP for the related PBB 278 BCB performs just regular Ethernet switching using the Backbone 279 Header (B-component) [PBB-VPLS]. 281 On reception of the NSP Capabilities sub-TLV a Layer 2 PE MUST 282 reject the PW Setup if it does not support or if the related NSP is 283 not properly configured to support any of the required NSP 284 capabilities. If the Layer 2 PE does not understand the NSP 285 Capabilities sub-TLV, it should continue the processing of the 286 interface parameters while silently discarding the unknown interface 287 parameter as per [RFC4447] section 5.5. 289 The format of the NSP sub-TLV follows the standard format defined 290 for all Interface Parameter sub-TLVs [RFC4447]: 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Sub-TLV Type | Length | Variable Length Value | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Variable Length Value | 298 | " | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 The type for NSP Capabilities sub-TLV is to be assigned by IANA. The 302 first 2 Bytes of the value field define the capability whereas the 303 rest of the value field is used to indicate parameters specific to 304 the required capability ID. A list of code points for the 305 capabilities is to be added as the applications are being defined. 306 Examples of possible capabilities ID are VPLS, PBB-VPLS BEB, PBB- 307 VPLS BCB with or without I-tag swapping [PBB-VPLS]. 309 5. The Control Word 311 The OPTIONAL control word specified in [RFC4385] MAY be used for the 312 GE-PW. 314 6. Backwards Compatibility with existing Ethernet PW implementations 316 The NSP of a GE-PW capable PE that needs to interoperate with older 317 implementations may be manually configured to fully emulate the 318 behavior of an existing Ethernet PW NSP as described in section 4.1 319 and 4.4 of [RFC4448]. 321 The NSP Capabilities sub-TLV may be also used to automatically 322 identify the old Ethernet PW implementation. The GE-PW capable PE 323 may use the NSP Capabilies indication to identify the regular 324 Ethernet PW implementations. 326 The GE-PW capable PE MUST always include the NSP capability sub-TLV 327 in the PW setup message. If the PW signaling received from the 328 remote PE does not contain the NSP Capability sub-TLV, the local PE 329 switches to regular Ethernet PW mode. If the other Layer 2 PE does 330 not understand the NSP Capabilities sub-TLV, it should continue the 331 processing of the interface parameters while silently discarding the 332 unknown interface parameter as per [RFC4447] section 5.5. 334 7. Emulating existing Ethernet Services 336 The rationale for redefining the two variants of the Ethernet 337 pseudowires is that the GE-PW is a more powerful construct that 338 subsumes both of them, prevents the future proliferation of other 339 Ethernet PW types and allows the definition of many more services 340 than are allowed by strictly following the existing pseudowire 341 definitions. 343 The following examples demonstrate that the right set of NSP and PW 344 functions yield not just the known ethernet VPWS, VPLS behaviors 345 induced by the two existing Ethernet pseudowires, but additional 346 models used by service providers, that are not strictly compliant to 347 the existing pseudowires. 349 7.1. GE-PW applicability to Ethernet VPWS 351 The GE-PW allows for emulation of an Ethernet point-to-point service 352 between different types of Ethernet Attachment Circuits by simply 353 emulating in the ingress NSP the required behavior. Specifically the 354 attachment circuits (ACs) may be defined at the two PEs to represent 355 the whole port, one or more VLAN(s) (tagged, one service delimiting 356 VLAN) or a VLAN combination (QinQ/[802.1ad], tagged with two service 357 delimiting VLANs) and are mapped to the point-to-point NSP function 358 in each PE through local association. 360 As a result the packet arriving on the local AC is classified as 361 belonging to an ingress NSP who may be configured to 362 remove/rewrite/add one or more VLAN tags before forwarding the 363 packet to the GE-PW termination function that will encapsulate it 364 for transport over PSN core. 365 Similarly the egress NSP can manipulate encapsulation received over 366 GE-PW, adding, replacing or removing one or more tags of different 367 types as desired to accommodate different types of egress Ethernet 368 interfaces and AC definitions, for example port, tagged with one 369 VLAN, tagged with multiple VLANs (QinQ [802.1ad]). 371 7.2. GE-PW Applicability to VPLS 373 The GE-PW can be used to serve the interconnect needs for the VPLS 374 Forwarders. The previous section discussed how the GE-PW can replace 375 the existing Ethernet PW types from a point to point forwarding 376 perspective, handling also the VLAN tags on a per local AC basis. 377 For VPLS the NSPs will have to replicate the same functions but for 378 multiple ACs, handling also the Ethernet switching functions (e.g. 379 MAC switching, MAC Learning, Packet Replication) as described in 380 [RFC4664] and [RFC4762]. 382 7.3. GE-PW for point-to-point transport of PBB over Pseudowires 384 When a PW interconnects two PBB access networks (see Figure 1) there 385 may be a need to use the PBB ISID Tag (I-tag) [802.1ah] to perform 386 the mapping to/from ACs. The PBB I-tag can be processed as an 387 extended tag that may need to be changed at ingress / egress PE. The 388 related NSPs can be configured to identify the I-tag (using the 389 Ethernet type assigned by [802.1ah]) and to change different I-tag 390 fields, for example the 24 bits ISID or the QoS information. The GE- 391 PW termination function will not need to change to accommodate this 392 new type of service. The required PW encapsulation described in the 393 previous sections will be added before the PBB Backbone MAC header. 395 For example assuming the PE depicted in Figure 1 [RFC4448] is 396 connected to a PBB network (PBBN) and the I-tag field is used to 397 defined the AC. 399 +------------------------------------------+ 400 | PE | 401 +---+ +-+ +-----+ +------+ +------+ +-+ 402 | | |P| | | |PW ter| | PSN | |P| 403 | |<==|h|<=| NSP |<=|minati|<=|Tunnel|<=|h|<== From PSN 404 | | |y| | | |on | | | |y| 405 | P | +-+ +-----+ +------+ +------+ +-+ 406 | B | | | 407 | B | +-+ +-----+ +------+ +------+ +-+ 408 | N | |P| | | |PW ter| | PSN | |P| 409 | |==>|h|=>| NSP |=>|minati|=>|Tunnel|=>|h|==> To PSN 410 | | |y| | | |on | | | |y| 411 +---+ +-+ +-----+ +------+ +------+ +-+ 412 | | 413 +------------------------------------------+ 415 Figure 1: PBB PW 417 The ingress PE may be configured to check on the incoming PBB 418 packets the ISID value of the I-tag to determine the AC and 419 subsequently the ingress NSP. The ingress NSP may be configured to 420 change the values of different I-tag fields (for example the ISID, 421 PCP, DEI bits). 423 Next the GE-PW termination functions will handle the PW header that 424 will transport it throughout the PSN core and towards the egress 425 NSP. 427 The egress NSP may perform different functions depending on the type 428 of egress AC: e.g. 429 - if the access network is part of a different PBB service domain 430 it may re-write the I-tag field. 431 - if the access domain is a QinQ domain it may remove the PBB 432 header altogether assuming it supports this capability. 434 7.4. PBB-VPLS Applicability 436 The GE-PWs can be also applied to provide the interconnect between 437 PBB-VPLS entities as described in [PBB-VPLS]. On top of the I-tag 438 identification, processing functions described in the previous 439 section, the related NSPs can emulate the PBB components described 440 in [802.1ah], for example the Backbone (B) and Customer (I) 441 components. For example, in a PBB-VPLS PE, as the In-NSP function 442 receive the packet on the local AC, it performs the Customer MAC 443 switching and possibly the mapping to the Backbone MAC address 444 specific to the I-component [802.1ah]. Subsequently the same In-NSP 445 function will perform the Backbone MAC switching function 446 characteristic to the B-component [802.1ah]. If the packet is to be 447 transported over the PW infrastructure it will be handled to the in- 448 PW function as per [PBB-VPLS]. From now on the processing steps 449 described in section 3 apply. Same for the Out-PW termination 450 function in the other PE. The PW service label is used by the Out-PW 451 function to identify the Out-NSP to which the packet is handled. 452 There are two possibilities for the Out-NSP. 454 If the PE is the final termination point for PBB, the Out-NSP runs 455 both I and B components (PBB BEB node in [802.1ah]). It will handle 456 first the Ethernet switching functions for Backbone MAC header 457 followed by the switching functions for Customer MAC header. As the 458 packet is handled to the egress AC the regular AC processing 459 functions described in section 3 apply. 461 If an HVPLS architecture is used the next PE in the chain may be 462 just an intermediate switching point for Backbone MAC header. The 463 related Out-NSP function runs just the PBB B-component (PBB BCB node 464 in [802.1ah]). It will handle just the Ethernet switching functions 465 for Backbone MAC header. The possible results may be switching the 466 packet back to another In-PW function for further forwarding towards 467 the PBB-VPLS PE (PBB BEB). 469 [PBB-VPLS] and [PBB-Interop] describe the requirements, 470 interoperability and solution in detail. 472 Other applications are possible and require just the definition of 473 the required NSP functions. 475 8. Management Model 477 There will be a new object to describe the NSP compatibility 478 capabilities [PW MIB]. 480 9. Acknowledgements 482 The authors gratefully acknowledge the contributions of Nabil Bitar, 483 and Dimitri Papadimitriou. 485 10. References 487 Normative References 489 [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and 490 G. Heron, "Pseudowire Setup and Maintenance Using the Label 491 Distribution Protocol (LDP)", RFC 4447, April 2006. 493 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 494 "Encapsulation Methods for Transport of Ethernet over MPLS 495 Networks", RFC 4448, April 2006. 497 [IANA PWE3] Martini, L., "IANA Allocations for Pseudowire Edge to 498 Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 500 [RFC4385] Bryant, S., Swallow, G., and D. McPherson, "Pseudowire 501 Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS 502 PSN", RFC 4385, February 2006. 504 [RFC4720] Malis, A., Allan, D.,and N. Del Regno, "Pseudowire 505 Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention", RFC 506 4720, November 2006 508 [802.1ad] IEEE 802.1ad-2005 "Virtual Bridged Local Area Networks, 509 Amendment 4: Provider Bridges", December 7, 2005 510 [802.1ah] IEEE Draft P802.1ah/D4.2 "Virtual Bridged Local Area 511 Networks, Amendment 6: Provider Backbone Bridges", Work in Progress, 512 March 26, 2008 514 [RFC4762] Lasserre, M. and Kompella, V. (Editors), "Virtual Private 515 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 516 Signaling", RFC 4762, January 2007. 518 [PW MIB] T. Nadeau, and D. Zelig "Pseudowire (PW) Management 519 Information Base (MIB)", draft-ietf-pwe3-pw-mib-14.txt, January 2008 520 ( work in progress ). 522 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 523 Requirement Levels", BCP 14, RFC 2119, March 1997. 525 Informative References 527 [RFC4664] Andersson, L. and Rosen, E. (Editors),"Framework for Layer 528 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006. 530 [PBB-VPLS] F. Balus, et Al. "VPLS Extensions for Provider Backbone 531 Bridging", draft-balus-l2vpn-vpls-802.1ah-02.txt, February 2008 ( 532 work in progress ). 534 [PBB-Interop] A. Sajassi, et Al. "VPLS Interoperability with 535 Provider Backbone Bridges", draft-sajassi-l2vpn-vpls-pbb-interop- 536 02.txt, November 2007 ( work in progress ). 538 11. Security Considerations 540 No new security issues arise out of the extensions proposed here. 542 12. IANA Considerations 544 A new IANA allocation is required to describe NSP compatibility 545 capabilities. 547 13. Authors' Addresses 549 Andrew Malis 550 Verizon 551 andrew.g.malis@verizon.com 553 Vach Kompella 554 Alcatel-Lucent 555 vach.kompella@alcatel-lucent.com 557 Florin Balus 558 Alcatel-Lucent 559 florin.balus@alcatel-lucent.com 561 14. Full Copyright Statement 563 Copyright (C) The IETF Trust (2008). 565 This document is subject to the rights, licenses and restrictions 566 contained in BCP 78, and except as set forth therein, the authors 567 retain all their rights. 569 This document and the information contained herein are provided on 570 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 571 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 572 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 573 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 574 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 575 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 576 FOR A PARTICULAR PURPOSE. 578 15. Intellectual Property 580 The IETF takes no position regarding the validity or scope of any 581 Intellectual Property Rights or other rights that might be claimed 582 to pertain to the implementation or use of the technology described 583 in this document or the extent to which any license under such 584 rights might or might not be available; nor does it represent that 585 it has made any independent effort to identify any such rights. 586 Information on the procedures with respect to rights in RFC 587 documents can be found in BCP 78 and BCP 79. 589 Copies of IPR disclosures made to the IETF Secretariat and any 590 assurances of licenses to be made available, or the result of an 591 attempt made to obtain a general license or permission for the use 592 of such proprietary rights by implementers or users of this 593 specification can be obtained from the IETF on-line IPR repository 594 at http://www.ietf.org/ipr. 596 The IETF invites any interested party to bring to its attention any 597 copyrights, patents or patent applications, or other proprietary 598 rights that may cover technology that may be required to implement 599 this standard. Please address the information to the IETF at ietf- 600 ipr@ietf.org. 602 16. Acknowledgments 604 Funding for the RFC Editor function is provided by the IETF 605 Administrative Support Activity (IASA).