idnits 2.17.1 draft-ietf-pwe3-segmented-pw-05.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 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1456. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1427. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1434. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1440. 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 : ---------------------------------------------------------------------------- No issues found here. 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 2007) is 6123 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) ** Downref: Normative reference to an Informational RFC: RFC 3985 -- Possible downref: Non-RFC (?) normative reference: ref. 'VCCV' ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-10) exists of draft-ietf-pwe3-fragmentation-05 == Outdated reference: A later version (-07) exists of draft-ietf-l2tpext-l2vpn-00 -- Unexpected draft version: The latest known version of draft-mistretta-l2tp-infomsg is -01, but you're referring to -02. == Outdated reference: A later version (-04) exists of draft-ietf-l2tpext-pwe3-atm-00 == Outdated reference: A later version (-16) exists of draft-ietf-pwe3-oam-msg-map-02 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Luca Martini 3 Internet Draft Chris Metz 4 Expiration Date: January 2008 Thomas D. Nadeau 5 Intended status: Standards Track Cisco Systems Inc. 7 Matthew Bocci Mike Duckett 8 Florin Balus Bellsouth 9 Mustapha Aissaoui 10 Alcatel-Lucent 12 July 2007 14 Segmented Pseudo Wire 16 draft-ietf-pwe3-segmented-pw-05.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that other 27 groups may also distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Abstract 42 This document describes how to connect pseudo wires (PW) between two 43 distinct PW control planes or PSN domains. The PW control planes may 44 belong to independent autonomous systems, or the PSN technology is 45 heterogeneous, or a PW might need to be aggregated at a specific PSN 46 point. The PW packet data units are simply switched from one PW to 47 another without changing the PW payload. 49 Table of Contents 51 1 Specification of Requirements ........................ 4 52 2 Terminology .......................................... 4 53 3 Introduction ......................................... 5 54 4 General Description .................................. 7 55 5 PW Switching and Attachment Circuit Type ............. 10 56 6 Applicability ........................................ 10 57 7 PW-MPLS to PW-MPLS Control Plane Switching ........... 11 58 7.1 Static Control plane switching ....................... 11 59 7.2 Two LDP control planes using the same FEC type ....... 12 60 7.2.1 FEC 129 Active/Passive T-PE Election Procedure ....... 12 61 7.3 LDP FEC 128 to LDP using the generalized FEC 129 ..... 12 62 7.4 LDP PW switching point TLV ........................... 13 63 7.4.1 PW Switching Point Sub-TLVs .......................... 14 64 7.4.2 Adaptation of Interface Parameters ................... 15 65 7.5 Group ID ............................................. 16 66 7.6 PW Loop Detection .................................... 16 67 8 PW-MPLS to PW-L2TPv3 Control Plane Switching ......... 16 68 8.1 Static MPLS and L2TPv3 PWs ........................... 16 69 8.2 Static MPLS PW and Dynamic L2TPv3 PW ................. 17 70 8.3 Static L2TPv3 PW and Dynamic LDP/MPLS PW ............. 17 71 8.4 Dynamic LDP/MPLS and L2TPv3 PWs ...................... 17 72 8.4.1 Session Establishment ................................ 17 73 8.4.2 Adaptation of PW Status message ...................... 18 74 8.4.3 Session Tear Down .................................... 18 75 8.5 Adaptation of L2TPv3 AVPs to Interface Parameters .... 19 76 8.6 Switching Point TLV in L2TPv3 ........................ 20 77 8.7 L2TPv3 and MPLS PW Data Plane ........................ 20 78 8.7.1 PWE3 Payload Convergence and Sequencing .............. 20 79 8.7.2 Mapping .............................................. 21 80 9 Operation And Management ............................. 22 81 9.1 Extensions to VCCV to Support Switched PWs ........... 22 82 9.2 PW-MPLS to PW-MPLS OAM Data Plane Indication ......... 22 83 9.2.1 PW Label TTL Method .................................. 22 84 9.2.2 MH-VCCV CW Method .................................... 23 85 9.3 Signaling OAM Capabilities for Switched Pseudo Wires . 23 86 9.3.1 OAM Capability for MH PWs Demultiplexed using MPLS ... 24 87 9.3.2 OAM Capability for MH PWs Demultiplexed using L2TPv3 . 24 88 9.4 Detailed MH-VCCV Procedures .......................... 24 89 9.4.1 PW Label TTL Method .................................. 25 90 9.4.2 MH-VCCV CW Method .................................... 25 91 9.5 Tracing Switched PW Switch Points Using MH-VCCV ...... 26 92 9.6 Mapping Switched Pseudo Wire Status .................. 26 93 9.6.1 S-PE initiated PW status messages .................... 28 94 9.6.1.1 Local PW2 reverse direction fault .................... 29 95 9.6.1.2 Local PW1 reverse direction fault .................... 29 96 9.6.1.3 Local PW2 forward direction fault .................... 29 97 9.6.1.4 Local PW1 forward direction fault .................... 30 98 9.6.1.5 Clearing Faults ...................................... 30 99 9.6.2 PW status messages and S-PE TLV processing ........... 30 100 9.6.3 T-PE processing of PW status messages ................ 30 101 9.7 Pseudowire Status Negotiation Procedures ............. 31 102 9.8 Status Dampening ..................................... 31 103 10 Peering Between Autonomous Systems ................... 31 104 11 Security Considerations .............................. 31 105 11.1 Data Plane Security .................................. 31 106 11.2 Control Protocol Security ............................ 32 107 12 IANA Considerations .................................. 33 108 12.1 Channel Type ......................................... 33 109 12.2 L2TPv3 AVP ........................................... 33 110 12.3 LDP TLV TYPE ......................................... 33 111 12.4 LDP Status Codes ..................................... 33 112 12.5 L2TPv3 Result Codes .................................. 34 113 12.6 New IANA Registries .................................. 34 114 13 Intellectual Property Statement ...................... 34 115 14 Full Copyright Statement ............................. 35 116 15 Acknowledgments ...................................... 35 117 16 Normative References ................................. 35 118 17 Informative References ............................... 36 119 18 Author Information ................................... 37 121 1. Specification of Requirements 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 2. Terminology 129 - PW Terminating Provider Edge (T-PE). A PE where the customer- 130 facing attachment circuits (ACs) are bound to a PW forwarder. A 131 Terminating PE is present in the first and last segments of a 132 MS-PW. This incorporates the functionality of a PE as defined in 133 [RFC3985]. 135 - Single-Segment Pseudo Wire (SS-PW). A PW setup directly between 136 two T-PE devices. Each PW in one direction of a SS-PW traverses 137 one PSN tunnel that connects the two T-PEs. 139 - Multi-Segment Pseudo Wire (MS-PW). A static or dynamically 140 configured set of two or more contiguous PW segments that behave 141 and function as a single point-to-point PW. Each end of a MS-PW 142 by definition MUST terminate on a T-PE. 144 - PW Segment. A part of a single-segment or multi-segment PW, which 145 is set up between two PE devices, T-PEs and/or S-PEs. 147 - PW Switching Provider Edge (S-PE). A PE capable of switching the 148 control and data planes of the preceding and succeeding PW 149 segments in a MS-PW. The S-PE terminates the PSN tunnels of the 150 preceding and succeeding segments of the MS-PW. It is therefore a 152 - PW switching point for a MS-PW. A PW Switching Point is never the 153 S-PE and the T-PE for the same MS-PW. A PW switching point runs 154 necessary protocols to setup and manage PW segments with other PW 155 switching points and terminating PEs. 157 3. Introduction 159 PWE3 defines the signaling and encapsulation techniques for 160 establishing SS-PWs between a pair of ultimate PEs and in the vast 161 majority of cases this will be sufficient. MS-PWs come into play in 162 two general cases: 164 -i. When it is not possible, desirable or feasible to establish 165 a PW control channel between the ultimate source and 166 destination PEs. At a minimum PW control channel 167 establishment requires knowledge of and reachability to the 168 remote (ultimate) PE IP address. The local (ultimate) PE may 169 not have access to this information related to topology, 170 operational or security constraints. 172 An example is the inter-AS L2VPN scenario where the ultimate 173 PEs reside in different provider networks (ASes) and it is 174 the practice to MD5-key all control traffic exchanged 175 between two networks. Technically a SS-PW could be used but 176 this would require MD5-keying on ALL ultimate source and 177 destination PE nodes. An MS-PW allows the providers to 178 confine MD5 key administration to just the PW switching 179 points connecting the two domains. 181 A second example might involve a single AS where the PW 182 setup path between the ultimate PEs is computed by an 183 external entity (i.e. client-layer routing protocol). Assume 184 a full mesh of PWE3 control channels established between 185 PE-A, PE-B and PE-C. A client-layer L2 connection tunneled 186 through a PW is required between ultimate PE-A and PE-C. The 187 external entity computes a PW setup path that passes through 188 PE-B. This results in two discrete PW segments being built: 189 one between PE-A and PE-B and one between PE-B and PE-C. The 190 successful client-layer L2 connection between ultimate PE-A 191 and ultimate PE-C requires that PE-B performs the PWE3 192 switching process. 194 A third example involves the use of PWs in hierarchical 195 IP/MPLS networks. Access networks connected to a backbone 196 use PWs to transport customer payloads between customer 197 sites serviced by the same access network and up to the edge 198 of the backbone where they can be terminated or switched 199 onto a succeeding PW segment crossing the backbone. The use 200 of PWE3 switching between the access and backbone networks 201 can potentially reduce the PWE3 control channels and routing 202 information processed by the access network T-PEs. 204 It should be noted that PWE3 switching does not help in any 205 way to reduce the amount of PW state supported by each 206 access network T-PE. 208 -ii. PWE3 signaling and encapsulation protocols are different. 209 The ultimate PEs are connected to networks employing 210 different PW signaling and encapsulation protocols. In this 211 case it is not possible to use a SS-PW. A MS-PW with the 212 appropriate interworking performed at the PW switching 213 points can enable PW connectivity between the ultimate PEs 214 in this scenario. 216 There are four different signaling protocols that are defined to 217 signal PWs: 218 -i. Static configuration of the PW (MPLS or L2TPv3). 219 -ii. LDP using FEC 128 220 -iii. LDP using the generalized FEC 129 221 -iv. L2TPv3 223 4. General Description 225 A pseudo-wire (PW) is a tunnel established between two provider edge 226 (PE) nodes to transport L2 PDUs across a packet switched network 227 (PSN) as described in Figure 1 and in [PWE3-ARCH]. Many providers are 228 looking at PWs as a means of migrating existing (or building new) 229 L2VPN services (i.e. Frame-Relay, ATM, Ethernet) on top of a PSN by 230 using PWs. PWs may span multiple autonomous systems of the same or 231 different provider networks. In these scenarios PW control channels 232 (i.e. targeted LDP, L2TPv3) and PWs will cross AS boundaries. 234 Inter-AS L2VPN functionality is currently supported and several 235 techniques employing MPLS encapsulation and LDP signaling have been 236 documented [2547BIS]. It is also straightforward to support the same 237 inter-AS L2VPN functionality employing L2TPv3. In this document we 238 define methodology to switch a PW between two PW control planes. 240 |<-------------- Emulated Service ---------------->| 241 | | 242 | |<------- Pseudo Wire ------>| | 243 | | | | 244 | | |<-- PSN Tunnel -->| | | 245 | V V V V | 246 V AC +----+ +----+ AC V 247 +-----+ | | PE1|==================| PE2| | +-----+ 248 | |----------|............PW1.............|----------| | 249 | CE1 | | | | | | | | CE2 | 250 | |----------|............PW2.............|----------| | 251 +-----+ ^ | | |==================| | | ^ +-----+ 252 ^ | +----+ +----+ | | ^ 253 | | Provider Edge 1 Provider Edge 2 | | 254 | | | | 255 Customer | | Customer 256 Edge 1 | | Edge 2 257 | | 258 native service native service 260 Figure 1: PWE3 Reference Model 262 There are two methods for switching a PW between two PW control 263 planes. In the first method (Figure 2), the two control planes 264 terminate on different PEs. 266 |<------------Emulated Service---------->| 267 | PSN PSN | 268 AC | |<-1->| |<-2->| | AC 269 | V V V V V V | 270 | +----+ +-----+ +----+ +----+ | 271 +----+ | | |=====| | | |=====| | | +----+ 272 | |-------|......PW1.......|--AC1--|......PW2......|-------| | 273 | CE1| | | | | | | | | | | |CE2 | 274 | |-------|......PW3.......|--AC2--|......PW4......|-------| | 275 +----+ | | |=====| | | |=====| | | +----+ 276 ^ +----+ +-----+ +----+ +----+ ^ 277 | PE1 PE2 PE3 PE4 | 278 | ^ ^ | 279 | | | | 280 | PW stitching points | 281 | | 282 | | 283 |<-------------------- Emulated Service ---------------->| 285 Figure 2: PW Switching using ACs Reference Model 287 In Figure 2, pseudo wires in two separate PSNs are stitched together 288 using native service attachment circuits. PE2 and PE3 only run the 289 control plane for the PSN to which they are directly attached. At PE2 290 and PE3, PW1 and PW2 are connected using attachment circuit AC1, 291 while PW3 and PW4 are connected using attachment circuit AC2. 293 Native |<-----------Pseudo Wire----------->| Native 294 Layer2 | | Layer2 295 Service | |<-PSN1-->| |<--PSN2->| | Service 296 (AC) V V V V V V (AC) 297 | +----+ +-----+ +----+ | 298 +----+ | | PE1|=========| PE2 |=========| PE3| | +----+ 299 | |----------|........PW1.........|...PW3........|----------| | 300 | CE1| | | | | | | | | |CE2 | 301 | |----------|........PW2.........|...PW4........|----------| | 302 +----+ | | |=========| |=========| | | +----+ 303 ^ +----+ +-----+ +----+ | ^ 304 | Provider Edge 1 ^ Provider Edge 3 | 305 | (Ultimate PE) | (Ultimate PE) | 306 | | | 307 | PW switching point | 308 | (Optional PW adaptation function) | 309 | | 310 |<------------------- Emulated Service ------------------>| 312 Figure 3: PW Control Plane Switching Reference Model 314 In Figure 3 PE2 runs two separate control planes: one toward PE1, and 315 one Toward PE3. The PW switching point is at PE2 which is configured 316 to connect PW1 and PW3 together to complete the multi-hop PW between 317 PE1 and PE3. PW1 and PW3 MUST be of the same PW type, but PSN1 and 318 PSN2 need not be the same technology. In the latter case, if the PW 319 is switched to a different technology, the PEs must adapt the PDU 320 encapsulation between the different PSN technologies. In the case 321 where PSN1 and PSN2 are the same technology the PW PDU does not need 322 to be modified, and PDUs are then switched between the pseudo-wires 323 at the PW label level. 325 It should be noted that it is possible to adapt one PSN technology to 326 a different one, for example MPLS over an IP or GRE [RFC4023] 327 encapsulation, but this is outside the scope of this document. 328 Further, one could perform an interworking function on the PWs 329 themselves at the PW switching point, allowing conversion from one PW 330 type to another, but this is also outside the scope of this document. 332 This document describes procedures for building multi-segment 333 pseudowires using manual configuration of the switching point PE2. 334 Other documents may build on this base specification to automate the 335 configuration and selection of PE2. It should also be noted that a PW 336 can traverse multiple PW switching points along it's path, and the 337 edge PEs will not require any specific knowledge of how many PW 338 switching points the PW has traversed (though this may be reported 339 for troubleshooting purposes). 341 In general the approach taken is to connect the individual control 342 planes by passing along any signaling information immediately upon 343 reception. First the PW switching point is configured to switch a 344 SS-PW from a specific peer to another SS-PW destined for a different 345 peer. No control messages are exchanged yet as the PW switching point 346 PE does not have enough information to actually initiate the PW setup 347 messages. However, if a session does not already exist, a control 348 protocol (LDP/L2TP) session is setup. In this model the MS-PW setup 349 is starting from the T-PE devices. Next once the T-PE is configured 350 it sends the PW control setup messages. These messages are received, 351 and immediately used to form the PW setup messages for the next SS-PW 352 of the MS-PW. If one of the Switching PEs doesn't accept an LDP Label 353 Mapping message then a Label Release message is sent back to the 354 originator T-PE. A MS-PW is declared UP when all the constituent SS- 355 PWs are UP. 357 5. PW Switching and Attachment Circuit Type 359 The PWs in each PSN are established independently, with each PSN 360 being treated as a separate PWE3 domain. For example, in Figure 2 for 361 case of MPLS PSNs, PW1 is setup between PE1 and PE2 using the LDP 362 targeted session as described in [RFC4447], and at the same time a 363 separate pseudo wire, PW2, is setup between PE3 and PE4. The ACs for 364 PW1 and PW2 at PE2 and PE3 MUST be configured such that they are the 365 same PW type e.g. ATM VCC, Ethernet VLAN, etc. 367 6. Applicability 369 When using a PSN to transport a PW, the performance of the PW is 370 equal to the performance of the PSN plus any impairments introduced 371 by the PW layer itself. Therefore it is not possible for the PW to 372 provide better performance than the PSN over which it is transported. 374 Therefore, it is necessary to carefully consider the order in which 375 different layer networks are stacked upon each other within a 376 'network stack' in order to provide the topmost service with the 377 performance that it requires. This performance inheritance within a 378 PW/PSN relationship is vertical because the PW is vertically stacked 379 upon its PSN. 381 Note: Due to this vertical performance inheritance and the different 382 performance provided by, and the characteristics of, each networking 383 mode it is generally advisable to stack modes that less efficiently 384 provide dedicated bandwidth/performance on top of modes that more 385 efficiently provide dedicated bandwidth/performance. 387 When performing peer partition interworking the PW inherits the 388 performance of the PSN partition that provides the worst performance 389 of all the peered PSN partitions over which the PW is transported. 390 Therefore it is not possible for the PW to receive (or provide) 391 better performance than the worst performing of the peered PSN 392 partitions over which it is transported. 394 Therefore, it is necessary to carefully consider which PSN modes 395 (and/or technologies) it is appropriate to peer with one another in 396 order to provide the service with the performance that it requires. 397 This is a horizontal performance relationship because the server 398 layer partitions are peered with each other horizontally. 400 7. PW-MPLS to PW-MPLS Control Plane Switching 402 Referencing Figure 3, PE2 sets up a PW1 using the LDP targeted 403 session as described in [RFC4447], at the same time a separate pseudo 404 wire PW3 is setup to PE3. Each PW is configured independently on the 405 PEs, but on PE2 pseudo wire PW1 is connected to pseudo wire PW3. PDUs 406 are then switched between the pseudo-wires at the PW label level. 407 Hence the data plane does not need any special knowledge of the 408 specific pseudo wire type. A simple standard MPLS label swap 409 operation is sufficient to connect the two PWs, and in this case the 410 PW adaptation function is not used. 412 This process can be repeated as many times as necessary, the only 413 limitation to the number of PW switching points traversed is imposed 414 by the TTL field of the PW MPLS Label. The setting of the TTL is a 415 matter of local policy on the originating PE, but SHOULD be set to 416 255. 418 There are three MPLS to MPLS PW control planes: 419 -i. Static configuration of the PW. 420 -ii. LDP using FEC 128 421 -iii. LDP using the generalized FEC 129 422 This results in four distinct PW switching situations that are 423 significantly different, and must be considered in detail: 424 -i. PW Switching between two static control planes. 425 -ii. Static Control plane switching to LDP dynamic control plane. 426 -iii. Two LDP control planes using the same FEC type 427 -iv. LDP using FEC 128, to LDP using the generalized FEC 129 429 7.1. Static Control plane switching 431 In the case of two static control planes the PW switching point MUST 432 be configured to direct the MPLS packets from one PW into the other. 433 There is no control protocol involved in this case. When one of the 434 control planes is a simple static PW configuration and the other 435 control plane is a dynamic LDP FEC 128 or generalized PW FEC, then 436 the static control plane should be considered identical to an 437 attachment circuit (AC) in the reference model of Figure 1. The 438 switching point PE SHOULD signal the proper PW status if it detects a 439 failure in sending or receiving packets over the static PW. Because 440 the PW is statically configured, the status communicated to the 441 dynamic LDP PW will be limited to local interface failures. In this 442 case, the PW switching point PE behaves in a very similar manner to a 443 T-PE, assuming an active role. This means that the S-PE will 444 immediately send the LDP Label Mapping message if the static PW is 445 deemed to be UP. 447 7.2. Two LDP control planes using the same FEC type 449 As stated in a section above, the PW switching point PE should assume 450 an initial passive role. This means that once independent PWs are 451 configured on the switching point, the LSR does not advertise the LDP 452 PW FEC mapping until it has received at least one of the two PW LDP 453 FECs from a remote PE. This is necessary because the switching point 454 LSR does not know a priori what the interface parameter field in the 455 initial FEC advertisement will contain. 457 The PWID is a unique number between each pair of PEs. Hence Each SS- 458 PW that forms an MS-PW may have a different PWID. In the case of The 459 Generalized PW FEC, the AGI/SAI/TAI may have to also be different for 460 some, or sometimes all, SS-PWs. 462 7.2.1. FEC 129 Active/Passive T-PE Election Procedure 464 When a MS-PW is signaled using FEC 129, each T-PE might independently 465 start signaling the MS-PW. If the MS-PW path is not statically 466 configured, in certain cases the signaling procedure could result in 467 an attempt to setup each direction of the MS-PW through different 468 paths. To avoid this situation one of the T-PE MUST start the PW 469 signaling (active role), while the other waits to receive the LDP 470 label mapping before sending the respective PW LDP label mapping 471 message. (passive role). When the MS-PW path not statically 472 configured, the Active T-PE (the ST-PE) and the passive T-PE (the 473 TT-PE) MUST be identified before signaling is initiated for a given 474 MS-PW. 476 The determination of which T-PE assume the active role SHOULD be done 477 as follows: 479 the SAII and TAII are compared as unsigned integers, if the SAII is 480 bigger then the T-PE assumes the active role. 482 The selection process to determine which T-PE assumes the active role 483 MAY be superseded by manual provisioning. 485 7.3. LDP FEC 128 to LDP using the generalized FEC 129 487 When a PE is using the generalized FEC 129, there are two distinct 488 roles that a PE can assume: active and passive. A PE that assumes the 489 active role will send the LDP PW setup message, while a passive role 490 PE will simply reply to an incoming LDP PW setup message. The PW 491 switching point PE, will always remain passive until a PWID FEC 128 492 LDP message is received, which will cause the corresponding 493 generalized PW FEC LDP message to be formed and sent. If a 494 generalized FEC PW LDP message is received while the switching point 495 PE is in a passive role, the corresponding PW FEC 128 LDP message 496 will be formed and sent. 498 PW IDs need to be mapped to the corresponding AGI/TAI/SAI and vice 499 versa. This can be accomplished by local PW switching point 500 configuration, or by some other means, such as some form of auto 501 discovery. Such other means are outside the scope of this document. 503 7.4. LDP PW switching point TLV 505 The edge to edge PW might traverse several switching points, in 506 separate administrative domains. For management and troubleshooting 507 reasons it is useful to record information about the switching points 508 that the PW traverses. This is accomplished by using a PW switching 509 point TLV. 511 Note that sending the PW switching point TLV is OPTIONAL, however the 512 PE or SPE MUST process the TLV upon reception. The PW switching point 513 TLV is appended to the PW FEC at each switching point and is encoded 514 as follows: 516 0 1 2 3 517 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 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 |1|0| PW sw TLV (0x096D) | PW sw TLV Length | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Type | Length | Variable Length Value | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Variable Length Value | 524 | " | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 [note] LDP TLV type is pending IANA approval. 529 - PW sw TLV Length 531 Specifies the total length of all the following PW switching 532 point TLV fields in octets 534 - Type 536 Encodes how the Value field is to be interpreted. 538 - Length 540 Specifies the length of the Value field in octets. 542 - Value 544 Octet string of Length octets that encodes information to be 545 interpreted as specified by the Type field. 547 PW Switching point TLV Types are assigned by IANA according the the 548 process defined in the "IANA Allocations" section below. 550 The PW switching Point TLV is an OPTIONAL TLV that can appear once 551 for each switching point traversed. 553 7.4.1. PW Switching Point Sub-TLVs 555 Below are details specific to PW Switching Point Sub-TLVs described 556 in this document: 558 - PW ID of last PW segment traversed. 560 This sub-TLV type contains a PW ID in the format of the PWID 561 described in [RFC4447] 563 - PW Switching Point description string. 565 An optional description string of text up to 80 characters long. 567 - IP address of PW Switching Point. 569 The IP V4 or V6 address of the PW Switching Point. This is an 570 OPTIONAL Sub-TLV. 571 - MH VCCV Capability Indication. 573 - The FEC of last PW segment traversed. 575 The Attachment Identifier of the last PW segment traversed. This 576 is coded in the following format: 578 0 1 2 3 579 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 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | AGI Type | Length | Value | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 ~ AGI Value (contd.) ~ 584 | | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | AII Type | Length | Value | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 ~ SAII Value (contd.) ~ 589 | | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | AII Type | Length | Value | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 ~ TAII Value (contd.) ~ 594 | | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 - L2 PW address of PW Switching Point (recommended format) 599 This sub-TLV type contains a L2 PW address of PW Switching Point in 600 the format described in [PW-ADDR]. This includes the AII type field , 601 and length, as well as the L2 PW address without the AC ID portion 602 (if applicable). 604 7.4.2. Adaptation of Interface Parameters 606 [RFC4447] defines several interface parameters, which are used by the 607 Network Service Processing (NSP) to adapt the PW to the Attachment 608 Circuit (AC). The interface parameters are only used at the end 609 points, and MUST be passed unchanged across the PW switching point. 610 However the following interface parameters MAY be modified as 611 follows: 613 - 0x03 Optional Interface Description string This Interface 614 parameter MAY be modified, or altogether removed from the FEC 615 element depending on local configuration policies. 617 - 0x09 Fragmentation indicator This parameter MAY be inserted in 618 the FEC by the switching point if it is capable of re-assembly of 619 fragmented PW frames according to [PWE3-FRAG]. 621 - 0x0C VCCV parameter The switching point MAY not be able to 622 inspect the VCCV control channel. If the new MH-VCCV sub-TLV is 623 present, the VCCV parameter MUST be ignored in order to avoid 624 conflicts with the new TLV. 626 7.5. Group ID 628 The Group ID (GR ID) is used to reduce the number of status messages 629 that need to be sent by the PE advertising the PW FEC. The GR ID has 630 local significance only, and therefore MUST be mapped to a unique GR 631 ID allocated by the PW switching point PE. 633 7.6. PW Loop Detection 635 A switching point PE SHOULD check the OPTIONAL PW switching Point 636 TLV, to verify if it's own IP address appears in it. If it's IP 637 address appears in a received PW switching Point TLV, the PE SHOULD 638 break the loop, and send a label release message with the following 639 error code: 640 Assignment E Description 641 0x0000003A 0 "PW Loop Detected" 643 [ note: error code pending IANA allocation ] 645 8. PW-MPLS to PW-L2TPv3 Control Plane Switching 647 Both MPLS and L2TPv3 PWs may be static or dynamic. This results in 648 four possibilities when switching between L2TPv3 and MPLS. 650 -i. Switching between MPLS and L2TPv3 static control planes. 651 -ii. Switching between a static MPLS PW and a dynamic L2TPv3 PW. 652 -iii. Switching between a static L2TPv3 PW and a dynamic MPLS PW. 653 -iv. Switching between a dynamic MPLS PW and a dynamic L2TPv3 PW. 655 8.1. Static MPLS and L2TPv3 PWs 657 In the case of two static control planes, the PW switching point MUST 658 be configured to direct packets from one PW into the other. There is 659 no control protocol involved in this case. The configuration MUST 660 include which MPLS VC Label maps to which L2TPv3 Session ID (and 661 associated Cookie, if present) as well as which MPLS Tunnel Label 662 maps to which PE destination IP address. 664 8.2. Static MPLS PW and Dynamic L2TPv3 PW 666 When a statically configured MPLS PW is switched to a dynamic L2TPv3 667 PW, the static control plane should be considered identical to an 668 attachment circuit (AC) in the reference model of Figure 1. The 669 switching point PE SHOULD signal the proper PW status if it detects a 670 failure in 672 sending or receiving packets over the static PW. Because the PW is 673 statically configured, the status communicated to the dynamic L2TPv3 674 PW will be limited to local interface failures. In this case, the PW 675 switching point PE behaves in a very similar manner to a T-PE, 676 assuming an active role. 678 8.3. Static L2TPv3 PW and Dynamic LDP/MPLS PW 680 When a statically configured L2TPv3 PW is switched to a dynamic 681 LDP/MPLS PW, then the static control plane should be considered 682 identical to an attachment circuit (AC) in the reference model of 683 Figure 1. The switching point PE SHOULD signal the proper PW status 684 (via an L2TPv3 SLI message) if it detects a failure in sending or 685 receiving packets over the static PW. Because the PW is statically 686 configured, the status communicated to the dynamic LDP/MPLS PW will 687 be limited to local interface failures. In this case, the PW 688 switching point PE behaves in a very similar manner to a T-PE, 689 assuming an active role. 691 8.4. Dynamic LDP/MPLS and L2TPv3 PWs 693 When switching between dynamic PWs, the switching point always 694 assumes an initial passive role. Thus, it does not initiate an 695 LDP/MPLS or L2TPv3 PW until it has received a connection request 696 (Label Mapping or ICRQ) from one side of the node. Note that while 697 MPLS PWs are made up of two unidirectional LSPs bonded together by 698 FEC identifiers, L2TPv3 PWs are bidirectional in nature, setup via a 699 3-message exchange (ICRQ, ICRP and ICCN). Details of Session 700 Establishment, Tear Down, and PW Status signaling are detailed below. 702 8.4.1. Session Establishment 704 When the PW switching point receives an L2TPv3 ICRQ message, the 705 identifying AVPs included in the message are mapped to FEC 706 identifiers and sent in an LDP label mapping message. Conversely, if 707 an LDP Label Mapping message is received, it is either mapped to an 708 ICRP message or causes an L2TPv3 session to be initiated by sending 709 an ICRQ. 711 Following are two example exchanges of messages between LDP and 712 L2TPv3. The first is a case where an L2TPv3 T-PE initiates an MS-PW, 713 the second is a case where an MPLS T-PE initiates an MS-PW. 715 PE 1 (L2TPv3) PW Switching Node PE3 (MPLS/LDP) 717 AC "Up" 718 L2TPv3 ICRQ ---> 719 LDP Label Mapping ---> 720 AC "UP" 721 <--- LDP Label Mapping 722 <--- L2TPv3 ICRP 723 L2TPv3 ICCN ---> 724 <-------------------- MH PW Established ------------------> 726 PE 1 (MPLS/LDP) PW Switching Node PE3 (L2TPv3) 728 AC "Up" 729 LDP Label Mapping ---> 730 L2TPv3 ICRQ ---> 731 <--- L2TPv3 ICRP 732 <--- LDP Label Mapping 733 L2TPv3 ICCN ---> 734 AC "Up" 735 <-------------------- MH PW Established ------------------> 737 8.4.2. Adaptation of PW Status message 739 L2TPv3 uses the SLI message to indicate a interface status change 740 (such as the interface transitioning from "Up" or "Down"). MPLS/LDP 741 PWs either signal this via an LDP Label Withdraw or the PW Status 742 Notification message defined in section 4.4 of [RFC4447]. 744 8.4.3. Session Tear Down 746 L2TPv3 uses a single message, CDN, to tear down a pseudowire. The CDN 747 message translates to a Label Withdraw message in LDP. Following are 748 two example exchanges of messages between LDP and L2TPv3. The first 749 is a case where an L2TPv3 T-PE initiates the termination of an MS-PW, 750 the second is a case where an MPLS T-PE initiates the termination of 751 an MS-PW. 753 PE 1 (L2TPv3) PW Switching Node PE3 (MPLS/LDP) 755 AC "Down" 756 L2TPv3 CDN ---> 757 LDP Label Withdraw ---> 758 AC "Down" 759 <-- LDP Label Release 761 <--------------- MH PW Data Path Down ------------------> 763 PE 1 (MPLS LDP) PW Switching Node PE3 (L2TPv3) 765 AC "Down" 766 LDP Label Withdraw ---> 767 L2TPv3 CDN --> 768 <-- LDP Label Release 769 AC "Down" 771 <---------------- MH PW Data Path Down ------------------> 773 8.5. Adaptation of L2TPv3 AVPs to Interface Parameters 775 [RFC4447] defines several interface parameters which MUST be mapped 776 to the equivalent AVPs in L2TPv3 setup messages. 778 * Interface MTU 780 The Interface MTU parameter is mapped directly to the L2TP 781 Interface MTU AVP defined in [L2TP-L2VPN] 783 * Max Number of Concatenated ATM cells 785 This interface parameter is mapped directly to the L2TP "ATM 786 Maximum Concatenated Cells AVP" described in section 6 of [L2TP- 787 ATM]. 789 * Optional Interface Description String 791 This string may be carried as the "Call-Information AVP" 792 described in section 2.2 of [L2TP-INFOMSG] 794 * PW Type 796 The PW Type defined in [RFC4446] is mapped to the L2TPv3 "PW 797 Type" AVP defined in [L2TPv3]. 799 * PW ID (FEC 128) 801 For FEC 128, the PW ID is mapped directly to the L2TPv3 "Remote 802 End ID" AVP defined in [L2TPv3]. 804 * Generalized FEC 129 SAI/TAI 806 Section 4.3 of [L2TP-L2VPN] defines how to encode the SAI and TAI 807 parameters. These can be mapped directly. 809 Other interface parameter mappings will either be defined in a future 810 version of this document, or are unsupported when switching between 811 LDP/MPLS and L2TPv3 PWs. 813 8.6. Switching Point TLV in L2TPv3 815 When translating between LDP and L2TPv3 control messages, the PW 816 Switching Point TLV described earlier in this document is carried in 817 a single variable length L2TP AVP present in the ICRQ, ICRP messages, 818 and optionally in the ICCN message. 820 The L2TP "Switching Point AVP" is Attribute Type TBA-L2TP-AVP-1. The 821 AVP MAY be hidden (the L2TP AVP H-bit may be 0 or 1), the length of 822 the AVP is 6 plus the length of the series of Switching Point sub- 823 TLVs included in the AVP, and the AVP MUST NOT be marked Mandatory 824 (the L2TP AVP M-bit MUST be 0). 826 8.7. L2TPv3 and MPLS PW Data Plane 828 When switching between an MPLS and L2TP PW, packets are sent in their 829 entirety from one PW to the other, replacing the MPLS label stack 830 with the L2TPv3 and IP header or vice versa. There are some 831 situations where an additional amount of interworking must be 832 provided between the two data planes at the PW switching node. 834 8.7.1. PWE3 Payload Convergence and Sequencing 836 Section 5.4 of [PWE3-ARCH] discusses the purpose of the various shim 837 headers necessary for enabling a pseudowire over an IP or MPLS PSN. 838 For L2TPv3, the Payload Convergence and Sequencing function is 839 carried out via the Default L2-Specific Sublayer defined in [L2TPv3]. 840 For MPLS, these two functions (together with PSN Convergence) are 841 carried out via the MPLS Control Word. Since these functions are 842 different between MPLS and L2TPv3, interworking between the two may 843 be necessary. 845 The L2TP L2-Specific Sublayer and MPLS Control Word are shim headers 846 which in some cases are not necessary to be present at all. For 847 example, an Ethernet PW with sequencing disabled will generally not 848 require an MPLS Control Word or L2TP Default L2-Specific Sublayer to 849 be present at all. In this case, Ethernet frames are simply sent from 850 one PW to the other without any modification beyond the MPLS and 851 L2TP/IP encapsulation and decapsulation. 853 The following section offers guidelines for how to interwork between 854 L2TP and MPLS for those cases where the Payload Convergence, 855 Sequencing, or PSN Convergence functions are necessary on one or both 856 sides of the switching node. 858 8.7.2. Mapping 860 The MPLS Control Word consists of (from left to right): 862 -i. These bits are always zero in MPLS are not necessary to be 863 mapped to L2TP. 865 -ii. These six bits may be used for Payload Convergence depending 866 on the PW type. For ATM, the first four of these bits are 867 defined in [PWE3-ATM]. These map directly to the bits 868 defined in [L2TP-ATM]. For Frame Relay, these bits indicate 869 how to set the bits in the Frame Relay header which must be 870 regenerated for L2TP as it carries the Frame Relay header 871 intact. 873 -iii. L2TP determines its payload length from IP. Thus, this 874 Length field need not be carried directly to L2TP. This 875 Length field will have to be calculated and inserted for 876 MPLS when necessary. 878 -iv. The Default L2-Specific Sublayer has a sequence number with 879 different semantics than that of the MPLS Control Word. This 880 difference eliminates the possibility of supporting 881 sequencing across the MS-PW by simply carrying the sequence 882 number through the switching point transparently. As such, 883 sequence numbers MAY be supported by checking the sequence 884 numbers of packets arriving at the switching point and 885 regenerating a new sequence number in the proper format for 886 the PW on egress. If this type of sequence interworking at 887 the switching node is not supported, and a T-PE requests 888 sequencing of all packets via the L2TP control channel 889 during session setup, the switching node SHOULD NOT allow 890 the session to be established by sending a CDN message with 891 Result Code set to 17 "sequencing not supported" (subject to 892 IANA Assignment). 894 9. Operation And Management 896 9.1. Extensions to VCCV to Support Switched PWs 898 Single-hop pseudowires are signaled using the VCCV parameter included 899 in the interface parameter field of the PW ID FEC TLV or the sub-TLV 900 interface parameter of the Generalized PW ID FEC TLV as described in 901 [VCCV]. When a switching point exist between PE nodes, it is 902 required to be able to continue operating VCCV end-to-end across a 903 switching point and to provide the ability to trace the path of the 904 MS-PW over any number of segments. 906 This document provides a couple of methods for achieving these two 907 objectives. The first method is based on re-using the existing VCCV 908 CW and decrementing the TTL of the PW label at each hop in the path 909 of the MS-PW. This method is suitable to deployments where T-PE 910 nodes continue to use the SS-PW control word and where S-PE nodes are 911 capable of decrementing the TTL field for all PW packets without 912 overwriting it. The second method is based on using a new MH-VCCV 913 control word and decrementing the TTL field in the control word. This 914 method is suitable to deployments where S-PE nodes cannot rely the 915 TTL in the PW label to identify if a VCCV packet is destined to this 916 node or not. 918 9.2. PW-MPLS to PW-MPLS OAM Data Plane Indication 920 9.2.1. PW Label TTL Method 922 This method reuses the SS-PW control word as described in [VCCV]. 923 VCCV control packets are indicated using the following CW in the 924 packet header: 926 0 1 2 3 927 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 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 |0 0 0 1|Version| Reserved = 0 | Channel Type = 0x21 | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 9.2.2. MH-VCCV CW Method 934 The VCCV control packets are indicated using a new Multi-hop 935 pseudowire CW in the packets header: 937 0 1 2 3 938 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 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 |0 0 0 1| 0x00 | Reserved = 0 | Channel Type = TBD | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | MH-TTL | MH-VCCV sub-TLV | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 9.3. Signaling OAM Capabilities for Switched Pseudo Wires 947 Like in SS-PW, MS-PW VCCV capabilities are signaled using the VCCV 948 parameter included in the interface parameter field of the PW ID FEC 949 TLV or the sub-TLV interface parameter of the Generalized PW ID FEC 950 TLV as described in [VCCV]. The new MH-VCCV CW is indicated using a 951 new CC type in the VCCV capability parameter field. 953 In Figure 1 T-PE1 uses the VCCV parameter included in the interface 954 parameter field of the PW ID FEC TLV or the sub-TLV interface 955 parameter of the Generalized PW ID FEC TLV to indicate to the far end 956 T-PE2 what VCCV capabilities T-PE1 supports. This is the same VCCV 957 parameter as would be used if T-PE1 and T-PE2 were connected directly 958 by T-LDP. S-PE2, which is a PW switching point, as part of the 959 adaptation function for interface parameters, processes locally the 960 VCCV parameter then passes it to T-PE2. If there were multiple S-PEs 961 on the path between T-PE1 and T-PE2, each would carry out the same 962 processing, passing along the VCCV parameter. The local processing of 963 the VCCV parameter removes CC Types specified by the originating T- 964 PE, except PWE3 Control Word and the new MH-VCCV Control Word that 965 are passed unchanged. For example, if T-PE1 indicates as supported CC 966 Types both Control Word and Router Alert then the S-PE removes the 967 Router Alert CC Type, leaving Control Word unchanged and then passes 968 the modified VCCV parameter to the next S-PE along the path. 970 The far end T-PE (T-PE2) receives the VCCV parameter indicating that 971 one or both Control Word CC types only if they are supported by the 972 initial T-PE (T-PE1) and all S-PEs along the PW path. If the VCCV 973 parameter indicates both the CW CC type and the new MH-VCCV CW CC 974 types are supported, then the T-PE1 is indicating it can receive both 975 types. If T-PE2 also supports both types, T-PE2 uses the CW CC type 976 in preference. 978 9.3.1. OAM Capability for MH PWs Demultiplexed using MPLS 980 The MH-VCCV parameter ID is defined as follows in [RFC4446]: 982 Parameter ID Length Description 983 0x0c 4 VCCV 985 The format of the VCCV parameter field is as follows: 987 0 1 2 3 988 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 0 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | 0x0c | 0x04 | CC Types | CV Types | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 0x01 Type 1: PWE3 control word with 0001b as first nibble 994 as defined in [RFC4385]. 995 0x02 Type 2: MPLS Router Alert Label. 996 0x04 Type 3: MPLS PW De-multiplexor Label TTL = 1 (Type 3). 997 0x08 Type 4: MH-VCCV Control Word 999 When using the PW label TTL method, the T-PE signals CC type 1. When 1000 using the MH-VCCV CW method, the T-PE signal CC type 4. 1002 9.3.2. OAM Capability for MH PWs Demultiplexed using L2TPv3 1004 TBD 1006 9.4. Detailed MH-VCCV Procedures 1008 In order to test the end-to-end connectivity of the multi-segment PW, 1009 a T-PE must include the FEC used in the last segment to the 1010 destination T-PE. This information is either configured at the 1011 sending T-PE or is obtained by processing the corresponding sub-TLV's 1012 of the PW switching point TLV. 1014 9.4.1. PW Label TTL Method 1016 In Figure 1, if T-PE1, S-PE and T-PE2 support Control Word for VCCV, 1017 then as described in Section 9.3 the control plane negotiates the 1018 common use of Control Word for VCCV end to end. 1020 At the S-PE the data path operations include an outer label pop, 1021 inner label swap and new outer label push. Note that there is no 1022 requirement for the S-PE to inspect the CW. 1024 Thus, the end-to-end connectivity of the multi-segment pseudowire can 1025 be verified by performing all of the following steps: 1027 -i. T-PE forms a VCCV-ping echo request message with the FEC 1028 matching that of the last segment PW to the destination T- 1029 PE. 1031 -ii. T-PE sets the inner PW label TTL to a large enough value to 1032 allow the packet to reach the far end T-PE. 1034 -iii. T-PE sends a VCCV packet that will follow the exact same 1035 data path at each S-PE as that taken by data packets. 1037 -iv. S-PE performs an outer label pop, an inner label swap with 1038 TTL decrement, and new outer label push. 1040 -v. There is no requirement for the S-PE to inspect the CW. 1042 -vi. The VCCV packet is diverted to VCCV control processing at 1043 the destination T-PE. 1045 -vii. Destination T-PE replies using the specified reply mode, 1046 i.e., reverse PW path or IP path. 1048 9.4.2. MH-VCCV CW Method 1050 TBD 1052 9.5. Tracing Switched PW Switch Points Using MH-VCCV 1054 Although the signaling of switched PWs includes functionality to 1055 record all switch points traversed by a particular switched 1056 pseudowire, this information is limited to the control plane. 1057 Specifically, this is the information which is then used to program 1058 the actual switching hardware. In an effort to provide explicit 1059 diagnostic capability of the data plane used by the switched 1060 pseudowire, it is necessary in some cases to compare the control and 1061 data planes used by a particular switched pseudowire. In these cases, 1062 it is possible to trace the pseudowire switch points by sending 1063 single-hop VCCV messages with TTL described above in the MH VCCV 1064 header, and increasing TTL values. This algorithm can be used to 1065 "walk" across the network of switching points until the ultimate PE 1066 is reached. 1068 Details of the operation for both methods will be provided in a 1069 future version of the document 1071 9.6. Mapping Switched Pseudo Wire Status 1073 In the PW switching with attachment circuits case (Figure 2), PW 1074 status messages indicating PW or attachment circuit faults SHOULD be 1075 mapped to fault indications or OAM messages on the connecting AC as 1076 defined in [PW-MSG-MAP]. If the AC connecting two PWs crosses an 1077 administrative boundary, then the manner in which those OAM messages 1078 are treated at the boundary is out of scope of this draft. 1080 In the PW control plane switching case (Figure 3), there is no 1081 attachment circuit at the PW switching point, but the two PWs are 1082 connected together. Similarly, the status of the PWs are forwarded 1083 unchanged from one PW to the other by the control plane switching 1084 function. However, it may sometimes be necessary to communicate 1085 status of one of the locally attached SS-PW at a PW switching point. 1086 For LDP this can be accomplished by sending an LDP notification 1087 message containing the PW status TLV, as well as an OPTIONAL PW 1088 switching point TLV as follows: 1090 0 1 2 3 1091 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 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 |0| Notification (0x0001) | Message Length | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | Message ID | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 |0|1| Status (0x0300) | Length | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 |0|1| Status Code=0x00000028 | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | Message ID=0 | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | Message Type=0 | PW Status TLV | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | PW Status TLV | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | PW Status TLV | PWId FEC | 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 | | 1110 | | 1111 | PWId FEC or Generalized ID FEC | 1112 | | 1113 | | 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 |1|0| PW sw TLV (0x096D) | PW sw TLV Length | 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | Type | Length | Variable Length Value | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 Only one PW switching point TLV can be present in this message. This 1121 message is then relayed by each PW switching point unchanged. The T- 1122 PE decodes the status message and the included PW switching point TLV 1123 to detect exactly where the fault occurred. At the T-PE if there is 1124 no PW switching point TLV included in the LDP status notification 1125 then the status message can be assumed to have originated at the 1126 remote T-PE. 1128 The merging of the received T-LDP status and the local status for the 1129 PW segments at an S-PE can be summarized as follows: 1131 -i. When the local status for both PW segments is UP, the S-PE 1132 passes any received AC or PW status bits unchanged, i.e., 1133 the status notification TLV is unchanged but the VCid in the 1134 case of a FEC 128 TLV is set to value of the PW segment to 1135 the next hop. 1137 -ii. When the local status for any of the PW segments is Down, 1138 the S-PE always sends "PW Down" status bits regardless if 1139 the received status bits from the remote node indicated AC 1140 UP/Down or PW UP/Down." 1142 9.6.1. S-PE initiated PW status messages 1144 The PW fault directions are defined as follows: 1146 +-------+ 1147 ---PW1 forward---->| |-----PW2 reverse----> 1148 S-PE1 | S-PE2 | S-PE3 1149 <--PW1 reverse-----| |<----PW2 forward----- 1150 +-------+ 1152 When a local fault is detected by the S-PE, a PW status message is 1153 sent in both directions along the PW. Since there are no attachment 1154 circuits on an S-PE, only the following status messages are relevant: 1156 0x00000008 - Local PSN-facing PW (ingress) Receive Fault 1157 0x00000010 - Local PSN-facing PW (egress) Transmit Fault 1159 Each S-PE needs to store only two 32-bit PW status words for each 1160 SS-PW: One for local failures , and one for remote failures (normally 1161 received from another PE). The first failure will set the appropriate 1162 bit in the 32-bit status word, and each subsequent failure will be 1163 ORed to the appropriate PW status word. In the case of the PW status 1164 word storing remote failures, this rule has the effect of a logical 1165 OR operation with the first failure received on the particular SS-PW. 1167 It should be noted that remote failures received on an S-PE are just 1168 passed along the MS-PW unchanged while local failures detected an an 1169 S-PE are signalled on both SS-PWs. 1171 A T-PE can receive multiple failures from S-PEs along the MH-PW, 1172 however only the failure from the remote closest S-PE will be stored. 1173 The PW status word received are just ORed to any existing remote PW 1174 status already stored on the T-PE. 1176 Given that there are two SS-PW at a particular S-PE for a particular 1177 MH-PW, there are for possible failure cases as follows: 1179 -i. PW2 reverse direction fault 1180 -ii. PW1 reverse direction fault 1181 -iii. PW2 forward direction fault 1182 -iv. PW1 forward direction fault 1184 It should also be noted that once a PW status notification message is 1185 initiated at a PW switching point for a partucular pw status bit any 1186 further status message, for the same status bit, received from an 1187 upstream neighbor is processed locally and not forwarded until the PW 1188 switching point original status error state is cleared. 1190 Each S-PE along the MS-PW MUST store any PW status messages 1191 transiting it. If more then one status message with the same PW 1192 status bit set is received by a T-PE only the last PW status message 1193 is stored. 1195 9.6.1.1. Local PW2 reverse direction fault 1197 When this failure occurs the S-PE will take the following actions: 1199 * Send a PW status message to S-PE3 containing "0x00000010 - Local 1200 PSN-facing PW (egress) Transmit Fault" 1201 * Send a PW status message to S-PE1 containing "0x00000008 - Local 1202 PSN-facing PW (ingress) Receive Fault" 1203 * Store 0x00000010 in the local PW status word for the SS-PW toward 1204 S-PE3. 1206 9.6.1.2. Local PW1 reverse direction fault 1208 When this failure occurs the S-PE will take the following actions: 1210 * Send a PW status message to S-PE1 containing "0x00000010 - Local 1211 PSN-facing PW (egress) Transmit Fault" 1212 * Send a PW status message to S-PE3 containing "0x00000008 - Local 1213 PSN-facing PW (ingress) Receive Fault" 1214 * Store 0x00000010 in the local PW status word for the SS-PW toward 1215 S-PE1. 1217 9.6.1.3. Local PW2 forward direction fault 1219 When this failure occurs the S-PE will take the following actions: 1220 * Send a PW status message to S-PE3 containing "0x00000008 - Local 1221 PSN-facing PW (ingress) Receive Fault" 1223 * Send a PW status message to S-PE1 containing "0x00000010 - Local 1224 PSN-facing PW (egress) Transmit Fault" 1225 * Store 0x00000008 in the local PW status word for the SS-PW toward 1226 S-PE3. 1228 9.6.1.4. Local PW1 forward direction fault 1230 When this failure occurs the S-PE will take the following actions: 1231 * Send a PW status message to S-PE1 containing "0x00000008 - Local 1232 PSN-facing PW (ingress) Receive Fault" 1233 * Send a PW status message to S-PE3 containing "0x00000010 - Local 1234 PSN-facing PW (egress) Transmit Fault" 1235 * Store 0x00000008 in the local PW status word for the SS-PW toward 1236 S-PE1. 1238 9.6.1.5. Clearing Faults 1240 Remote PW status fault clearing messages received by an S-PE will 1241 only be forwarded if there are no corresponding local faults on the 1242 S-PE. ( local faults always supersede remote faults ) 1244 Once the local fault has cleared, and there is no corresponding ( 1245 same PW status bit set ) remote fault, a PW status messages is sent 1246 out to the adjacent PEs clearing the fault. 1248 9.6.2. PW status messages and S-PE TLV processing 1250 When a PW status message is received that includes a S-PE TLV, the 1251 S-PE TLV information MAY be stored, along with the contents of the PW 1252 status Word according to the procedures described above. If 1253 subsequent PW status message for the same pw status bit are received 1254 the S-PE TLV will overwrite the previously stored S-PE TLV. 1256 9.6.3. T-PE processing of PW status messages 1258 The PW switching architecture is based on the concept that the T-PE 1259 should process the PW LDP messages in the same manner as if it was 1260 participating in the setup of a SS-PW. However T-PE participating a 1261 MS-PW, SHOULD be able to process the PW switching point TLV. 1262 Otherwise the processing of PW status messages , and other PW setup 1263 messages is exactly as described in [RFC4447]. 1265 9.7. Pseudowire Status Negotiation Procedures 1267 Pseudowire Status signaling methodology, defined in [RFC4447], SHOULD 1268 be transparent to the switching point. 1270 9.8. Status Dampening 1272 When the PW control plane switching methodology is used to cross an 1273 administrative boundary it might be necessary to prevent excessive 1274 status signaling changes from being propagated across the 1275 administrative boundary. This can be achieved by using a similar 1276 method as commonly employed for the BGP protocol route advertisement 1277 dampening. The details of this OPTIONAL algorithm are a matter of 1278 implementation, and are outside the scope of this document. 1280 10. Peering Between Autonomous Systems 1282 The procedures outlined in this document can be employed to provision 1283 and manage MS-PWs crossing AS boundaries. 1285 The use of more advanced mechanisms involving auto-discovery and 1286 ordered PWE3 MS-PW signaling will be covered in a separate document. 1288 11. Security Considerations 1290 This document specifies the LDP and L2TPv3 extensions that are needed 1291 for setting up and maintaining pseudowires. The purpose of setting up 1292 pseudowires is to enable layer 2 frames to be encapsulated and 1293 transmitted from one end of a pseudowire to the other. Therefore we 1294 treat the security considerations for both the data plane and the 1295 control plane. 1297 11.1. Data Plane Security 1299 Data plane security consideration as discussed in [RFC4447], 1300 [L2TPv3], and [PWE3-ARCH] apply to this extension without any 1301 changes. 1303 11.2. Control Protocol Security 1305 General security considerations with regard to the use of LDP are 1306 specified in section 5 of RFC 3036. Security considerations with 1307 regard to the L2TPv3 control plane are specified in [L2TPv3]. These 1308 considerations apply as well to the case where LDP or L2TPv3 is used 1309 to set up PWs. 1311 A Pseudowire connects two attachment circuits. It is important to 1312 make sure that LDP connections are not arbitrarily accepted from 1313 anywhere, or else a local attachment circuit might get connected to 1314 an arbitrary remote attachment circuit. Therefore an incoming session 1315 request MUST NOT be accepted unless its IP source address is known to 1316 be the source of an "eligible" peer. The set of eligible peers could 1317 be pre-configured (either as a list of IP addresses, or as a list of 1318 address/mask combinations), or it could be discovered dynamically via 1319 an auto-discovery protocol which is itself trusted. (Obviously if the 1320 auto-discovery protocol were not trusted, the set of "eligible peers" 1321 it produces could not be trusted.) 1323 Even if a connection request appears to come from an eligible peer, 1324 its source address may have been spoofed. So some means of 1325 preventing source address spoofing must be in place. For example, if 1326 all the eligible peers are in the same network, source address 1327 filtering at the border routers of that network could eliminate the 1328 possibility of source address spoofing. 1330 For a greater degree of security, the LDP MD5 authentication key 1331 option, as described in section 2.9 of RFC 3036, or the Control 1332 Message Authentication option of [L2TPv3] MAY be used. This provides 1333 integrity and authentication for the control messages, and eliminates 1334 the possibility of source address spoofing. Use of the message 1335 authentication option does not provide privacy, but privacy of 1336 control messages are not usually considered to be highly urgent. 1337 Both the LDP and L2TPv3 message authentication options rely on the 1338 configuration of pre-shared keys, making it difficult to deploy when 1339 the set of eligible neighbors is determined by an auto-configuration 1340 protocol. 1342 When the Generalized ID FEC Element is used, it is possible that a 1343 particular peer may be one of the eligible peers, but may not be the 1344 right one to connect to the particular attachment circuit identified 1345 by the particular instance of the Generalized ID FEC element. 1346 However, given that the peer is known to be one of the eligible peers 1347 (as discussed above), this would be the result of a configuration 1348 error, rather than a security problem. Nevertheless, it may be 1349 advisable for a PE to associate each of its local attachment circuits 1350 with a set of eligible peers, rather than having just a single set of 1351 eligible peers associated with the PE as a whole. 1353 12. IANA Considerations 1355 12.1. Channel Type 1357 The Channel Type code point is defined in [RFC4385], and an IANA 1358 registry was requested in [VCCV]. This draft further requests the 1359 following code point to be assigned to that registry. 0x01 OAM 1360 Indication For Multi Segment Pseudowires (MH-VCCV) 1362 12.2. L2TPv3 AVP 1364 This document uses a ne L2TP parameter, IANA already maintains a 1365 registry of name "Control Message Attribute Value Pair" defined by 1366 [RFC3438]. The following new values are required: 1368 TBA-L2TP-AVP-1 - PW Switching Point AVP 1370 12.3. LDP TLV TYPE 1372 This document uses several new LDP TLV types, IANA already maintains 1373 a registry of name "TLV TYPE NAME SPACE" defined by RFC3036. The 1374 following value is suggested for assignment: 1376 TLV type Description 1377 0x096D Pseudo Wire Switching TLV 1379 12.4. LDP Status Codes 1381 This document uses several new LDP status codes, IANA already 1382 maintains a registry of name "STATUS CODE NAME SPACE" defined by 1383 RFC3036. The following value is suggested for assignment: 1385 Assignment E Description 1386 0x0000003A 0 "PW Loop Detected" 1388 12.5. L2TPv3 Result Codes 1390 This document uses several new L2TPv3 status codes, IANA already 1391 maintains a registry of name "L2TPv3 Result Codes" defined by 1392 RFCxxxx. The following value is suggested for assignment: 1394 Assignment Description 1395 17 "sequencing not supported" 1397 12.6. New IANA Registries 1399 IANA needs to set up a registry of "PW Switching Point TLV Type". 1400 These are 8-bit values. Types value 1 through 3 are defined in this 1401 document. Type values 4 through 64 are to be assigned by IANA using 1402 the "Expert Review" policy defined in RFC2434. Type values 65 through 1403 127, 0 and 255 are to be allocated using the IETF consensus policy 1404 defined in [RFC2434]. Types values 128 through 254 are reserved for 1405 vendor proprietary extensions and are to be assigned by IANA, using 1406 the "First Come First Served" policy defined in RFC2434. 1408 The Type Values are assigned as follows: 1409 Type Length Description 1411 0x01 4 PW ID of last PW segment traversed 1412 0x02 variable PW Switching Point description string 1413 0x03 4/16 IP address of PW Switching Point 1414 0x04 variable MH VCCV Capability Indication 1415 0x05 variable AI of last PW segment traversed 1416 0x06 variable L2 PW address of PW Switching Point 1418 13. Intellectual Property Statement 1420 The IETF takes no position regarding the validity or scope of any 1421 Intellectual Property Rights or other rights that might be claimed to 1422 pertain to the implementation or use of the technology described in 1423 this document or the extent to which any license under such rights 1424 might or might not be available; nor does it represent that it has 1425 made any independent effort to identify any such rights. Information 1426 on the procedures with respect to rights in RFC documents can be 1427 found in BCP 78 and BCP 79. 1429 Copies of IPR disclosures made to the IETF Secretariat and any 1430 assurances of licenses to be made available, or the result of an 1431 attempt made to obtain a general license or permission for the use of 1432 such proprietary rights by implementers or users of this 1433 specification can be obtained from the IETF on-line IPR repository at 1434 http://www.ietf.org/ipr. 1436 The IETF invites any interested party to bring to its attention any 1437 copyrights, patents or patent applications, or other proprietary 1438 rights that may cover technology that may be required to implement 1439 this standard. Please address the information to the IETF at ietf- 1440 ipr@ietf.org. 1442 14. Full Copyright Statement 1444 Copyright (C) The IETF Trust (2007). 1446 This document is subject to the rights, licenses and restrictions 1447 contained in BCP 78, and except as set forth therein, the authors 1448 retain all their rights. 1450 This document and the information contained herein are provided on an 1451 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1452 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1453 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1454 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1455 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1456 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1458 15. Acknowledgments 1460 The authors wish to acknowledge the contributions of Wei Luo, Skip 1461 Booth, Neil Hart, Michael Hua, and Tiberiu Grigoriu. 1463 16. Normative References 1465 [RFC4385] " Pseudowire Emulation Edge-to-Edge (PWE3) 1466 Control Word for Use over an MPLS PSN", S. Bryant, et al., 1467 RFC4385, February 2006. 1469 [RFC4446] "IANA Allocations for Pseudowire Edge to Edge 1470 mulation (PWE3)", L. Martini, RFC4446, April 2006. 1472 [RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini, L., 1473 et al., rfc4447 April 2006. 1475 [RFC3985] Stewart Bryant, et al., PWE3 Architecture, 1476 RFC3985 1478 [2547BIS] "BGP/MPLS IP VPNs", Rosen, E, Rekhter, Y. 1479 draft-ietf-l3vpn-rfc2547bis-03.txt ( work in progress ), 1480 October 2004. 1482 [L2TPv3] "Layer Two Tunneling Protocol (Version 3)", J. Lau, 1483 M. Townsley, I. Goyret, RFC3931 1485 [VCCV] Nadeau, T., et al."Pseudo Wire Virtual Circuit Connection 1486 Verification (VCCV)", Internet Draft 1487 , October 2005. (work in progress) 1489 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1490 IANA Considerations section in RFCs", BCP 26, RFC 2434, October 1491 1998. 1493 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1494 Requirement Levels", BCP 14, RFC 2119, March 1997. 1496 [PW-ADDR] C. Metz, L. Martini, F. Balus, J. Sugimoto, "AII Types 1497 for Aggregation" draft-ietf-pwe3-aii-aggregate-02.txt, (work in 1498 progress), February 2007. 1500 17. Informative References 1502 [RFC4023] "Encapsulating MPLS in IP or Generic 1503 Routing Encapsulation (GRE)", Rosen, E, Rekhter, Y. 1504 RFC4023, March 2005. 1506 [PWE3-ARCH] "PWE3 Architecture" Bryant, et al., 1507 draft-ietf-pwe3-arch-07.txt ( work in progress ), June 2003. 1509 [PWE3-FRAG] "PWE3 Fragmentation and Reassembly", A. Malis, 1510 W. M. Townsley, draft-ietf-pwe3-fragmentation-05.txt 1511 ( work in progress ) February 2004 1513 [L2TP-L2VPN] "L2VPN Extensions for L2TP", Luo, Wei, 1514 draft-ietf-l2tpext-l2vpn-00.txt, ( work in progress ), Jan 2004 1516 [L2TP-INFOMSG] "L2TP Call Information Messages", Mistretta, 1517 Goyret, McGill, Townsley, draft-mistretta-l2tp-infomsg-02.txt, 1518 ( work in progress ), July 2004 1520 [L2TP-ATM] "ATM Pseudo-Wire Extensions for L2TP", Singh, 1521 Townsley, Lau, draft-ietf-l2tpext-pwe3-atm-00.txt, 1522 ( work in progress ), March 2004. 1524 [PWE3-ATM] "Encapsulation Methods for Transport of ATM 1525 Over IP and MPLS Networks", Martini, Rosen, Bocci, 1526 "draft-ietf-pwe3-atm-encap-05.txt", ( work in progress ), 1527 April 2004. 1529 [RFC3438] W. M. Townsley, "Layer Two Tunneling Protocol 1530 (L2TP) Internet" 1532 [PW-MSG-MAP] "Pseudo Wire (PW) OAM Message Mapping", Nadeau et al, 1533 draft-ietf-pwe3-oam-msg-map-02.txt, ( work in progress ), 1534 February 2005 1536 18. Author Information 1538 Luca Martini 1539 Cisco Systems, Inc. 1540 9155 East Nichols Avenue, Suite 400 1541 Englewood, CO, 80112 1542 e-mail: lmartini@cisco.com 1544 Thomas D. Nadeau 1545 Cisco Systems, Inc. 1546 300 Beaver Brook Road 1547 Boxborough, MA 01719 1548 e-mail: tnadeau@cisco.com 1550 Chris Metz 1551 Cisco Systems, Inc. 1552 e-mail: chmetz@cisco.com 1554 Mike Duckett 1555 Bellsouth 1556 Lindbergh Center 1557 D481 1558 575 Morosgo Dr 1559 Atlanta, GA 30324 1560 e-mail: mduckett@bellsouth.net 1561 Matthew Bocci 1562 Alcatel-Lucent 1563 Grove House, Waltham Road Rd 1564 White Waltham, Berks, UK. SL6 3TN 1565 e-mail: matthew.bocci@alcatel-lucent.co.uk 1567 Florin Balus 1568 Alcatel-Lucent 1569 701 East Middlefield Rd. 1570 Mountain View, CA 94043 1571 e-mail: florin.balus@alcatel-lucent.com 1573 Mustapha Aissaoui 1574 Alcatel-Lucent 1575 600, March Road, 1576 Kanata, ON, Canada 1577 e-mail: mustapha.aissaoui@alcatel-lucent.com