idnits 2.17.1 draft-bocci-l2vpn-pnni-mpls-iw-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 3978, Section 5.1.a on line 26. -- Found old boilerplate from RFC 3978, Section 5.5 on line 631. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 608. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 615. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 621. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 191 has weird spacing: '...terface to ...' -- 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 (November 15, 2004) is 7101 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) ** Downref: Normative reference to an Informational draft: draft-ietf-pwe3-arch (ref. '3') == Outdated reference: A later version (-11) exists of draft-ietf-pwe3-atm-encap-07 -- Possible downref: Non-RFC (?) normative reference: ref. '5' == Outdated reference: A later version (-17) exists of draft-ietf-pwe3-control-protocol-11 Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Bocci, Ed. 2 Internet-Draft Alcatel 3 Expires: May 16, 2005 M. Jensen 4 Equipe Communications 5 D. Proch 6 Marconi Communications 7 J. Sugimoto 8 Nortel Networks 9 H. Shah 10 Ciena Corp. 11 November 15, 2004 13 Signalling Interworking for Asynchronous Transfer Mode Virtual 14 Private Wire Service 15 draft-bocci-l2vpn-pnni-mpls-iw-02 17 Status of this Memo 19 This document is an Internet-Draft and is subject to all provisions 20 of section 3 of RFC 3667. By submitting this Internet-Draft, each 21 author represents that any applicable patent or other IPR claims of 22 which he or she is aware have been or will be disclosed, and any of 23 which he or she become aware will be disclosed, in accordance with 24 RFC 3668. This document may not be modified, and derivative works of 25 it may not be created, except to publish it as an RFC and to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on May 16, 2005. 46 Copyright Notice 48 Copyright (C) The Internet Society (2004). 50 Abstract 52 This Internet Draft describes a method for control plane interworking 53 for Asynchronous Transfer Mode (ATM) pseudo wires, where Provider 54 Edge nodes (PEs) on both sides of an MPLS Packet Switched Network 55 (PSN) connect edge ATM networks using the Private Network-Network 56 Interface (PNNI) or the ATM Inter-Network Interface (AINI). In this 57 method, ATM signalling and routing messages are tunnelled over the 58 PSN using dedicated pseudo wires, enabling ATM pseudo wires carrying 59 user traffic to be established and release dynamically by ATM. The 60 method does not require changes to existing IETF defined protocols in 61 order to support all features of PNNI and AINI. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1 Conventions Used in this Document . . . . . . . . . . . . 3 67 1.2 Additional Contributors and Acknowledgements . . . . . . . 3 68 1.3 Objectives and Scope . . . . . . . . . . . . . . . . . . . 3 69 1.4 Relevance . . . . . . . . . . . . . . . . . . . . . . . . 4 70 1.5 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.6 A Note on Terminology Differences . . . . . . . . . . . . 5 72 2. ATM Signalled to ATM Signalled Networks . . . . . . . . . . . 6 73 2.1 Tunnelling of the ATM Control Plane . . . . . . . . . . . 6 74 2.1.1 Extending ATM Signalling Across the PSN . . . . . . . 7 75 2.1.2 Extending PNNI Routing Across the PSN . . . . . . . . 8 76 2.1.3 ATM Control Plane Association to PSN Tunnels . . . . . 8 77 2.1.4 Encapsulation Format . . . . . . . . . . . . . . . . . 9 78 2.1.5 Quality of Service . . . . . . . . . . . . . . . . . . 9 79 2.2 Resiliency . . . . . . . . . . . . . . . . . . . . . . . . 9 80 2.2.1 PSN-based Protection of the PSN Tunnel . . . . . . . . 10 81 2.2.2 PNNI-based Protection of the Pseudo Wires . . . . . . 10 82 2.3 Operations, Administration and Maintenance . . . . . . . . 11 83 3. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 85 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 5.1 Normative References . . . . . . . . . . . . . . . . . . . . 14 87 5.2 Informative References . . . . . . . . . . . . . . . . . . . 14 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 89 Intellectual Property and Copyright Statements . . . . . . . . 16 91 1. Introduction 93 1.1 Conventions Used in this Document 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC-2119 [1]. 99 1.2 Additional Contributors and Acknowledgements 101 Additional contributors to this document are: 103 Mustapha Aissaoui, Alcatel, mustapha.aissaoui@alcatel.com 104 David Watkinson, Alcatel, david.watkinson@alcatel.com 105 George Matey, Equipe Communications, george@equipecom.com 106 John Rutemiller, Marconi Communications, john.rutemiller@marconi.com 107 Ghassem Koleyni, Nortel Networks, ghassem@nortelnetworks.co 108 m 110 The authors also gratefully acknowledge the input of Peter Roberts, 111 Dimitri Papadimitriou and Jack Pugaczewski. 113 1.3 Objectives and Scope 115 This informative document extends [7] by including mechanisms for 116 interworking with attachment circuits that are Asynchronous Transfer 117 Mode (ATM) Soft Permanent Virtual Channels or Soft Permanent Virtual 118 Paths (SPVCs/SPVPs) and ATM Switched Virtual Channels or Switched 119 Virtual Paths (SVCs/SPVCs) for Multi Protocol Labels Switching (MPLS) 120 based Packet Switched Networks (PSNs). 122 Service providers are introducing new PSN based networks and are 123 looking for a seamless way to extend the reach of existing ATM 124 services to new sites attached to this PSN network. One important 125 capability which is used in the existing ATM networks is ATM switched 126 services. These are mainly SPVC services, and to a lesser extent SVC 127 services. SPVC services are critical in today's networks as they 128 allow simplified provisioning of the ATM services by configuring the 129 endpoints only. They also allow dynamic traffic engineering and a 130 faster restoration in the case of a network failure. Finally, ATM 131 SPVCs extend connectivity to non-ATM endpoints, such as Frame Relay 132 and Ethernet, on an ATM switch. Thus ATM SPVCs support both native 133 ATM, and non-ATM services and are used in both network and service 134 interworking deployment scenarios. Non-ATM services continue to 135 drive deployments of ATM SPVCs. By transparently supporting ATM 136 switched services over the PSN, existing provisioning tools and 137 operational procedures may be used. It is therefore important to 138 provide methods for interworking ATM switched services and PSN based 139 services such as Virtual Private Wire Service (VPWS). 141 In this document, the attachment circuits on both the ingress and 142 egress Provider Ede Nodes (PEs) are either ATM SPVCs/SPVPs or ATM 143 SVCs/SVPs. In addition, ATM Private Network-Network Interface (PNNI) 144 routing may run between the ingress and egress PEs. 146 There are no methods to signal port connections in ATM, and thus 147 there is no intent to provide VPWS services for transporting an 148 entire ATM port across the PSN using these services. These services 149 should use standard VPWS services instead. This may include the 150 tunnelling of many VC's including PNNI Routing Control Channels 151 (RCCs) and signalling channels within the same port pseudo wire. 152 There are no control plane interactions between ATM 153 signalling/routing and the underlying PSN, and therefore there are no 154 protocol considerations. 156 This document describes methods and procedures specified in ATM Forum 157 Specification "ATM-MPLS Network Interworking Signalling 158 Specification, Version 1.0"[5]. 160 1.4 Relevance 162 This informative document shows how the existing Layer 2 Virtual 163 Private Network framework (L2VPN)[7] and the Pseudo Wire Emulation 164 Edge-to-Edge (PWE3) architecture [3] can be leveraged to tunnel ATM 165 signalling and routing through the PSN. We show how ATM pseudo wires 166 can be established and released as required by the ATM switched 167 service, without requiring changes to existing IETF protocols e.g. 168 [2], [6], [8]. This addresses work item 2 of the Layer 2 VPN working 169 group charter for signalling layer 2 information. 171 1.5 Terminology 173 This document uses the following terms. Formal definitions of some 174 of these terms can be found in [3] 176 ATM Inter Network An ATM Forum specification for signaling to 177 Interface (AINI) establish point-to-point and point-to- 178 multipoint connections across an ATM 179 network 181 Attachment Circuit The physical or virtual circuit attaching 182 (AC) a PE to a CE. In the context of the 183 application described here, this will be an 184 ATM VCI or VPI. 186 Integrated An ATM Forum specification allowing any ATM 187 Link Management device to be provided with status and 188 Interface (ILMI) configuration information. 190 Private Network ATM Forum specification to establish point 191 to Network Interface to point and point to multipoint connections 192 across an ATM network including source, 193 routing, crankback, and alternate routing 195 Provider Edge (PE) A device that provides PWE3 to a CE. 197 Pseudo Wire (PW) A mechanism that carries the essential 198 elements of an emulated service from one PE 199 to one or more other PEs over a PSN. 201 Pseudo Wire Emulation A mechanism that emulates the essential 202 Edge to Edge (PWE3) attributes of a service (such as an ATM 203 VCC) over a PSN. 205 PSN Tunnel A tunnel across a PSN inside which one or 206 more PWs can be carried. 208 Routing Control An ATM connection that carries PNNI routing 209 Channel (RCC) messages between PNNI neighbouring peer 210 nodes 212 Tunnel A method of transparently carrying 213 information over a network. 215 Virtual Private A point-to-point circuit (link) connecting 216 Wire Service (VPWS) two Customer Edge devices. 218 1.6 A Note on Terminology Differences 220 There are some differences in terminology between the IETF, and that 221 used by the ATM Forum in [5]. Figure 2 summarizes the main terms. 223 IETF Term | ATM Forum Term 224 -------------------|-------------------- 225 Pseudo Wire | Interworking LSP 226 Pseudo Wire Label | Interworking Label 227 PSN Tunnel | Transport LSP 228 Provider Edge | Interworking Network Element 230 Figure 2: Terminology 232 2. ATM Signalled to ATM Signalled Networks 234 ACs PSN ACs 236 ATM ATM 237 +------+ Tunnel +------+ 238 +-----+ | PE1 |==============| PE2 | +-----+ 239 | CE1 |-----------.........PW..........-------------| CE2 | 240 +-----+ | VPWS | | VPWS | +-----+ 241 | |==============| | 242 +------+ +------+ 244 Figure 3: Architecture 246 Figure 3 shows the general architecture for ATM VPWS. The attachment 247 circuits are ATM VCCs or VPCs that span an ATM network. ATM 248 connections are mapped to Pseudo Wires (PWs) in the PSN tunnel. ATM 249 SVC services start and terminate on the attached CE devices, while 250 the signalling for the SPVC services originates and terminates on the 251 ATM switches in the ATM networks that the CEs are physically attached 252 to, or on the PE where there is only a single hop path netween the CE 253 and the PE. The objective is to provide service over a PSN without 254 impacting the ATM signalling that occurs between the CE devices, and 255 without requiring changes to non-ATM protocols between PE1 and PE2 256 e.g. MPLS [2], the PWE3 control protocol [8], or RSVP-TE [6]. 258 ATM signalling and routing typically operates over PNNI [10] or AINI 259 [11] interfaces. Signalling and routing messages for these protocols 260 are carried on dedicated ATM VCCs. These are known as Signalling 261 Channels for signalling messages and Routing Control Channels (RCC 262 s) 263 for PNNI routing messages. For ATM link managent messages, an ILMI 264 channel [13] may be used. For AINI, static ATM routing is assumed 265 and so no RCC is present. 267 2.1 Tunnelling of the ATM Control Plane 269 The terminology used in this section follows the L2VPN naming 270 conventions. The use of the pseudo wire label in this section can be 271 related to the use of the interworking label within [5]. 273 ACs PSN ACs 275 ATM ATM 276 +-----+ Tunnel +------+ 277 _____ | PE1 |=============| PE2 | _____ 278 ( )--Sig---- ......PW.(SIG)..... ------Sig---( ) 279 ( ATM ) |VPWS | | VPWS | ( ATM ) 280 (network) | | | | (network) 281 ( )--RCC---- ......PW.(RCC)..... ------RCC---( ) 282 ~~~~~~~ | |=============| | ~~~~~~~ 283 +-----+ +------+ 285 Figure 4: Extending ATM Signalling and Routing Across the PSN 287 Figure 4 shows how ATM signalling and routing is extended across the 288 PSN between attached ATM networks. In the case of ILMI, a PW would 289 also be present that represents an ILMI channel in the ATM network. 291 2.1.1 Extending ATM Signalling Across the PSN 293 In the case of signalling, a bidirectional PW MUST established, using 294 the PW signalling protocol [8], or by configuration. to carry the 295 ATM signalling channel messages transparently across the PSN for 296 either PNNI or AINI. This allows all of the existing and future ATM 297 signalling capabilities to be carried transparently. 299 [5] explains how ATM signalling is extended across the PSN to 300 advertise PW labels between PE1 and PE2. The PNNI and AINI protocol 301 extensions described in [5] add an Interworking Information Element 302 (IE) which supports label exchange between the PE pair for the ATM 303 connection pseudo wire and the negotiation of encapsulation methods 304 for the connection. There is no requirement for any ATM capable 305 system, other than the PEs, to understand or support the Interworking 306 IE. Therefore legacy systems can take advantage of the interworking 307 capabilities without need for software modifications. Since ATM 308 signalling messages are carried transparently between the PE pairs, 309 there are no protocol considerations for the PSN related to the 310 signalling and establishment of ATM connection pseudo wires. 312 The pseudo wire label for an ATM connection is carried between the 313 two PEs in the Interworking IE within the PNNI or AINI signalling 314 messages. As the label is significant only to the PE devices at 315 either end of the PSN tunnel, this IE can be added to the signalling 316 message by the PE. Where other non-ATM VPWS services are also 317 supported by the PE and pseudo wire labels are allocated from the 318 same label space as ATM pseudo wires, the PE will need to manage 319 common resources between multiple control plane protocols e.g. [5] 320 and [8]. This is a common capability in current PE devices. 322 Implementations should provide a mechanism to restrict the maximum 323 the number of PWs that can be established on the PSN tunnel so that 324 the PW label space in the downstream PE does not become exhausted. 325 The details of this mechanism are outside the scope of this document. 327 2.1.2 Extending PNNI Routing Across the PSN 329 ATM Routing is also extended between PE1 and PE2 as explained in [5]. 330 Before the ATM routing can start exchanging ATM reachability across 331 the PSN tunnel, a PNNI RCC MUST be set up between PE1 and PE2 in 332 Figure 4. As in the case of signalling, the PW control protocol [8], 333 or configuration, sets up a bidirectional PW to carry the ATM routing 334 messages in each direction. This PW represents an RCC between PE1 335 and PE2. 337 For PNNI, the PSN tunnel can be modelled as a PNNI link between PE1 338 and PE2, thus extending ATM reachability across the MPLS network 339 using any desired meshing. Therefore, PNNI Routing can take 340 advantage of any parallel or alternate tunnels through the MPLS 341 network. This includes the use of multiple hops (i.e. a sparse 342 mesh), whereby the pseudo wire leaves one PSN tunnel at a given PE, 343 is processed by the ATM signalling on that PE, and enters another PSN 344 tunnel before terminating at the egress PE. 346 PNNI Routing can also properly traffic engineer the usage of any 347 traffic engineered MPLS PSN tunnels. This is achieved by PNNI 348 Routing advertising the available bandwidth of an MPLS PSN tunnel for 349 use by the pseudo wires to the attached ATM networks. Any of the ATM 350 addressing formats can be used in these network situations and is 351 fully transparent to the PSN. 353 This method supports all currently deployed PNNI network scenarios, 354 including PNNI Hierarchy. 356 Note that signalling of the PSN tunnel is beyond the scope of this 357 document. 359 2.1.3 ATM Control Plane Association to PSN Tunnels 361 There is no stipulation or restriction on how PSN Tunnels are 362 established between two PE devices. The architecture requires at 363 least one bidirectional PSN Tunnel between two PE devices, but can 364 also support multiple PSN Tunnels modeled as a single PNNI or AINI 365 link. In its simplest default case, a single PSN Tunnel is 366 represented as a single PNNI or AINI link. The control pseudo wires 367 i.e those representing Signalling Channels and RCCs, are carried 368 "in-band" - that is within the PSN tunnel whose ATM PWs they control. 370 In other cases, where multiple PSN Tunnels may be used to support QoS 371 guarantees, resiliency requirements or more efficient usage of PSN 372 resources, a single set of control pseudo wires may be used to manage 373 the resources of all PSN tunnels available for ATM established 374 between the two PEs. These control pseudo wires may be carried 375 within one of the PSN Tunnel pairs, but are not required to be 376 associated directly with the tunnels they control. 378 2.1.4 Encapsulation Format 380 Any of the ATM PW encapsulations can be used for both PWs carrying 381 user data, and those used for RCC, ILMI or Signalling channels. The 382 PW types as defined in [4] are used for user connections based on the 383 signalled ATM parameters, as defined in [5]. The choice of 384 encapsulation will depend on its ability to support the requirements 385 of the ATM service, as described in [4]. 387 Negotiation of an encapsulation mode is a local matter between a pair 388 of PEs. While an ATM end system may add the Interworking IE to 389 request a specific encapsulation mode at any interworking interface, 390 it is not required. The PE should support a default mode for 391 connections signalled without a specific encapsulation indicated. 392 Alternatively, the PE may select from among its supported 393 encapsulations based on local policies. It is expected that the 394 default will be to use a cell mode pseudo wire. 396 2.1.5 Quality of Service 398 Many of the ATM QoS guarantees can continue to be met through the PSN 399 core. This is possible with the use of traffic-engineered MPLS 400 DiffServ PSN tunnels [14]. This is discussed in more detail in [9] 401 section 9 and Appendix V. PNNI can use these mappings to advertise 402 the resources available for ATM connections on the PSN tunnel to the 403 attached ATM networks. The attached ATM networks will see these 404 resources as native ATM resources. Generalized Connection Admission 406 Control (GCAC) of PNNI running in the attached ATM networks can then 407 use these advertised resources as a part of the route selection 408 decision. 410 Note that the translation of ATM traffic parameters into bandwidth 411 parameters for utilization in the PSN needs to take into account the 412 overhead associated with the PW type. 414 2.2 Resiliency 416 The tunnelling of PNNI through the PSN means that either PSN-based 417 protection mechanisms may be used to provide resiliency, or 418 optionally PNNI-based mechanisms, or both. Failure detection timers 419 of each mechanism may need to be adjusted in order to allow one 420 mechanism priority over the other. 422 2.2.1 PSN-based Protection of the PSN Tunnel 424 The PSN tunnel can be protected from failures in the PSN using PSN 425 specific mechanisms, for example MPLS Fast Reroute [12]. Whichever 426 mechanism is chosen, the PSN tunnel needs to continue to support any 427 QoS guarantees given to the ATM connections following any restorative 428 action. 430 2.2.2 PNNI-based Protection of the Pseudo Wires 432 PNNI has its own mechanisms to provide resiliency in a native ATM 433 network. These same mechanisms can be used without modification to 434 provide protection for the ATM pseudo wires carried through the PSN. 435 Two examples are given below. 437 ACs PSN ACs 439 ATM ATM 440 PNNI +------+ PSN Tunnel +------+ PNNI 441 +-----+ | PE1 |==============| PE2 | +-----+ 442 | CE1 |-RCC------ ........PW.......... ----------| CE2 | 443 | |-SIG------ .................... ----------| | 444 | |\ | | | | /| | 445 | |\\ | VPWS | | VPWS | //| | 446 +-----+ \RCC | |==============| | // +-----+ 447 \\ +------+ | | // 448 SIG\\ +------+ PSN Tunnel | | // 449 \\ | PE3 |==============| | // 450 \\--- .................... ---// 451 \--- .................... ---/ 452 | |==============| | 453 +------+ +------+ 455 Figure 5: Dual Homing Example 457 Figure 5 shows an example of multi-homing of the ATM network into the 458 PSN cloud, using PNNI rerouting to protect against failures of PE1 or 459 the PSN tunnel. An additional PE, PE3. is shown in the network 460 above that is connected to the ATM network, together with an 461 additional PSN tunnel from PE3 to PE2. Both PSN tunnels are 462 configured as PNNI links, with associated RCCs and Signalling 463 Channels. If PSN tunnel PE1->PE2 fails, then PNNI can automatically 464 reroute all ATM connections on PSN tunnel PE1->PE2 to PSN tunnel 465 PE3->PE2. 467 ACs PSN ACs 469 ATM ATM 470 PNNI +------+ Tunnel +------+ PNNI 471 +-----+ | PE1 |==============| PE2 | +-----+ 472 | CE1 |-----------.........PW..........-------------| CE2 | 473 +-----+ | VPWS |==============| VPWS | +-----+ 474 | | | | 475 | |======| |=====| | 476 | |===== | | ====| | 477 +------+ || || +------+ 478 || || 479 +-------+ 480 | | 481 | PE3 | 482 | | 483 +-------+ 485 Figure 6: Multi-Hop ATM Routing 487 Figure 6 shows a third PE, PE3, attached to an additional ATM 488 network. PE3 is connected to PE1 and PE2 using PSN tunnels. All 489 three tunnels (PE1->PE2, PE1->PE3, PE3->PE2) can be configured as 490 PNNI links so that PNNI can automatically use the alternate path 491 formed by PSN tunnels PE1->PE3 and then PE3->PE2 if tunnel PE1->PE2 492 fails. PE3 simply acts as a transit ATM/PNNI node in this scenario. 494 2.3 Operations, Administration and Maintenance 496 ATM OAM is tunnelled through the PSN, as described in [4]. ATM OAM 497 is notified of PSN tunnel failures in the same way as it handles port 498 or virtual port failures in an ATM switched network. The mechanisms 499 for detecting tunnel failures depends on the PSN mechanisms used and 500 is outside the scope of this document. Fault management procedures 501 for ATM PWs are outside the scope of this document. 503 3. Security Considerations 505 Extended PNNI uses pseudo wires to transport ATM signalling and 506 routing across a PSN. The security of the transported ATM service 507 will only be as good as the security of the PSN. This level of 508 security might be less rigorous then a native ATM service. 510 4. IANA Considerations 512 This document has no IANA actions. 514 5. References 516 5.1 Normative References 518 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 519 Levels", RFC 2119, March 1997. 521 [2] Rosen, E., "Multiprotocol Label Switching Architecture", RFC 522 3031, January 2001. 524 [3] Bryant, S., "The PWE3 Architecture, 525 draft-ietf-pwe3-arch-07.txt", March 2004. 527 [4] Martini, L., "Encapsulation Methods for Transport of ATM 528 Cells/Frame Over IP and MPLS Networks, 529 draft-ietf-pwe3-atm-encap-07.txt", October 2004. 531 [5] ATM Forum Technical Committee, "ATM-MPLS Network Interworking 532 Signalling Specification, Version 1.0, AF-CS-0197.000", August 533 2003. 535 5.2 Informative References 537 [6] Awduche, D., "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 538 3209, December 2001. 540 [7] Andersson, L., "L2VPN Framework, 541 draft-ietf-l2vpn-l2-framework-05.txt", June 2004. 543 [8] Martini, L., "Pseudowire Setup and Maintenance using LDP, 544 draft-ietf-pwe3-control-protocol-11.txt", October 2004. 546 [9] ATM Forum Technical Committee, "ATM-MPLS Network Interworking, 547 Version 2.0, AF-AIC-0178.001", August 2003. 549 [10] ATM Forum Technical Committee, "Private Network-Network 550 Interface Specification, Version 1.1 (PNNI 1.1), 551 af-pnni-0055.002", April 2003. 553 [11] ATM Forum Technical Committee, "ATM Inter-Network Interface 554 Specification, Version 1.1 (ANNI 1.1), af-cs-0125.002", 555 September 2002. 557 [12] Pan, P., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels, 558 draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt", September 2004. 560 [13] ATM Forum Technical Committee, "ILMI (Integrated Link 561 Management Interface)", September 1996. 563 [14] Le Faucheur, F., "Multi-Protocol Label Switching (MPLS) Support 564 of Differentiated Services", RFC 3270, May 2002. 566 Authors' Addresses 568 Matthew Bocci (editor) 569 Alcatel 571 Phone: +44 20 8883 2782 572 EMail: matthew.bocci@alcatel.c 573 o.uk 575 Martin Jensen 576 Equipe Communications 578 Phone: +1 978 795 2140 579 EMail: martin@equipecom.com 581 Daniel Proch 582 Marconi Communications 584 Phone: +1 724 742 7746 585 EMail: daniel.proch@marconi.com 587 Jeff Sugimoto 588 Nortel Networks 590 Phone: +1 613 763 1392 591 EMail: sugimoto@nortelnetworks.com 593 Himanshu Shah 594 Ciena Corp. 596 Phone: +1 508 489 2196 597 EMail: hshah@ciena.com 599 Intellectual Property Statement 601 The IETF takes no position regarding the validity or scope of any 602 Intellectual Property Rights or other rights that might be claimed to 603 pertain to the implementation or use of the technology described in 604 this document or the extent to which any license under such rights 605 might or might not be available; nor does it represent that it has 606 made any independent effort to identify any such rights. Information 607 on the procedures with respect to rights in RFC documents can be 608 found in BCP 78 and BCP 79. 610 Copies of IPR disclosures made to the IETF Secretariat and any 611 assurances of licenses to be made available, or the result of an 612 attempt made to obtain a general license or permission for the use of 613 such proprietary rights by implementers or users of this 614 specification can be obtained from the IETF on-line IPR repository at 615 http://www.ietf.org/ipr. 617 The IETF invites any interested party to bring to its attention any 618 copyrights, patents or patent applications, or other proprietary 619 rights that may cover technology that may be required to implement 620 this standard. Please address the information to the IETF at 621 ietf-ipr@ietf.org. 623 Disclaimer of Validity 625 This document and the information contained herein are provided on an 626 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 627 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 628 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 629 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 630 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 631 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 633 Copyright Statement 635 Copyright (C) The Internet Society (2004). This document is subject 636 to the rights, licenses and restrictions contained in BCP 78, and 637 except as set forth therein, the authors retain all their rights. 639 Acknowledgment 641 Funding for the RFC Editor function is currently provided by the 642 Internet Society.