idnits 2.17.1 draft-vkompella-pwe3-ethernet-pw-bis-01.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 24. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 642. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 653. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 660. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 666. 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 5764 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-03 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: January 2009 Alcatel-Lucent 5 Andrew Malis 6 Verizon 8 Shane Amante 9 Level 3 11 Giles Heron 12 British Telecom 14 July 2008 16 Generic Ethernet Pseudowire 17 draft-vkompella-pwe3-ethernet-pw-bis-01.txt 19 Status of this Memo 21 By submitting this Internet-Draft, each author represents that any 22 applicable patent or other IPR claims of which he or she is aware 23 have been or will be disclosed, and any of which he or she becomes 24 aware will be disclosed, in accordance with Section 6 of BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other documents 33 at any time. It is inappropriate to use Internet-Drafts as 34 reference material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire in January 2009. 44 Copyright Notice 46 Copyright (C) The IETF Trust (2008). 48 Abstract 50 This draft proposes a simpler approach to handling various 51 encapsulations of Ethernet packets over a pseudowire, over the 52 existing Ethernet Pseudowire definition in [RFC4448]. 54 Conventions used in this document 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in [RFC2119]. 60 1. Introduction 62 In this draft, we describe a methodology for encapsulating Ethernet 63 packets in pseudowires that eliminates the need for multiple 64 encapsulation formats and pseudowire code-points when Ethernet 65 formats change. This draft extends the concepts already published 66 in [RFC4448]. 68 [RFC4448] defines two different pseudowire types for Ethernet 69 packets, one where the packet transported over the pseudowire must 70 have a service delimiting VLAN tag (Ethernet tagged type), and the 71 other where it does not need to have one (Ethernet type) as per 72 [IANA PWE3]. The original justification for the tagged PW type came 73 from the need to accommodate routers that could not handle standard 74 Ethernet functions like imposing, stripping or rewriting VLAN tags. 76 This draft has been written in response to the following statements 77 from [RFC4448] and consequent concerns that as new Ethernet formats 78 (such as Provider Backbone Bridging, PBB I-tag [802.1ah]) are 79 defined, corresponding pseudowires have to be defined: 81 - For an Ethernet VLAN PW, VLAN tag rewrite can be achieved by 82 NSP at the egress PE, which is outside the scope of this 83 document ([RFC4448], Section 3). 85 - The Ethernet or Ethernet VLAN PW only supports homogeneous 86 Ethernet frame type across the PW; both ends of the PW must be 87 either tagged or untagged. Heterogeneous frame type support 88 achieved with NSP functionality is outside the scope of this 89 document ([RFC4448], Section 3). 91 This document proposes a Generic Ethernet PW (GE-PW) that extends 92 the definition of Ethernet PWs and their usage in the existing 93 L2VPNs (VPWS, VPLS) and simplifies the development of future 94 solutions that require transport of Ethernet frames over a 95 pseudowire. 97 2. The Generalized Ethernet Pseudowire 99 To define the Generalized Ethernet Pseudowire (GE-PW) we need to 100 describe the following functions: 102 - the packets eligible to be placed in a GE-PW 103 - the processing functions outside the scope of the GE-PW 104 - the processing functions within the scope of the GE-PW 106 2.1. Eligible Packets in the GE-PW 108 Any ethernet packet defined by the IEEE is an eligible packet for 109 the GE-PW, regardless of the type of tags it contains - e.g. IEEE 110 802.1Q, 802.1ad, 802.1ah tags. The Ethernet header is defined with a 111 set of well defined code points that can be used by the NSP to 112 identify the type of tag and the following header fields and to 113 process the frame accordingly. 115 A new Interface Parameter sub-TLV is defined to describe the 116 capabilities of the NSP function to adapt different ethernet 117 encapsulations as packets arrive from the pseudowire and are 118 delivered to the attachment circuit. Section 4 describes the 119 applicability and the format for the new sub-TLV. 121 2.2. Processing outside the scope of the GE-PW 123 When an ethernet packet is received on an attachment circuit (AC), 124 it may be processed before being passed to the PW termination 125 function. This processing is done by the NSP function which has the 126 responsibility of removing service delimiting encapsulations on the 127 packet, and identifying the PW that the packet is bound for. 129 When a packet arrives on a PW, the PW service label is used to 130 identify the particular service instance and subsequently the NSP 131 function that is applied to the ethernet packet at the egress PE. 132 The NSP function puts on the appropriate ethernet encapsulation 133 before passing the packet on to the attachment circuit(s) associated 134 with the NSP. 136 The processing of the Ethernet frames at the ingress and egress NSPs 137 are outside the scope of the GE-PW. 139 2.3. Processing within the scope of the GE-PW 141 A packet passed to the PW termination function by the ingress NSP at 142 the ingress PE is encapsulated with the appropriate PW label and is 143 passed to the PSN function for encapsulation and transport to the 144 egress PE. A packet arriving on a pseudowire egress has its PW label 145 popped, and the resulting packet is passed to the appropriate NSP 146 instance. 148 3. Detailed processing steps 150 There are four main processing points in using a pseudowire: the 151 ingress NSP function, the ingress PW termination function, the 152 egress PW termination function, and the egress NSP function. 154 Although just the PW termination functions are relevant for GE-PW, 155 this section discusses how the GE-PW can be used with different 156 types of existing NSPs to emulate existing and future services. 158 In order to more clearly illustrate how a GE-PW may be used to 159 provide pseudowire services, we introduce the following terms. 160 These terms are to be used as a guideline to understanding the 161 behavior of a GE-PW, and in no way define an implementation: 163 - In-NSP(packet, options): the ingress NSP function, includes the 164 ingress attachment circuit (AC) function 165 - In-PW(packet, options): the ingress PW termination function 166 - Out-PW(packet, options): the egress PW termination function 167 - Out-NSP(packet, options): the egress NSP function, includes the 168 egress AC function 170 In addition, we define the pseudowire context (PWC) as the construct 171 which has, at ingress, the following information: 173 - the incoming encapsulation of the packet 174 - the In-NSP function to be applied on the packet 175 - the In-PW termination function to be applied 176 - the ingress PSN encapsulation information to be applied 178 and at egress: 180 - the Out-PW termination function to be applied 181 - the Out-NSP function to be applied on the packet 182 - the outgoing encapsulation of the packet on the attachment 183 circuit 185 Using the above functions, we will define actions at the various 186 stages of the packet through the network that affect its behavior. 187 In particular, we will show the capabilities in describing the two 188 existing Ethernet pseudowires, and introduction of a number of 189 standard VLL service types that are enabled as a consequence of 190 implementing the GE-PW methods. 192 As the packet arrives from the customer, at the In-NSP function, the 193 NSP may remove the FCS and any extraneous packet header information 194 that is locally significant [RFC4448]. The optional method described 195 in [RFC4720] can be used to achieve payload integrity transparency. 196 In particular, the function of the In-NSP is to render the packet 197 ready for consumption by the remote Out-NSP function. In other 198 words, the In-NSP must replace, remove or impose VLAN tags, PBB I- 199 tag or any required Ethernet headers so that the packet is 200 recognizable by the egress NSP. It performs also functions specific 201 to the type of native service that is rendered at the ingress PE, 202 for example MAC switching, MAC learning, packet replication for 203 VPLS. Finally, the In-NSP function also identifies the pseudowire 204 that is associated with the attachment circuit over which the packet 205 arrived. If, for example, the packet arrived on a VLAN tagged port, 206 and the VLAN tag identifies the attachment circuit, then the In-NSP 207 is responsible for recovering the VLAN tag and identifying the 208 attachment circuit. It is out of the scope of this document to 209 define how attachment circuits are represented and associated with 210 pseudowires. 212 The resulted Ethernet frame, as delivered by the In-NSP is not 213 modified in any way by the In-PW function. The In-PW termination 214 simply imposes the PW encapsulation for the packet. This may be 215 introducing the optional control word and its fields, depending on 216 how the pseudowire was configured and which options were negotiated. 217 Following this step, the PW label for the packet is imposed. 218 Subsequently, the appropriate forwarding engine component imposes 219 the PSN encapsulation. How the PSN encapsulation is determined and 220 imposed for a particular pseudowire is out of the scope of this 221 document. 223 Once the packet is delivered to the network, the PSN encapsulation 224 directs the packet towards the egress endpoint of the pseudowire. 225 At the egress, the PSN encapsulation is removed. Following this, 226 the packet is delivered to the Out-PW termination function. The 227 Out-PW function removes the PW encapsulation. This involves 228 removing both the PW label and the optional control word (if 229 negotiated and present). In addition, the PW label is used to 230 identify an Out-NSP function associated with one or more attachment 231 circuit(s) that is/are the outgoing interface(s) to the customer. 232 The packet is handed to the Out-NSP function which will complete 233 processing and hand the packet to the egress attachment circuit. 235 The Out-NSP function has the responsibility for processing the 236 packet in order to prepare it for the egress attachment circuit. 237 This would involve, e.g., the insertion, deletion or replacement of 238 different Ethernet tags or other Ethernet encapsulation so that it 239 can accommodate different types of ACs, for example port, tagged 240 with one VLAN, tagged with multiple VLANs (QinQ [802.1ad]) or PBB I- 241 tags. 243 There are a number of functions that are out of the scope of this 244 specification. The primary reason they are out of scope is that 245 they are implementation dependent, and do not relate to the standard 246 definition of the Generalized Ethernet Pseudowire (GE-PW). For 247 example, whether the incoming attachment circuit has a pointer to 248 the In-NSP function or an index into a table, or how the pseudowire 249 is identified within the forwarding engine are not material to the 250 definition of the GE-PW. The definition of what the NSP function has 251 to perform is also a matter of local configuration. 253 4. Control Plane 255 All the PW Setup and Maintenance procedures described in [RFC4447] 256 apply to the GE-PW. There is no need for a new PW type. The Ethernet 257 type (0x0005) may be used [IANA PWE3] as the new GE-PW procedures 258 are backwards compatible with an existing implementation using 259 Ethernet type PW - see section 6. The function of an Ethernet tagged 260 PW can be also emulated in the NSPs with a GE-PW. 262 There might be some network scenarios where the required NSP 263 capabilities need to be signaled between PEs. This might be the case 264 for certain implementations that need to know what kind of NSP they 265 need to instantiate for certain PW. Also in some scenarios the 266 Service Providers might need to make sure the capabilities of the 267 related NSPs match. 269 An optional NSP capabilities sub-TLV for the Interface Parameters 270 TLV [RFC4447] is defined to allow the signaling of NSP capabilities 271 between Layer 2 PEs. 273 The NSP Capabilities sub-TLV is included in the related LDP messages 274 for PW setup and maintenance if the transmitting PE needs to verify 275 that the remote NSP is capable of performing certain functionality. 276 On reception of the NSP Capabilities sub-TLV a Layer 2 PE MUST 277 reject the PW Setup if it does not support or if the related NSP is 278 not properly configured to support any of the required NSP 279 capabilities. If the Layer 2 PE does not understand the NSP 280 Capabilities sub-TLV, it should continue the processing of the 281 interface parameters while silently discarding the unknown interface 282 parameter as per [RFC4447] section 5.5. 284 The format of the NSP sub-TLV follows the standard format defined 285 for all Interface Parameter sub-TLVs [RFC4447]: 287 0 1 2 3 288 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Sub-TLV Type | Sub-TLV Length | Capability 1 | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Capability 1 (cont) | 293 | " | 294 | Capability n | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 The type for NSP Capabilities sub-TLV is to be assigned by IANA 298 (0x0D to be confirmed). The following field defines the value length 299 in octets. Next is one or a list of NSP capabilities. 300 Each Capability is coded as 1 byte code point followed by an 1 byte 301 length field (length of the capability parameters in octets)whereas 302 the rest of the value field is used to indicate parameters specific 303 to the required capability ID. 305 The following code points are defined in this document: 306 - 001, Service delimiting VLAN tag required; length = 2 octets, 307 value identifies the (tag) Ethernet type (e.g. IEEE 802.1q, 308 802.1ad, 802.1ah) 309 - 002, Tag rewrite; length - 2 octets; value identifies the (tag) 310 Ethernet type, same as for the above 312 Addditional code points for the NSP Capabilities are to be added as 313 the applications are being defined. 315 5. The Control Word 317 The OPTIONAL control word specified in [RFC4385] MAY be used for the 318 GE-PW. 320 6. Backwards Compatibility with existing Ethernet PW implementations 322 The NSP of a GE-PW capable PE that needs to interoperate with older 323 implementations may be manually configured to fully emulate the 324 behavior of an existing Ethernet PW NSP as described in section 4.1 325 and 4.4 of [RFC4448]. 327 The NSP Capabilities sub-TLV may be also used to automatically 328 identify the old Ethernet PW implementation. The GE-PW capable PE 329 may use the received NSP Capabilities indication to identify the 330 regular (Ethernet or Ethernet VLAN) PW implementations. 331 The GE-PW capable PE MUST always include the NSP capability sub-TLV 332 in the PW setup message. If the PW signaling received from the 333 remote PE does not contain the NSP Capability sub-TLV, the local PE 334 switches to regular PW mode. If the other Layer 2 PE does not 335 understand the NSP Capabilities sub-TLV, it should continue the 336 processing of the interface parameters while silently discarding the 337 unknown interface parameter as per [RFC4447] section 5.5. 339 7. Emulating existing Ethernet Services 341 The rationale for redefining the two variants of the Ethernet 342 pseudowires is that the GE-PW is a more powerful construct that 343 subsumes both of them, prevents the future proliferation of other 344 Ethernet PW types and allows the definition of many more services 345 than are allowed by strictly following the existing pseudowire 346 definitions. 348 The following examples demonstrate that the right set of NSP and PW 349 functions yield not just the known VPWS, VPLS behaviors induced by 350 the two existing Ethernet pseudowires, but additional models used by 351 service providers, that are not strictly compliant to the existing 352 pseudowires. 354 7.1. GE-PW applicability to Ethernet PW 356 The GE-PW allows for emulation of an Ethernet point-to-point service 357 between different types of Ethernet Attachment Circuits by simply 358 emulating in the ingress NSP the required behavior. Specifically the 359 attachment circuits (ACs) may be defined at the PEs to represent the 360 whole port, one or more VLAN(s) (tagged, one service delimiting 361 VLAN) or a VLAN combination (QinQ/[802.1ad], tagged with two service 362 delimiting VLANs) and are mapped to the point-to-point NSP function 363 in each PE through local association. 365 As a result the packet arriving on the local AC is classified as 366 belonging to an ingress NSP who may be configured to 367 remove/rewrite/add one or more VLAN tags before forwarding the 368 packet to the GE-PW termination function that will encapsulate it 369 for transport over PSN core. 370 Similarly the egress NSP can manipulate encapsulation received over 371 GE-PW, adding, replacing or removing one or more tags of different 372 types as desired to accommodate different types of egress Ethernet 373 interfaces and AC definitions, for example port, tagged with one 374 VLAN, tagged with multiple VLANs (QinQ [802.1ad]). 376 A default behavior for the AC processing function of the NSPs 377 corresponding to the Ethernet PW type can be defined as follows: 378 - Assume one or more service delimiting tags are used by one of 379 the NSPs (NSP1) to identify the AC. The other NSP (NSP2) might 380 use a different set of service delimiting tags to identify the 381 AC. 383 - If a packet arrives at NSP1, the related in-NSP AC function 384 removes the service delimiting tags after AC identification 385 then performs the rest of the operations as described above. 386 - At the NSP2, the corresponding out-NSP AC function adds for 387 each AC the local service delimiting tags. 388 - This default behavior provides flexibility of supporting 389 interworking between any kind of ACs without one PE needing to 390 know what the remote PEs is using for AC identification. 392 7.2. GE-PW Applicability to Ethernet VLAN PW 394 Starting from the default behavior outlined in the previous section 395 for GE-PW, one can emulate the Ethernet VLAN mode by simply 396 configuring the in-NSP to insert a service delimiting VLAN tag 397 before sending the packet to the in-PW processing function. 398 Alternatively the need for service delimiting VLAN tag can be 399 indicated from the egress PE via the NSP capability TLV using code 400 point 001 as described in the Control Plane section. The type of tag 401 to be inserted (IEEE 802.1q, IEEE 802.1ad or proprietary) can be 402 specify in the parameter field of the capability. 404 7.3. GE-PW Applicability to VPWS and VPLS 406 The GE-PW can be used to serve the interconnect needs for the VPWS 407 and VPLS Forwarders. The previous section discussed how the GE-PW 408 can replace the existing Ethernet PW types from a point to point 409 forwarding perspective, handling also the VLAN tags on a per local 410 AC basis. 412 VPWS is really a collection of point-to-point virtual circuits, each 413 of them built as an individual PW context with full (in-NSP, in-PW, 414 out-PW, out NSP) functions. As demonstrated in the previous two 415 sections the GE-PW construct can emulate either of the existing 416 behaviors (Ethernet or Ethernet VLAN PWs) for each of the individual 417 virtual circuits, providing this way full support for any possible 418 VPWS combination supported by the existing PW types. 420 For VPLS the NSPs will have to replicate the same in-NSP AC, out-NSP 421 AC functions but for multiple ACs, handling also the Ethernet 422 switching functions (e.g. MAC switching, MAC Learning, Packet 423 Replication) as described in [RFC4664] and [RFC4762]. Translating 424 the default behavior for the Ethernet PW type that means each in-NSP 425 will remove the tags configured for AC identification and each out- 426 NSP will add the tags configured for AC identification providing 427 flexible support for any AC combination in the same VPLS. 429 7.4. GE-PW for point-to-point transport of PBB over Pseudowires 431 When a PW interconnects two PBB access networks (see Figure 1), 432 there may be a need to use the PBB ISID Tag (I-tag) [802.1ah] to 433 perform the mapping to/from ACs. The PBB I-tag can be processed as 434 an extended tag that may need to be changed at ingress / egress PE. 435 The related NSPs of a GE-PW can be configured to identify the I-tag 436 (using the Ethernet type assigned by [802.1ah]) and to change 437 different I-tag fields, for example the 24 bits ISID or the QoS 438 information as required. Alternatively the NSP capability code point 439 002 can be used to indicate the required rewrite of the I-tag fields 440 for an out-NSP that can not perform this sort of processing. The 441 parameter value of the code point 002 will specify the Ethernet type 442 for I-tag [802.1ah]. 444 The GE-PW (in-PW or out-PW) termination functions will not need to 445 change to accommodate this new type of service. The required PW 446 encapsulation described in the previous sections will be added 447 before the PBB Backbone MAC header. 449 For example assuming the PE depicted in Figure 1 [RFC4448] is 450 connected to a PBB network (PBBN) and the I-tag field is used to 451 defined the AC. 453 +------------------------------------------+ 454 | PE | 455 +---+ +-+ +-----+ +------+ +------+ +-+ 456 | | |P| | | |PW ter| | PSN | |P| 457 | |<==|h|<=| NSP |<=|minati|<=|Tunnel|<=|h|<== From PSN 458 | | |y| | | |on | | | |y| 459 | P | +-+ +-----+ +------+ +------+ +-+ 460 | B | | | 461 | B | +-+ +-----+ +------+ +------+ +-+ 462 | N | |P| | | |PW ter| | PSN | |P| 463 | |==>|h|=>| NSP |=>|minati|=>|Tunnel|=>|h|==> To PSN 464 | | |y| | | |on | | | |y| 465 +---+ +-+ +-----+ +------+ +------+ +-+ 466 | | 467 +------------------------------------------+ 469 Figure 1: PBB/PW 471 The ingress PE may be configured to check on the incoming PBB 472 packets the ISID value of the I-tag to determine the AC and 473 subsequently the ingress NSP. The ingress NSP may be configured to 474 change the values of different I-tag fields (for example the ISID, 475 PCP, DEI bits). 477 Next the GE-PW termination functions will handle the PW header that 478 will transport it throughout the PSN core and towards the egress 479 NSP. 481 The egress NSP may perform different functions depending on the type 482 of egress AC: e.g. 483 - if the access network is part of a different PBB service domain 484 it may re-write the I-tag field. 485 - if the access domain is a QinQ domain it may remove the PBB 486 header altogether assuming it supports this capability. 488 7.5. PBB-VPLS Applicability 490 The GE-PWs can be also applied to provide the interconnect between 491 PBB-VPLS entities as described in [PBB-VPLS]. On top of the I-tag 492 identification, processing functions described in the previous 493 section, the related NSPs can emulate the PBB components described 494 in [802.1ah], for example the Backbone (B) and Customer (I) 495 components. For example, in a PBB-VPLS PE, as the In-NSP function 496 receive the packet on the local AC, it may remove (default behavior) 497 the service tags configured locally for each AC identification. Then 498 it performs the Customer MAC switching and possibly the mapping to 499 the Backbone MAC address specific to the I-component [802.1ah]. 500 Subsequently the same In-NSP function will perform the Backbone MAC 501 switching function characteristic to the B-component [802.1ah]. If 502 the packet is to be transported over the PW infrastructure it will 503 be handled to the in-PW function as per [PBB-VPLS]. From now on the 504 processing steps described in the previous sections for various 505 types of PW behaviors apply. Same for the Out-PW termination 506 function in the other PE. The PW service label is used by the Out-PW 507 function to identify the Out-NSP to which the packet is handled. 508 There are two possibilities for the Out-NSP. 510 If the PE is the final termination point for PBB, the Out-NSP runs 511 both I and B components (PBB BEB node in [802.1ah]). It will handle 512 first the Ethernet switching functions for Backbone MAC header 513 followed by the switching functions for Customer MAC header. As the 514 packet is handled to the egress AC the regular AC processing 515 functions described in the previous sections apply. As a default 516 behavior the out-NSP will add the service tags configured locally 517 for AC identification. 519 If an HVPLS architecture is used the next PE in the chain may be 520 just an intermediate switching point for Backbone MAC header. The 521 related Out-NSP function runs just the PBB B-component (PBB BCB node 522 in [802.1ah]). It will handle just the Ethernet switching functions 523 for Backbone MAC header. The possible results may be switching the 524 packet back to another In-PW function for further forwarding towards 525 the PBB-VPLS PE (PBB BEB). 527 [PBB-VPLS] and [PBB-Interop] describe the requirements, 528 interoperability and solution in detail. 530 Other applications are possible and require just the definition of 531 the required NSP functions. 533 8. Management Model 535 There will be a new object to describe the NSP compatibility 536 capabilities [PW MIB]. 538 9. Acknowledgements 540 The authors gratefully acknowledge the contributions of Nabil Bitar, 541 and Dimitri Papadimitriou. 543 10. References 545 Normative References 547 [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and 548 G. Heron, "Pseudowire Setup and Maintenance Using the Label 549 Distribution Protocol (LDP)", RFC 4447, April 2006. 551 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 552 "Encapsulation Methods for Transport of Ethernet over MPLS 553 Networks", RFC 4448, April 2006. 555 [IANA PWE3] Martini, L., "IANA Allocations for Pseudowire Edge to 556 Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 558 [RFC4385] Bryant, S., Swallow, G., and D. McPherson, "Pseudowire 559 Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS 560 PSN", RFC 4385, February 2006. 562 [RFC4720] Malis, A., Allan, D.,and N. Del Regno, "Pseudowire 563 Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention", RFC 564 4720, November 2006 566 [802.1ad] IEEE 802.1ad-2005 "Virtual Bridged Local Area Networks, 567 Amendment 4: Provider Bridges", December 7, 2005 569 [802.1ah] IEEE Draft P802.1ah/D4.2 "Virtual Bridged Local Area 570 Networks, Amendment 6: Provider Backbone Bridges", Work in Progress, 571 March 26, 2008 572 [RFC4762] Lasserre, M. and Kompella, V. (Editors), "Virtual Private 573 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 574 Signaling", RFC 4762, January 2007. 576 [PW MIB] T. Nadeau, and D. Zelig "Pseudowire (PW) Management 577 Information Base (MIB)", draft-ietf-pwe3-pw-mib-14.txt, January 2008 578 ( work in progress ). 580 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 581 Requirement Levels", BCP 14, RFC 2119, March 1997. 583 Informative References 585 [RFC4664] Andersson, L. and Rosen, E. (Editors),"Framework for Layer 586 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006. 588 [PBB-VPLS] F. Balus, et Al. "VPLS Extensions for Provider Backbone 589 Bridging", draft-balus-l2vpn-vpls-802.1ah-03.txt, February 2008 ( 590 work in progress ). 592 [PBB-Interop] A. Sajassi, et Al. "VPLS Interoperability with 593 Provider Backbone Bridges", draft-sajassi-l2vpn-vpls-pbb-interop- 594 03.txt, November 2007 ( work in progress ). 596 11. Security Considerations 598 No new security issues arise out of the extensions proposed here. 600 12. IANA Considerations 602 A new IANA allocation is required to describe NSP compatibility 603 capabilities. 605 13. Authors' Addresses 607 Andrew Malis 608 Verizon 609 andrew.g.malis@verizon.com 611 Giles Heron 612 British Telecom 613 giles.heron@bt.com 615 Shane Amante 616 Level 3 617 shane@castlepoint.net 619 Vach Kompella 620 Alcatel-Lucent 621 vach.kompella@alcatel-lucent.com 623 Florin Balus 624 Alcatel-Lucent 625 florin.balus@alcatel-lucent.com 627 14. Full Copyright Statement 629 Copyright (C) The IETF Trust (2008). 631 This document is subject to the rights, licenses and restrictions 632 contained in BCP 78, and except as set forth therein, the authors 633 retain all their rights. 635 This document and the information contained herein are provided on 636 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 637 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 638 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 639 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 640 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 641 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 642 FOR A PARTICULAR PURPOSE. 644 15. Intellectual Property 646 The IETF takes no position regarding the validity or scope of any 647 Intellectual Property Rights or other rights that might be claimed 648 to pertain to the implementation or use of the technology described 649 in this document or the extent to which any license under such 650 rights might or might not be available; nor does it represent that 651 it has made any independent effort to identify any such rights. 652 Information on the procedures with respect to rights in RFC 653 documents can be found in BCP 78 and BCP 79. 655 Copies of IPR disclosures made to the IETF Secretariat and any 656 assurances of licenses to be made available, or the result of an 657 attempt made to obtain a general license or permission for the use 658 of such proprietary rights by implementers or users of this 659 specification can be obtained from the IETF on-line IPR repository 660 at http://www.ietf.org/ipr. 662 The IETF invites any interested party to bring to its attention any 663 copyrights, patents or patent applications, or other proprietary 664 rights that may cover technology that may be required to implement 665 this standard. Please address the information to the IETF at ietf- 666 ipr@ietf.org. 668 16. Acknowledgments 670 Funding for the RFC Editor function is provided by the IETF 671 Administrative Support Activity (IASA).