idnits 2.17.1 draft-balus-mh-pw-control-protocol-02.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 3667, Section 5.1 on line 996. -- Found old boilerplate from RFC 3978, Section 5.1 on line 35. -- Found old boilerplate from RFC 3978, Section 5.5 on line 967. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 978. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 985. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 991. ** Found boilerplate matching RFC 3978, Section 5.1 (on line 35), which is fine, but *also* found old RFC 3667, Section 5.1 text on line 996. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The abstract seems to contain references ([RFC3036bis], [PWARCH]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 137: '... definition MUST terminate on an ...' RFC 2119 keyword, line 247: '...g., PW1 and PW2) MUST be of the same P...' RFC 2119 keyword, line 525: '... i.e. MUST be set to zero when tran...' RFC 2119 keyword, line 547: '... of a PW segment MUST terminate on the...' RFC 2119 keyword, line 792: '...from the failure MUST be released as a...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 2005) is 6860 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'PW ARCH' on line 161 looks like a reference -- Missing reference section? 'RFC3036bis' on line 1000 looks like a reference -- Missing reference section? 'PWE3-ARCH' on line 210 looks like a reference -- Missing reference section? 'Segmented PW' on line 1017 looks like a reference -- Missing reference section? 'PW CONTROL' on line 368 looks like a reference -- Missing reference section? 'L2VPN SIGN' on line 1013 looks like a reference -- Missing reference section? 'VCCV' on line 1010 looks like a reference -- Missing reference section? 'MPLS FRR' on line 768 looks like a reference -- Missing reference section? 'Grace RS' on line 394 looks like a reference -- Missing reference section? 'TSPEC' on line 1023 looks like a reference -- Missing reference section? 'RFC3270' on line 1020 looks like a reference -- Missing reference section? 'BGP AD' on line 745 looks like a reference -- Missing reference section? 'PWE3 CNTL' on line 824 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PWE3 Working Group 3 Internet Draft 4 Expires: January 2006 6 David McDysan Florin Balus 7 MCI Mike Loomis 8 Jeff Sugimoto 9 Yuichiro Wada Nortel 10 NTT Communications 11 Andy Malis 12 Mike Duckett Tellabs 13 Bellsouth 14 Paul Doolan 15 Yeongil Seo Mangrove Systems 16 Korea Telecom 17 Prayson Pate 18 Chris Metz Overture Networks 19 Cisco Systems 20 Vasile Radoaca 21 Ping Pan Consultant 22 Hammerhead Systems 24 July 2005 26 Multi-Segment Pseudowire Setup and Maintenance using LDP 28 draft-balus-mh-pw-control-protocol-02.txt 30 Status of this Memo 32 By submitting this Internet-Draft, each author represents that any 33 applicable patent or other IPR claims of which he or she is aware 34 have been or will be disclosed, and any of which he or she becomes 35 aware will be disclosed, in accordance with Section 6 of BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as 40 Internet-Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six 43 months and may be updated, replaced, or obsoleted by other 44 documents at any time. It is inappropriate to use Internet-Drafts 45 as reference material or to cite them other than as "work in 46 progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html. 53 Abstract 55 [MS PWE3 Requirements] describes the requirements to allow a service 56 provider to extend the reach of pseudo-wires across multiple 57 domains. A Multi-Segment PW is defined as a set of two or more 58 contiguous PW segments that behave and function as a single point- 59 to-point PW. 61 The current specification of the PW Architecture [PW ARCH] defines 62 the PW as a single Segment entity, connecting the Attachment 63 Circuits between two Ultimate PEs (U-PE). The current procedures for 64 establishing a single segment PW (SS-PW) is described in [PW 65 Control], where typically an LDP session is established between the 66 ultimate PEs handling the Pseudowire End Service (PWES). No 67 intermediate nodes, between the PEs, are aware of the PW. 69 The purpose of this draft is to specify new LDP extensions, end to 70 end signaling procedures to address the related requirements 71 specified in [MS-PWE3 Requirements]. The proposed procedures follow 72 the guidelines defined in [RFC3036bis] and enable the usage of 73 addressing schemes (L2FECs) and other TLVs already defined for PWs 74 in [PW Control]. 76 The solution described in the draft provides a MS-PW Operational 77 Model, Signaling Procedures consistent with the regular (SS-)PWs, in 78 order to enable seamless implementation, deployment. The resulting 79 MS-PW building blocks accommodate and enhance LDP-VPLS, VPWS 80 solutions with minimal changes in the Information Models and 81 Software Modules related to the L2VPN functionality. 83 Table of Contents 85 1. Terminology...................................................3 86 2. Introduction and Scope........................................4 87 3. Relevant SS and MS-PW Architectures...........................4 88 4. Motivations and Resulting Design Requirements.................6 89 4.1 Satisfy the MS-PW requirements in [MS PWE3 Requirements].....6 90 4.1.1 Scalability and Inter-Domain Signaling and Routing.........6 91 4.1.2 Signaling Requirements.....................................7 92 4.2 Operational Consistency with SS-PWs..........................8 93 4.2.1 Service Identification and Provisioning Models.............8 94 4.2.2 OAM........................................................8 95 4.3 Service Resiliency...........................................9 96 5. Information Model for Dynamic Signaling of MS-PWs.............9 97 5.1 MS-PW TLV Design............................................10 98 6. Signaling Procedures.........................................12 99 6.1 Ensuring both MS-PW directions traverse the same U/S-PEs....12 100 6.2 LDP Signaling Walkthrough...................................13 101 6.3 Using common LDP Signaling procedures for MS and SS-PWs.....15 102 6.4 Determining the Next Signaling Hop..........................15 103 6.4.1 Static Provisioning of the next-signaling-hop.............15 104 6.4.2 "Discovery" Mechanisms for the next-signaling-hop.........16 105 7. Service Resiliency...........................................17 106 8. OAM Considerations...........................................17 107 8.1 MS-PW Capabilities..........................................18 108 8.1.1 PW Status Capability Negotiation..........................18 109 8.1.2 VCCV Capability Negotiation...............................18 110 8.2 PW Status Notification Operation............................18 111 8.3 VCCV Operation..............................................18 112 9. Security Considerations......................................19 113 10. IANA Considerations..........................................19 114 11. Acknowledgements.............................................19 115 12. Appendix: Example of Signaling Procedures....................19 116 13. Full Copyright Statement.....................................21 117 14. Intellectual Property Statement..............................21 118 15. References...................................................21 119 16. Authors' Information.........................................22 121 1. Terminology 123 The terminology used in this document is consistent with the 124 terminology used in [MS PWE3 Requirements]: 126 . Ultimate PE (U-PE). A PE where the customer-facing ACs 127 (attachment circuits) are bound to a PW forwarder. An ultimate 128 PE is present in the first and last segments of a MS-PW. 130 . Single-Segment PW(SS-PW). A PW setup directly between two U-PE 131 devices. Each LSP in one direction of a SS-PW traverses one PSN 132 tunnel that connects the two U-PEs. 134 . Multi-Segment PW (MS-PW). A static or dynamically configured 135 set of two or more contiguous PW segments that behave and 136 function as a single point-to-point PW. Each end of a MS-PW by 137 definition MUST terminate on an U-PE. 139 . PW Switching Provider Edge S-PE. A PE capable of switching the 140 control and data planes of the preceding and succeeding PW 141 segments in a MS-PW. It is therefore a PW switching point for a 142 MS-PW. A PW Switching Point is never both U-PE and S-PE for the 143 same MS-PW. A PW switching point runs necessary protocols to 144 setup and manage PW segments with other PW switching points and 145 ultimate PEs. 147 . PW Segment. A part of a Single-Segment or Multi-Segment PW, 148 which is set up between two adjacent PE devices, U-PEs and/or 149 S-PEs. 151 . Extended LDP session (E-LDP). An LDP session established using 152 targeted discovery mode [RFC3036bis] 154 2. Introduction and Scope 156 [MS PWE3 Requirements] describes the requirements to allow a service 157 provider to extend the reach of pseudo-wires across multiple 158 domains. A MS-PW is defined as a set of two or more contiguous PW 159 segments that behave and function as a single point-to-point PW. 161 The current specification of the PW Architecture [PW ARCH] defines 162 the PW as a single Segment entity, connecting attachment circuits on 163 exactly two PEs. The current procedures for establishing PWs are 164 described in [PW Control], where typically an LDP session is 165 established between the PEs handling the pseudowire end service 166 (PWES). The LDP session is referred to as "targeted" because it uses 167 a targeted discovery (via hello messages) to establish an LDP 168 session between the two PEs exchanging the PW labels. The tandem 169 nodes between the PEs are unaware of the PW and are only involved 170 with establishing a PSN tunnel between the (U-)PEs. 172 The purpose of this draft is to specify new LDP extensions and end 173 to end signaling procedures to address the requirements specified in 174 [MS PWE3 Requirements]. 176 The proposed procedures follow the guidelines defined in 177 [RFC3036bis] and enable the reuse of existing addressing schemes 178 (L2FECs) and other TLVs already defined for SS-PWs in [PW Control]. 180 3. Relevant SS and MS-PW Architectures 182 The following two figures describe the reference models [MS PWE3 183 Requirements] to support SS and MS-PW emulated services. 185 |<-------------- Emulated Service ---------------->| 186 | | 187 | |<------- Pseudo Wire ------>| | 188 | | | | 189 | | |<-- PSN Tunnel -->| | | 190 | PW End V V V V PW End | 191 V Service +----+ +----+ Service V 192 +-----+ | | PE1|==================| PE2| | +-----+ 193 | |----------|............PW1.............|----------| | 195 | CE1 | | | | | | | | CE2 | 196 | |----------|............PW2.............|----------| | 197 +-----+ ^ | | |==================| | | ^ +-----+ 198 ^ | +----+ +----+ | | ^ 199 | | Provider Edge 1 Provider Edge 2 | | 200 | | | | 201 Customer | | Customer 202 Edge 1 | | Edge 2 203 | | 204 | | 205 Attachment Circuit (AC) Attachment Circuit(AC) 206 native ethernet service native ethernet service 208 Figure 1: PWE3 Reference Configuration 210 Figure 1 shows the PWE3 reference architecture [PWE3-ARCH]. This 211 architecture applies to the case where a PSN tunnel extends between 212 two edges of a single PSN domain to transport a PW with endpoints at 213 these edges. 215 Native |<-----------Pseudo Wire----------->| Native 216 Layer2 | | Layer2 217 Service | |<-PSN1-->| |<--PSN2->| | Service 218 (AC) V V (AC) 219 | +----+ +-----+ +----+ | 220 +----+ | |UPE1|======== | SPE |=========|UPE2| | +---+ 221 | |----------|.......PW1....|.........PW2...|---------|----| | 222 | CE1| | | | | | | | |CE2| 223 +----+ | |=========| |=========| | +---+ 224 ^ +----+ +-----+ +----+ ^ 225 | Provider Edge 1 ^ Provider Edge 2 | 226 | (Ultimate-PE1) | (Ultimate-PE2) | 227 | PW switching point | 228 | (Optional PW adaptation function) | 229 | | 230 |<------------------- Emulated Service ----------------->| 232 Figure 2: MS-PW Reference Model 234 Figure 2 extends this architecture to show a Multi-Segment case. 235 UPE1 and UPE2 provide a Pseudowire from CE1 to CE2. Each UPE resides 236 in a different PSN domain. A PSN domain may correspond to a single 237 Provider's network or to a subset of nodes within a Provider 238 network. A PSN tunnel extends from UPE1 to SPE across PSN1, and a 239 second PSN tunnel extends from SPE to UPE2 across PSN2. 241 PWs are used to connect the Attachment circuits (ACs) attached to 242 UPE1 to the corresponding ACs attached to UPE2. The PW segment on 243 the tunnel across PSN1 is switched to a PW segment in the tunnel 244 across PSN2 at SPE to complete the Multi-Segment PW (MS-PW) between 245 UPE1 and UPE2. S-PE is therefore a PW switching point node and will 246 be referred to as the PW switching provider edge (S-PE). PW segments 247 of the same MS-PW (e.g., PW1 and PW2) MUST be of the same PW type, 248 but PSN tunnels (e.g., PSN1 and PSN2) can be the same or different 249 technology. 251 Note that although Figure 2 only shows a single S-PE, a PW may 252 transit more than one S-PE along its path. 254 4. Motivations and Resulting Design Requirements 256 This section describes the motivations and highlights the 257 architectural objectives of the proposal. 259 4.1 Satisfy the MS-PW requirements in [MS PWE3 Requirements] 261 4.1.1 Scalability and Inter-Domain Signaling and Routing 263 If a MS-PW deployment extends to large and far reaching portions of 264 one or more networks, mandating an E-LDP session between all 265 switching points of a MS-PW may lead to a control plane scalability 266 issue [MS PWE3 Requirements]. Some network topologies have a natural 267 hierarchy, as described in the use cases section of [MS PWE3 268 Requirements]. For example, multiple providers who wish to provide 269 PWs that span two or more networks will likely have a relatively 270 small number of gateway nodes as switching points (S-PE) that 271 provide access to a larger number of end nodes (U-PE) forming a 272 hierarchy. As another example, in some MPLS access network 273 topologies, it is foreseeable that thousands or even tens of 274 thousands of U-PE nodes may specify a small number of gateway nodes 275 as switching points (S-PE) for access to the MPLS backbone, breaking 276 the overall MPLS network into a well established hierarchy of MPLS 277 "domains". 279 In a more generic sense, [MS PWE3 Requirements] discusses a number 280 of cases of a PW Service that has to span multiple domains: e.g. 281 Inter-Provider, Inter-AS (same provider), MAN-WAN. In any of these 282 cases the interaction between domains is controlled by certain 283 gateways with a specific set of requirements for each individual 284 scenario. 286 This proposal eliminates the requirement for an E-LDP session 287 between every pair of U-PE nodes for which a PW is required while at 288 the same time preserving the necessary end to end signaling 289 properties. In doing so it alleviates the control plane scalability 290 requirements described in the previous paragraphs. Our proposal 291 enables the end to end PW signaling through a "chain" of (E-)LDP 292 sessions, using a dynamically determined set of S-PEs. If the S-PE 293 and U-PE are identified by IP addresses, then IP routing protocols 294 can distribute information to facilitate dynamic selection of a set 295 of PEs between a Source U-PE and a Destination U-PE based upon 296 parameters (e.g., metric, TE constraints, BGP attributes). U-PE 297 reachability information could be reduced by assignment of IP 298 address prefixes and/or prefix aggregation by a routing protocol. 300 There could also be some Inter-Provider scenarios where the U-PEs 301 located in a certain Provider domain may not be permitted to 302 communicate directly via an (E)-LDP session to a U-PE in a different 303 domain for operational and security reasons. For other reasons 304 (e.g., security, administrative, etc.) the local U-PE may have no 305 knowledge of the IP address of the remote U-PE. The requirements for 306 these valid scenarios are still being specified and it is not clear 307 whether or not a solution for dynamic end to end signaling is 308 required or even allowed. 310 A solution for these scenarios is for further study. 312 4.1.2 Signaling Requirements 314 The signaling described in this proposal is based on extensions to 315 [RFC3036bis] and [PW Control]. The new elements (section 6) provide 316 a flexible model that permits interoperability with manual 317 provisioning models, but also enable an end to end MS-PW to be 318 established with minimal number of OSS touches, ideally only one as 319 specified in [MS PWE3 Requirements]. Specifically, the proposal 320 enables the dynamic creation of an end-to-end MS-PW that does not 321 require any manual intervention at the S-PE nodes. 323 This draft allows for either the same set of S-PE nodes to be 324 traversed in each direction of the MS-PW, or a different set. 326 [Segmented PW] specifies the case where the set of intermediate S- 327 PEs is manually configured and the PW is stitched at these points by 328 matching the L2FEC for each segment and associating this with the 329 next segment. This case is not precluded by, and could interoperate 330 with, the method described in this document. 332 4.2 Operational Consistency with SS-PWs 334 In a Service Provider network it is understood that SS and MS-PWs 335 will co-exist, possibly for an indefinite amount of time. 336 Furthermore, it is foreseeable that existing SS-PWs may one day be 337 forced to migrate to a MS-PW scenario for a number of reasons. In 338 any case, it should be an advantage to vendors developing PW 339 implementations as well as providers of PW services to minimize the 340 differences between SS and MS-PWs. Operationally, the procedures for 341 identifying (addressing), provisioning and troubleshooting a SS or a 342 MS-PW should be similar. 344 4.2.1 Service Identification and Provisioning Models 346 [PW CONTROL] specifies that a PW is uniquely associated with a set 347 of connection identifiers: i.e. PWID (& U-PE pair) for PWID FEC or 348 AGI, AII1, AII2 for the Generalized ID FEC. This proposal reuses the 349 same service identifiers as SS-PW (PWID and Generalized ID FEC) to 350 identify MS-PWs. 352 From a provisioning perspective, this proposal is consistent with 353 the existing models for SS-PWs. For MS-PWs, both a single ended and 354 double ended model are possible as defined by [L2VPN SIGN], with no 355 user intervention required at any S-PE node. 357 In a MS-PW scenario, the S-PE nodes are aware of the PW. In the case 358 of PWID addressing, in order to reuse the service identifiers for 359 SS-PWs, the unique association between the U-PE pair and the PWID 360 FEC must be maintained when transiting through the S-PE nodes. In 361 the Generalized ID case a PW is identified by , 362 PE2, > in one direction and by , PE1, 363 > in the reverse direction [L2VPN SIGN]. 365 This document proposes some extensions to LDP to address the 366 requirements described above for consistent operational model across 367 different PW types. The proposed solution re-uses the same L2FEC 368 definitions as in [PW CONTROL] for identifying the virtual 369 connections and a similar service provisioning model. 371 The proposal does not preclude the use or support of existing Auto- 372 discovery procedures (e.g. BGP-AD, RADIUS). 374 4.2.2 OAM 376 It is important to support the end to end PW OAM concepts already 377 described in [VCCV] and [PW Control]. To meet this requirement, the 378 S-PE must participate in the negotiation of the PW OAM options and 379 Status TLV. 381 The current definition of PW OAM functions (e.g. VCCV (LSP-Ping, 382 BFD)) [VCCV] are specified only for operation on a U-PE to U-PE 383 basis. This means that the concatenation of PW switching of S-PEs 384 in MS-PW appears as a PSN tunnel to the PW OAM function. 386 Support for PW OAM on a U-PE to S-PE, or S-PE to S-PE segment basis, 387 will require changes in the OAM messages and procedures to indicate 388 whether the OAM message is intended for the destination U-PE, 389 intermediate S-PEs, or both. 391 4.3 Service Resiliency 393 Several MPLS mechanisms exist today, including procedures defined in 394 [RFC3036bis], [MPLS FRR], [Grace RS] etc. This draft does not 395 preclude the use of any of these mechanisms. 396 From a MS-PW perspective, Service Resiliency refers to the ability 397 to choose a backup path in case of failure of the existing MS-PW 398 path (including S-PE failure or any segment failure) [MS PWE3 399 Requirements]. 401 5. Information Model for Dynamic Signaling of MS-PWs 403 In the current (SS) PW Architecture (see figure 1), the setup and 404 maintenance of the PW connection is based on a direct, E-LDP Session 405 between PE1 and PE2. As a result of the bidirectional nature of PWs, 406 there is an association between the L2FEC, Source and Destination U- 407 PEs. This association is derived from the information related to the 408 (E-)LDP session between PEs and it is used as part of the end to end 409 message exchange. 411 In the case of a MS-PW (see figure 2), there is not an E-LDP session 412 between U-PE1 and U-PE2. Instead two LDP Sessions are to be used to 413 establish the MS-PW connection: LDP1 between U-PE1 and S-PE, LDP2 414 between U-PE2 and S-PE. 416 The procedures defined in [PW Control] can not be applied to achieve 417 the end to end signaling of the MS-PW. Specifically: 418 . the identity of the PW endpoints can no longer be derived from 419 the attributes of the local LDP session 420 . the PWID U-PE pair association is lost. PWID becomes globally 421 unique 422 . for the Generalized ID the direct association between PW and 423 <, PE2, > respectively , PE1, > is lost. 426 . the forwarding of received Label Mapping (LM) messages is not 427 allowed 429 In order to support dynamic end to end signaling [MS PWE3 430 Requirements], while maintaining a consistent operational model with 431 SS-PW, there is a need to maintain the relationships between L2FEC 432 and PW endpoints (as discussed above) that are lost when the direct 433 LDP session is not available. This document proposes transporting 434 the address of the Source and Destination U-PEs in the related LDP 435 messages transiting through S-PE node(s). The L2FEC in combination 436 with the source and destination U-PE information form unique PW 437 endpoint identifiers; for example using the GID FEC, the TAI and 438 destination U-PE information will be unique, similarly for the 439 source U-PE and SAI information. 441 This information could be transported in a number of ways: via new 442 "fields" inserted in the existing Generalized ID FEC or via a new 443 LDP TLV. Choosing one vehicle versus the other is orthogonal to the 444 concepts described in this document as long as the Source and 445 Destination information together with the corresponding L2FEC is 446 explicitly carried in the signaling message and used to identify, 447 route the PW signaling message from source to destination U-PE. 449 We describe, in section 5.1, the details of the LDP TLV approach as 450 it ensures backwards compatibility with existing deployments, 451 offering support for both PWID and Generalized ID FECs. 453 Details of the Generalized ID FEC usage is for further study 455 5.1 MS-PW TLV Design 457 We are introducing a new TLV, the Multi-Segment PW TLV, which is 458 appended by the Source U-PE to the LDP messages related to a MS-PW. 460 The following format is being proposed: 462 0 1 2 3 463 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 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 |0|0| MS-PW TLV (TBD) | MS-PW TLV Length | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | (Source) U-PE (Mandatory) | 468 | " | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | (Destination) U-PE (Mandatory) | 471 | " | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 - UF bits 00 - U equal 0 means that if the receiving PE does not 474 understand the TLV, a notification must be returned to the message 475 originator and the entire message must be ignored. 477 - MS-PW TLV (TBD) - To be assigned by IANA. Identifies this TLV as a 478 MS-PW. The presence of this TLV in LDP messages indicates this is a 479 MS-PW. 481 - MS-PW TLV Length - Specifies the total length in octets of the 482 TLV. 484 - Source U-PE (Mandatory) - The address of the originating U-PE 485 (e.g. U-PE1). In most of the cases it carries the IP loopback 486 address of the Source U-PE, although other address types - e.g. 487 IPv6, NSAP - could be supported. 488 This field is used by a MS-PW Network Element for maintaining the 489 uniqueness of PWID FECs and, optionally, in single sided 490 provisioning the discovery of the remote U-PE by the Destination U- 491 PE. When double sided provisioning is used, it is used to verify the 492 remote U-PE against the provisioned value. 494 - Destination U-PE (Mandatory) - The address of the Destination U-PE 495 (e.g. U-PE2) 497 Its value could be provisioned at the Source U-PE or is determined 498 as part of the single-sided provisioning behavior [L2VPN SIGN]. 500 The Destination U-PE address field is used to select the next hop 501 through the MS-PW domains. 503 The basic construct used to carry the Address of the Source and 504 Destination U-PEs is the Prefix Element which is defined below: 506 0 1 2 3 507 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 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Prefix Type | FLAGS | PreLen | Prefix | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 ~ Prefix (contd) ~ 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 - Prefix Type - one octet quantity. It encodes the address type for 515 the address prefix in the Prefix field. Initial formats supported 516 are: 517 - IPv4 0x01 518 - IPv6 0x02 519 - NSAP 0x03 521 Addition of other formats (or combinations of existing ones) for 522 further study: for example, AS Numbers, URLs etc. 524 - FLAGS - One octet field. The field is reserved for future use: 525 i.e. MUST be set to zero when transmitting a message and MUST be 526 ignored at the receiving PE. 528 - PreLen 529 One octet unsigned integer containing the length in bits of the 530 address prefix that follows. 532 - Prefix Value 533 An address prefix encoded according to the Prefix type field, whose 534 length, in bits, was specified in the PreLen field, padded to a byte 535 boundary. 537 6. Signaling Procedures 539 The following are generic procedures for signaling of an MS-PW. 541 Note that we are using throughout the next sections, examples based 542 on existing IP Loopbacks (as U-PE addresses) and references to IP 543 routing procedures. 545 According to section 6.1 of [MS PW Requirements]: "MS-PWs are 546 composed of SS-PW, and SS-PW are bi-directional, therefore both 547 directions of a PW segment MUST terminate on the same S-PE/U-PE". In 548 other words both directions of a MS-PW should traverse the same set 549 of S-PEs/U-PEs. 551 Next section introduces the concepts, procedures that ensure 552 compliance of the solution described in this document with the above 553 requirement. Note that should this requirement change (e.g. "MUST" 554 to "MAY terminate [..]") to enable for diverse S-PEs paths, our 555 solution could accommodate both options. 557 6.1 Ensuring both MS-PW directions traverse the same U/S-PEs 559 The proposed procedure is based on an "Ordered" establishment of the 560 individual PW segments that belong to a certain MS-PW. In other 561 words, the signaling is initiated only from the "originating" U-PE 562 node (selected based on provisioned information at nodal/PW level). 563 Any S-PEs or the other U-PE will not initiate a LM Message for the 564 setup of a MS-PW until it receives an incoming LM message for that 565 MS-PW. 567 We will refer to the direction from the originating U-PE node to the 568 other U-PE node as the "Forward" direction of a MS-PW. The Forward 569 direction describes the direction of the LDP label mapping messages 570 rather than the direction of the user dataplane. The Reverse 571 direction is the opposite logic, describing the direction towards 572 the originating U-PE node. 574 The following section first discusses the signaling in the "Forward" 575 direction followed by a brief description of the deltas in the 576 "Reverse" direction. Note that the flags from the destination U-PE 577 field (see section 5.1) may be used to indicate directionality/ 578 behavior in determining the next-signaling-hop. 580 6.2 LDP Signaling Walkthrough 582 The following section focuses on the step by step, generic signaling 583 procedures involved in the setup of a MS-PW. The procedures involved 584 in discovery of Next Signaling Hop are referenced in section 6.4. 586 1. The PW FEC (PWID or Generalized ID) and Destination U-PE is 587 provisioned on both U-PEs. If single sided provisioning or auto 588 discovery is used, the Destination U-PE needs only to be 589 configured on one of the U-PEs. 591 2. The originating U-PE builds the MS-PW TLV by inserting its local 592 address in the Source U-PE field and the address of Destination 593 U-PE in the Destination U-PE field. The MS-PW TLV and optional 594 TLVs, (e.g. QOS TLV) are appended to the LM message which is sent 595 to the Next Signaling Hop. The next signaling hop towards the dU- 596 PE can be determined by referencing the PW end point information 597 against the MS-PW information disseminated as per section 6.4. 599 3. When the next signaling hop receives the LM message, it verifies 600 a PSN tunnel exists to the upstream MS-PW NE. If a PSN tunnel is 601 not available a label release message is sent. However if the S- 602 PE and the next signaling hop are directly connected, with no P 603 device between them, the PSN tunnel may not be necessary [PW 604 Control]. 606 4. OAM parameters (VCCV, Status TLV support) are validated. If the 607 request cannot be supported a label release message is sent to 608 the upstream MS-PW NE. 610 5. If QoS information* was included in the LM message, the local NE 611 performs a CAC against the selected PSN Tunnel to requesting NE. 612 If the CAC fails a label release message is sent. Alternatively, 613 based on Service Provider choice an increase in the capacity of a 614 PSN tunnel may be tried to accommodate the bandwidth requirements 615 of the MS-PW. 617 6. If the Destination U-PE address does not equal the MS-PW NE 618 address, a new label mapping message is generated and sent to the 619 Next Signaling Hop, with the original L2FEC and MS-PW TLV, 620 replacing just the value of the service label in the Label TLV 621 with one from its own label space. Note that the S-PE should not 622 comply with the text of section 5.2.3 of [PW Control] i.e. should 623 not initiate a LM message in the opposite direction towards U-PE1 624 ("Ordered" Mode). Go to step 3. 626 7. When the Destination U-PE receives the LM message containing the 627 MS-PW TLV (the value from the destination U-PE field matches the 628 address of the local Network Element), it attempts to match the 629 L2 FEC with its local provisioning. 630 a) If the L2 FEC and the Source U-PE address do not match the 631 local provisioning, a label release message is sent. 633 b) If the L2 FEC is not provisioned, the label maybe retained 634 by virtue of liberal label retention 636 8. The remaining Destination U-PE processing of the PW label mapping 637 message is as defined in PWE3 control signaling standard [PW 638 Control] (see also tasks outlined in steps 3-5). This completes 639 the Signaling in the Forward direction. 641 9. MS-PW Signaling in the Reverse direction starts. The (new) source 642 U-PE and subsequently the S-PEs in the Reverse direction will 643 perform the tasks described in steps 2-8. 645 The next hop at any S-PE is determined by referencing the LDP 646 sessions used to setup the LSP in the Forward direction. The 647 particular LDP Session is determined using the index (dU-PE, 648 TAI/PWID) information from the LM message received from the 649 Reverse direction. The association between (L2FEC, sU-PE, dU-PE) 650 and the incoming LDP session is stored as the PW Segments are 651 established. This information is always required for further 652 Control Plane Exchanges (e.g. Label Release, PW Status) but is 653 used to also setup the MS-PW in the Reverse direction. 655 * The term "QoS Information" is used here to mean either one or both 656 of Quantity (e.g. Bandwidth) and/or Quality (e.g. DiffServ) of 657 Service. The detailed definition of the TLVs used to signal this 658 information is outside the scope of this document. Description of 659 possible TLV structures could be found in [TSPEC] and respectively 660 [RFC3270]. 662 6.3 Using common LDP Signaling procedures for MS and SS-PWs 664 In addition to the OSS and Operational consistency between SS [PW 665 Control] and MS-PWs concepts described in this document, it would be 666 preferable to have consistent procedures used in the Network 667 Elements in order to minimize implementation deltas. 669 If the U/S-PEs support the signaling procedures described in the 670 previous section for MS-PWs, then these Network Elements could use 671 consistent procedures to establish also SS-PWs between them. 673 In this context it is important to note that steps 1-9 are the same 674 for both SS/MS-PWs. The only difference between a SS/MS-PW is the 675 amount of times the procedure cycles through steps 3-6: i.e. in the 676 SS-PW case, the first receiving PE (see step 6) will determine that 677 the destination U-PE is itself and the source U-PE is the same with 678 the originator of the LDP session on which the LM message was 679 received. As a result it will run right away through the remaining 680 of the steps (7-9) instead of cycling 1/more times through steps 3-6 681 as for a MS-PW. 683 6.4 Determining the Next Signaling Hop 685 To support end-to-end dynamic signaling of MS-PWs, information must 686 be present in MS-PW aware nodes to support the determination of the 687 next signaling hop. Such information can be provisioned on each MS- 688 PW system or disseminated via regular routing protocols (e.g. BGP). 690 The following section describes procedures that could be used to 691 "discover" the next-signaling-hop in MS-PW aware systems. 693 6.4.1 Static Provisioning of the next-signaling-hop 695 The simplest way to build next-signaling-hop knowledge is by static 696 provisioning. The provisioning of the next-signaling-hop (e.g. S-PE) 697 is similar to the way IP static routes/default gateways are 698 provisioned: e.g. in a U-PE at the nodal level, a default S-PE is 699 provisioned manually when the MS-PW feature is enabled. This can be 700 a simple and effective method, when the network topology is simple 701 and well defined. 703 As long as the U-PE prefixes from one domain can be summarized the 704 static method could be also expanded to entire domains: i.e. all the 705 U-PEs in one domain being represented by 1/just a few static entries 706 of this sort: U-PE Prefix (47.0.0.0/8), NH = S-PE1. At the other 707 extreme, when special treatment is required for a certain PW a 708 "fully qualified" entry could be provisioned: e.g. AGI (40),U-PE1 709 (47.1.1.1), AII (200) -> NH (S-PE1). 711 Note that static provisioning may be used in combination with 712 dynamic discovery. Indeed, some PW domains may use static 713 provisioning while other PW domains along the multi-hop signaling 714 path may use dynamic discovery within their domain. An example of 715 this scenario is where many U-PEs in a given network will always use 716 a well known primary and backup S-PE "gateways" as the next hop. 717 This S-PE gateway may have many possible S-PE peers and may use a 718 dynamic discovery mechanism to determine the next-signaling-hop of 719 its S-PE peer for a given MS-PW. 721 6.4.2 "Discovery" Mechanisms for the next-signaling-hop 723 The next-signaling-hop selection can also be determined by 724 dynamically learning, for each PW Domain, the association between 725 the (Destination U-PE and optionally TAI/PWID) and the next- 726 signaling-hop. 728 There could be several mechanisms that allow dynamic discovery, 729 advertisement of the next-signaling-hop. The focus of this section 730 is on how this can be accomplished with BGP-based procedures. Note 731 that these procedures may have an end-to-end scope (e.g. Inter-AS 732 Use Case) or may be limited just to the PW Domain (e.g. MAN- 733 WAN Use Case), depending upon the availability of BGP in the related 734 MS-PW capable nodes. 736 The signaling procedures described in this draft are compatible and 737 make use of the L2VPN provisioning models and related AD procedures 738 described in [L2VPN SIGN] and respectively [BGP AD]. 740 If the Source U-PE knows apriori the address of the Destination U- 741 PE, there is no need to advertise a "fully qualified" address on a 742 per PW Attachment Circuit. The Destination U-PE may 743 advertise only its Prefix address (and not the Attachment 744 Identifier (AI)) as part of well known BGP auto-discovery procedures 745 - see [BGP AD], [L2VPN SIGN]. 747 As PW Endpoints are provisioned in the U-PEs, the Source U-PE will 748 use this information to obtain the first S-PE hop (i.e., first BGP 749 next hop) where the first PW segment will be established and 750 subsequent S-PEs will use the same information (i.e. the next BGP 751 next-hop(s)) to obtain the next-signaling-hop(s) on the path to the 752 Destination U-PE. 754 This is not an exhaustive list, merely examples of how discovery can 755 be accomplished using BGP. It can also be envisioned, in some 756 particular scenarios, that IGP with TE extensions could be used to 757 control the selection of the next-signaling-hop, while avoiding non 758 MS-PW aware devices (e.g. Ps, 2547 PEs). 760 7. Service Resiliency 762 With the introduction of dynamic determination of the intermediate 763 S-PEs, this proposal introduces the possibility of end to end (as 764 well as segment) connection resiliency for MS-PWs. 766 For failures between MS-PW elements, this document does not preclude 767 any existing MPLS failure recovery mechanisms from being used (i.e. 768 [MPLS FRR]). 770 For failures that prevent one MS-PW system from establishing a PW 771 segment to the succeeding MS-PW system (e.g. U-PE to S-PE), this 772 document adopts the procedures described in section 6 to allow for 773 the dynamic selection of intermediate next hops for the purpose of 774 service resiliency. For example, a source U-PE node can select a 775 candidate S-PE next hop via local preference (or via any other 776 metrics) for the purpose of service resiliency. 778 Several options are possible for service resiliency and a simple 779 example is provided here, with further optimizations to be explored 780 in future revisions of the document. Existing MPLS or PSN tunnel 781 recovery mechanisms must be attempted before the procedures 782 described below. 784 As a result of the MS-PW following the same forward and reverse 785 path, we propose that only the upstream node from the failure in the 786 forward path make the next hop selection. This provides consistency 787 with the procedures used to establish the original MS-PW (described 788 in section 6), where the forward path determines the backwards path 789 as well. Recall that each MS-PW system is already aware of the 790 direction of the MS-PW signaling, and its relation to that direction 791 for any particular MS-PW L2 FEC, sU-PE, dU-PE triplet. The MS-PW 792 segments downstream from the failure MUST be released as a new path 793 may be selected that does not overlap with the previous path. 795 If alternate routing is not possible at the closest MS-PW node 796 upstream from the failure, that node must release the PW segment to 797 the next upstream MS-PW system to attempt additional rerouting. 799 8. OAM Considerations 801 This section deals with the Negotiation of the OAM Capabilities 802 described in [VCCV], where the OAM functions (e.g. VCCV (LSP-Ping, 803 BFD)) are specified only for operation on a U-PE to U-PE basis. 805 Support for PW OAM on a U-PE to S-PE, or S-PE to S-PE segment basis, 806 require changes in the OAM messages and procedures to indicate 807 whether the OAM message is intended for the destination U-PE, 808 intermediate S-PEs, or both. These changes are for further study. 810 8.1 MS-PW Capabilities 812 Common OAM capabilities should be supported on all U-PE and S-PE 813 nodes in the MS-PW. MS-PW takes a least common denominator approach 814 to OAM. The minimum OAM functionality supported on a MS-PW is label 815 withdraw. 817 8.1.1 PW Status Capability Negotiation 819 PW Status capability is negotiated across the MS-PW when the MS-PW 820 is first setup. Support for PW status notification is indicated by 821 the presence of the status TLV in the label mapping message. 823 PW Status capability negotiation at the U-PE occurs as described in 824 [PWE3 CNTL]. 826 It is strongly recommended that MS-PW implement PW status TLV. 828 8.1.2 VCCV Capability Negotiation 830 VCCV capability is negotiated across the MS-PW when the MS-PW is 831 first setup. Support for VCCV is indicated by the presence of the 832 VCCV parameter in the interfaces parameter TLV. This parameter is 833 included in the label mapping message within the parameter TLV as 834 described in [VCCV] 836 VCCV capability negotiation at the U-PE occurs as described in 837 [VCCV] 839 An S-PE successfully negotiates VCCV capability for the MS-PW when 840 it support VCCV itself and the label mapping messages from its 841 upstream and downstream neighbors indicate support for VCCV for a 842 given MS-PW FEC. 844 8.2 PW Status Notification Operation 846 PW Status notification at the U-PE occurs as described in [PWE3 847 CNTL]. 849 When an S-PE receives a PW status notification message, the message 850 is processed at the S-PE and propagated down stream along the 851 control path. 853 8.3 VCCV Operation 855 VCCV operation at the MS-PW Network Element (NE) occurs as described 856 in [VCCV], with the S-PEs transparently forwarding these messages 857 towards the destination U-PE. 859 Support for MS-PW segment OAM, trace-route is for further study. 861 9. Security Considerations 863 To be addressed later. 865 10. IANA Considerations 867 A new TLV code point needs to be allocated by IANA for MS-PW TLV. 869 11. Acknowledgements 871 The editors gratefully acknowledge the following contributors: Luca 872 Martini, Nabil Bitar, Richard Spencer, Simon Delord, Bruce Davie, 873 Elizabeth Hache, Hamid Ould-Brahim, Praveen Muley, Arashmid 874 Akhavain. 876 12. Appendix: Example of Signaling Procedures 878 The following section discusses an example of an end to end 879 signaling walkthrough for a MS-PW using the architecture depicted in 880 Figure 2. 882 Let us assume that Double-sided provisioning and Generalized ID FEC 883 are being used to set up the MS-PW built using segments PW1 and PW3 884 and using LDP1 and LDP2 sessions. 886 Here are the required steps: 888 1. Service Provisioning 889 a) at U-PE1: AGI = 40, SAII=100, TAII=200, Remote PE = U-PE2 890 (IP2 loopback), Origin = Yes 891 b) at U-PE2: AGI = 40, SAII=200, TAII=100, Remote PE = U-PE1 892 (IP1 loopback); 894 2. The originating U-PE (U-PE1 in our example) builds the MS-PW TLV 895 by inserting its loopback address in the Source U-PE field and 896 the address of U-PE2 in the Destination U-PE field. Next it 897 appends the MS-PW TLV to the label mapping message associating 898 the provisioned FEC information - i.e. (40,100,200) - with the 899 corresponding PW service label. 901 3. Using the address of Destination U-PE (U-PE2), U-PE1 selects the 902 next signaling hop (S-PE) determined by referencing the PW end 903 point information - IP2,40,200 - against the MS-PW information 904 disseminated as per section 6.4. 906 4. On receipt of the LM message, S-PE performs the following tasks: 907 Verifies it has a PSN tunnel to U-PE1. If no tunnel is found a 908 label release message is sent. 910 a) Verifies it can support the requested OAM parameters (VCCV, 911 Status TLV support). If the request cannot be supported a 912 label release message is sent to U-PE1. 914 b) If QoS information* was included in the LM message, it 915 performs a CAC against the selected PSN Tunnel to U-PE1. If 916 the CAC fails a label release message is sent to U-PE1. 917 Alternatively, based on Service Provider choice, an 918 increase in the capacity of the PSN tunnel may be tried to 919 accommodate the bandwidth requirements of the MS-PW. 921 c) Checks to see if it is the Destination U-PE by comparing 922 the address within the MS-PW TLV d-UPE field with its own 923 address. If the addresses are not the same, S-PE looks for 924 a next signaling hop to get to U-PE2 - see step 3 above. 925 Then it signals the final segment of the MS-PW by 926 generating and forwarding a new label mapping message to U- 927 PE2, with the original L2FEC (40,100,200) and MS-PW TLV 928 (IP1, IP2), replacing just the value of the service label 929 in the Label TLV with one from its own label space. 931 5. When U-PE2 receives the LM message containing the MS-PW TLV, it 932 performs tasks outlined in step 4. 934 6. U-PE2 then attempts to match the L2 FEC with its local 935 provisioning. 936 a) If the FEC information and the U-PE1 address do not match 937 the local provisioning, a label release message is sent. 938 b) If the FEC information (40,200,100) is not yet provisioned, 939 the label may be retained by virtue of liberal label 940 retention. 942 7. The remaining U-PE2 processing of the PW label mapping message is 943 defined in PWE3 control signaling [PW Control]. 945 8. MS-PW Signaling in the Reverse direction U-PE2 to U-PE1 starts. 946 The U-PE2 and subsequently S-PE will perform the tasks described 947 in steps 2-7. The next hop at U-PE2 and S-PE is determined by 948 referencing the LDP sessions used to setup the LSP in the Forward 949 direction. The particular LDP Session is determined in the U-PE2 950 and S-PE using the index (IP1,TAI(40,100)) from the LM message 951 received from the Reverse direction. 953 13. Full Copyright Statement 955 Copyright (C) The Internet Society (2005). 957 This document is subject to the rights, licenses and restrictions 958 contained in BCP 78, and except as set forth therein, the authors 959 retain all their rights. 961 This document and the information contained herein are provided on an 962 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 963 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 964 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 965 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 966 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 967 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 969 14. Intellectual Property Statement 971 The IETF takes no position regarding the validity or scope of any 972 Intellectual Property Rights or other rights that might be claimed to 973 pertain to the implementation or use of the technology described in 974 this document or the extent to which any license under such rights 975 might or might not be available; nor does it represent that it has 976 made any independent effort to identify any such rights. Information 977 on the procedures with respect to rights in RFC documents can be 978 found in BCP 78 and BCP 79. 980 Copies of IPR disclosures made to the IETF Secretariat and any 981 assurances of licenses to be made available, or the result of an 982 attempt made to obtain a general license or permission for the use of 983 such proprietary rights by implementers or users of this 984 specification can be obtained from the IETF on-line IPR repository at 985 http://www.ietf.org/ipr. 987 The IETF invites any interested party to bring to its attention any 988 copyrights, patents or patent applications, or other proprietary 989 rights that may cover technology that may be required to implement 990 this standard. Please address the information to the IETF at ietf- 991 ipr@ietf.org. 993 By submitting this Internet-Draft, I certify that any applicable 994 patent or other IPR claims of which I am aware have been disclosed, 995 or will be disclosed, and any of which I become aware will be 996 disclosed, in accordance with RFC 3668. 998 15. References 1000 [RFC3036bis] Andersson, Minei, Thomas. "LDP Specification" draft- 1001 ietf-mpls-rfc3036bis-01.txt, IETF Work in Progress, November 2004 1002 [MS PWE3 Requirements] Martini et al. "Requirements for inter domain 1003 Pseudo-Wires", draft-ietf-pwe3-ms-pw-requirements-00.txt, IETF Work 1004 in Progress, June 2005 1006 [PW Control] Martini et.al. "Pseudowire Setup and Maintenance using 1007 LDP", draft-ietf-pwe3-control-protocol-17.txt, IETF Work in 1008 Progress, June 2005 1010 [VCCV] Nadeau et.al., "Pseudo Wire (PW) Virtual Circuit Connection 1011 Verification (VCCV)", draft-ietf-pwe3-vccv-03.txt, June 2004 1013 [L2VPN SIGN] Rosen et. al. "Provisioning Models and Endpoint 1014 Identifiers in L2VPN Signaling", draft-ietf-l2vpn-signaling-03.txt, 1015 IETF Work in Progress, February 2005 1017 [Segmented PW] Martini et.al. " Segmented Pseudo Wire", draft-ietf- 1018 pwe3-segmented-pw-00.txt, IETF Work in Progress, July 2005 1020 [RFC3270] Le Faucheur, et. al. "MPLS Support of Differentiated 1021 Services", RFC 3270, May 2002 1023 [TSPEC] Wroclawski, J. "The Use of RSVP with IETF Integrated 1024 Services", RFC 2210, September 1997 1026 16. Authors' Information 1028 Andrew G. Malis 1029 Tellabs, Inc. 1030 2730 Orchard Parkway 1031 San Jose, CA, USA 95134 1032 Email: Andy.Malis@tellabs.com 1034 Chris Metz 1035 Cisco Systems, Inc. 1036 3700 Cisco Way 1037 San Jose, Ca. 95134 1038 Email: chmetz@cisco.com 1040 David McDysan 1041 MCI 1042 22001 Loudoun County Pkwy 1043 Ashburn, VA, USA 20147 1044 dave.mcdysan@mci.com 1046 Florin Balus 1047 Nortel 1048 3500 Carling Ave. 1049 Ottawa, Ontario, CANADA 1050 balus@nortel.com 1051 Jeff Sugimoto 1052 Nortel 1053 3500 Carling Ave. 1054 Ottawa, Ontario, CANADA 1055 sugimoto@nortel.com 1057 Mike Duckett 1058 Bellsouth 1059 Lindbergh Center 1060 D481 1061 575 Morosgo Dr 1062 Atlanta, GA 30324 1063 e-mail: mduckett@bellsouth.net 1065 Mike Loomis 1066 Nortel 1067 600, Technology Park Dr 1068 Billerica, MA, USA 1069 mloomis@nortel.com 1071 Paul Doolan 1072 Mangrove Systems 1073 IO Fairfield Blvd 1074 Wallingford, CT, USA 06492 1075 pdoolan@mangrovesystems.com 1077 Ping Pan 1078 Hammerhead Systems 1079 640 Clyde Court 1080 Mountain View, CA, USA 94043 1081 e-mail: ppan@hammerheadsystems.com 1083 Prayson Pate 1084 Overture Networks, Inc. 1085 507 Airport Blvd, Suite 111 1086 Morrisville, NC, USA 27560 1087 Email: prayson.pate@overturenetworks.com 1089 Yuichiro Wada 1090 NTT Communications 1091 3-20-2 Nishi-Shinjuku, Shinjuke-ku 1092 Tokyo 163-1421, Japan 1093 yuichiro.wada@ntt.com 1095 Yeongil Seo 1096 Korea Telecom Corp. 1097 463-1 Jeonmin-dong, Yusung-gu 1098 Daejeon, Korea 1099 syi1@kt.co.kr