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