Internet Draft D. Watkinson Document: draft-watkinson-l2vpn-pnni-psn-framework-01 M. Aissaoui Expires: January 2005 M. Bocci Alcatel July 2004 Framework for PNNI to PSN Interworking Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document defines the framework for interworking mechanisms between PNNI signaled ATM networks and the set of Public Switched Networks (PSN) supported by this working group. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Table of Contents..................................................1 1. Introduction....................................................2 1.1. Conventions used in this document.............................2 1.2. Objectives and Scope of the Document..........................2 2. ATM Signaled to PSN to ATM Signaled Networks....................3 3. ATM Signaled to PSN Networks....................................5 3.1. Signaling and Routing.........................................5 3.2. Data Format...................................................6 3.3. QoS...........................................................7 3.4. Resiliency....................................................8 Watkinson Expires January 2005 1 Framework for PNNI to PSN Interworking July 2004 3.5. OAM...........................................................9 3.6. Summary.......................................................9 4. Security Considerations.........................................9 5. References.....................................................10 6. Author's Addresses.............................................11 7. Intellectual Property Statement................................11 8. Full Copyright Statement.......................................11 1. Introduction 1.1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. 1.2. Objectives and Scope of the Document This document extends [L2VPN-FRMK] by including mechanisms for interworking with attachment circuits that are ATM SPVCs. Service providers are introducing new PSN based networks and are looking for a seamless way to extend the reach of existing FR/ATM services to new sites attached to this PSN network. One important capability which is used in the existing FR/ATM networks is ATM switched services. These are mainly SPVC services and to a lesser extent SVC services. SPVC services are critical in todayËs networks as they allow simplified provisioning of the FR/ATM services by configuring the endpoints only. They also allow online traffic engineering and a faster restoration in the case of a network failure. Finally, ATM SPVCs extend connectivity to non-ATM endpoints such as FR and Ethernet endpoint on an ATM switch. They are thus used in both network and service interworking deployment scenarios. It is therefore important to provide methods for interworking ATM switched services and PSN based services such as VPWS. There are two models that must be considered when ATM SPVCs are attachment circuits. The first model has both attachment circuits of the connection using the ATM signaling for connection establishment. The second model has only one of the attachment circuits of the connection using ATM signaling and the other attachment circuit using a different access technology (switched or permanent). It must be emphasized that both models are likely to exist within the same network. Some connections may be ATM signaling to ATM signaling. Other connections may be ATM signaling to a non-switched Watkinson Expires January 2005 2 Framework for PNNI to PSN Interworking July 2004 AC. There also will be standard VPWS services connecting two non- signaled ACËs together. There are no methods to signal port connections in ATM thus there is no intent to provide PW services for transporting an entire ATM port across the PSN using these services. These PW services should use standard VPWS services instead. This may include the tunneling of many VCËs including PNNI RCC and Signaling links within the same port pseudowire. There are no interactions between PNNI and the PSN in these networks, thus there are no protocol considerations. 2. ATM Signaled to PSN to ATM Signaled Networks ACs PSN ACs Signalled Tunnel Signalled ATM ATM +------+ +------+ +-----+ | PE1 |==============| PE2 | +-----+ | CE1 |-----------.........PW..........-------------| CE2 | +-----+ | VPWS | | VPWS | +-----+ | |==============| | +------+ +------+ Figure 1 The ACËs can be ATM UNIËs for the operation of SVC services over the network or any other AC type that has an interworking function with ATM. Examples include non-signaled ATM, Frame Relay and Ethernet. These are supported through SPVC services. The SVC services start and terminate on the CE devices. The signaling for the SPVC services start and terminate on the adjacent ATM switches to the CEËs. The intention is to provide service over a PSN without impacting the ATM signaling that occurs between the CE devices. PE1 and PE2 may have additional procedures and there may be changes to signaling between PE1 and PE2 but no other nodes are affected by these procedures. The three mechanisms that will be discussed are [PNNI-VPN] and Virtual Trunking which tunnel PNNI Routing and Signaling and the [DRAFT-METZ] which interworks both PNNI Routing and Signaling to PSN/PW Routing and Signaling protocols. The comparison of Virtual Trunking / [PNNI-VPN] and [DRAFT-METZ] will be left for a future version of this draft if it is felt to be necessary. See [PNNI-VPN] for more details of this solution. It is structured similarly to the framework described below in section 3. Virtual Trunking emulates an ATM port or VP carrying many connections using a PW. [PNNI-VPN] emulates a single ATM VP or ATM Watkinson Expires January 2005 3 Framework for PNNI to PSN Interworking July 2004 VC using a PW. They both use PNNI routing and signaling for each individual customer connection. The advantages of Virtual Trunking are: a) No changes are required to the PNNI protocol. b) No requirement to combine ATM and MPLS Control Planes on the same equipment. This can be a two-box solution. c) Only one PW is signalled instead of two PW for the PNNI RCC and Signaling channels. The advantages of [PNNI-VPN] are: a) Improved data efficiency when ATM 1:1 cell mode is used with [PNNI-VPN]. b) Improved QoS support. A single ATM connection has a given SLA. This is more easily mapped into the QoS capabilities that are provided with the PW label. With Virtual Trunking, a port carrying many connections will have a mix of QoS capabilities that will need to be emulated over the single PW. c) Improved traffic engineering using separate admission control of each customer connection on to an MPLS tunnel instead of the coarse control of the emulated ports. d) Less provisioning. The characteristics of each emulated ATM port or VP need to be configured including their bandwidths. e) Better failure recovery. A failure of a single PW will only affect one connection with [PNNI-VPN]. PNNI rerouting can quickly restore this individual connection. A single PW failure with Virtual Trunking will cause many PNNI connections to be rerouted. f) Unknown OAM treatment for Virtual Trunks. When a pseudowire fails, it is unknown how many VPIËs are being tunneled, thus how many F4 AIS cells are required to be generated. The choice of Virtual Trunking vs. [PNNI-VPN] will depend solely based on an evaluation of the advantages of each listed above as they both provide the same service. Watkinson Expires January 2005 4 Framework for PNNI to PSN Interworking July 2004 3. ATM Signaled to PSN Networks Non-signaled Attachment PSN Attachment Circuits tunnel Circuits Signalled + +-----+ ATM pseudo +-----+ | | wire | | | CE1 +---+ +---| CE2 | | | | +-----+ +-----+ +-----+ | | | +-----+ +---+---- | | P | | ----+---+ +-----+ |VPWS\|---|-----|---|/VPWS| | PE1 |===|=====|===| PE2 | +-----+ | /|---|-----|---|\ | +-----+ | | +---+---- | | | | ----|---+ | | | CE3 +---+ +-----+ +-----+ +-----+ +---+ CE4 | | | | | +-----+ +-----+ Figure 4 This network shows one side of the PSN as explained in the section above. Again, this can be PNNI, AINI, or UNI. The other side does not use ATM signaling. Any AC as defined in [L2VPN-FRMK] can be used in this network. The desire in this network scenario is to avoid any changes in the ATM signaling that occurs up to PE1 and to avoid any changes in the PSN signaling that occurs through the PSN up to PE2. There may be minor changes to the procedures on PE2. The only node affected by these procedures is PE1. There is no signaling between PE2 and CE2 or CE4. No configuration is needed on PE1 to perform the interworking. 3.1. Signaling and Routing There are two possible directions for single-sided call setup in these networks. The SPVC calls can start from CE1 or CE3 or the ATM switch CE1 or CE3 is attached to. The calls will be converted from ATM signaling to an appropriate pseudowire signaling. In these network situations, there is no point in communicating any of the ATM signaled parameters to PE2. PE2 may not even be able to handle or deal with these parameters. PE1 needs to interwork as many of the ATM parameters into equivalent pseudowire signaling. Some of the mechanisms to do this are discussed in [PWE3-SPVC-IW]. Alternatively, calls can start from PE2 as pseudowire signaling and be converted to ATM signaling. This suffers from some of the same drawbacks as encountered in [DRAFT-METZ]. The major one is the desire to signal ATM traffic parameters through the ATM network. The first of these mechanisms is more appropriate as the ATM signaling provides sufficient information to generate the pseudowire Watkinson Expires January 2005 5 Framework for PNNI to PSN Interworking July 2004 signaling but the pseudowire signaling is missing information that may be important to the ATM network operator such as the ATM traffic parameters. When the call setup direction is CE1 or CE3 (or from the ATM switch CE1 or CE3 is attached to) towards PE2, reachability needs to be communicated from the PSN to the ATM network. The easiest translation of addressing is using IPv4/IPv6 addresses in the PSN and ATM End System Addresses (AESA) embedded IPv4/IPv6 addresses within the ATM network [ATM-IP-ADDR]. PE1 needs to advertise all of the IPv4/IPv6 addresses of the other PE nodes into PNNI. One mechanism is to advertise them as exterior reachable addresses. Other mechanisms are for future study. When the call setup direction is from PE2, ATM reachability needs to be advertised into a PSN routing protocol. This would most likely be MP-BGP. Only SPVC services are supported. Note that SPVC services can be extended across the ATM UNI using the UNI signaling SPVC IE as defined in [ATM-UNI-41]. Due to the additional requirements placed on pseudowire signaling and the existing protocol support of advertising IP reachability into ATM, the best choice is signaling from CE1 or CE3 towards PE2 and the insertion of IP routes into PNNI. The initiation of signaling from PE2 and advertising of ATM reachability into MP-BGP will be left as a topic for future discussion. 3.2. Data Format It is possible to use many of the PW types for the transmission of the data through the PSN. For example, if it is known through the ATM signaled parameters that all traffic is RFC2684 Bridged, it is possible to use an Ethernet PW type. The following are the various endpoint interworking scenarios and the valid PW types to use. By default, the ATM-PSN gateway selects a ATM PW unless otherwise specified. a. ATM-ATM endpoints: Configure a ATM PW which uses any of the encaps in [draft-pwe3-atm- encap]. The ATM PW encapsulation type is negotiated between the ATM- PSN gateway and PE2 during the PW setup. b. ATM-FR endpoints: Two scenarios are possible. The first one is to configure a FR PW and perform FRF.8.1 [FRF.8.1] in ATM-PSN gateway. ATM-PSN gateway selects a FR PW type after inspecting TBD in the received ATM call setup message. Watkinson Expires January 2005 6 Framework for PNNI to PSN Interworking July 2004 The second one is to configure a ATM PW and perform FRF.8.1 in PE2. ATM Encapsulation type negotiated between the ATM-PSN gateway and PE2. ATM-PSN gateway can select the AAL5 PDU or SDU encapsulations after inspecting TBD in the received ATM setup message. c. FR-FR endpoints: Two scenarios are possible. The first one is to configure a FR PW and perform FRF.5 [FRF.5] in ATM-PSN gateway. The ATM-PSN gateway selects a FR PW type after inspecting TBD in the received ATM call setup message. The second one is to configure a ATM PW and perform FRF.5 in PE2. ATM Encapsulation type negotiated between the ATM-PSN gateway and PE2. ATM-PSN gateway can select the AAL5 PDU or SDU encapsulations after inspecting TBD in the received ATM setup message. d. (FR/ATM)-Ethernet endpoints: Three scenarios are possible. The ATM-PSN gateway selects the appropriate PW encapsulation type after inspecting TBD in the received ATM call setup message. The first one is to configure a IP PW for IP only connections. The second one is to configure an Ethernet PW for Ethernet only connections. The last one is to configure multiple parallel PWs [L2VPN-IW] or a multiprotocol PW [EXTENDED-PID] for the multiprotocol connection case. In many ATM signaled networks, there will not be the necessary parameters to determine the above interworking schemes without pre- configuration of all of the possible gateway nodes. The gateway node will be required to choose either the ATM N:1 VC Cell Mode with the cell concatenation that is supported. When PE2 does not support either of these PW Types, negotiation of the PW Type can take place. Procedures for this are TBD. OAM is a consideration as referred to below in section 3.6. 3.3. QoS The ATM traffic parameters can be converted into traffic parameters for use on the pseudowire. Specifically, admission control of the PW into the appropriate PSN tunnel in both the ATM-PSN gateway and PE2 requires the knowledge of the PW traffic descriptor. Appropriate translation needs to be defined to map ATM traffic parameters to [PWE3-CP-EXT] or other equivalent mechanisms to signal pseudowire QoS parameters. The overhead based on the PW type needs to taken into account. Watkinson Expires January 2005 7 Framework for PNNI to PSN Interworking July 2004 3.4. Resiliency 3.4.1. Dual-Homing of ATM Network to PSN Attachment PSN Attachment Circuits tunnel Circuits Signalled + +-----+ ATM pseudo +-----+ | | wire | | | CE1 +---+ +---| CE2 | | | | +-----+ +------+ +-----+ | | | +-----+ +---+---- | | P | | ----+---+ +-----+ |VPWS\|---|------|---|/VPWS| | PE1 |===|======|===| PE2 | +-----+ | /|---|------|---|\ | +-----+ | | +---+---- | |------|---| ----|---+ | | | CE3 +---+ +-----+ /|------|---| | +---+ CE4 | | | +-----+ //+------+ +-----+ | | +-----+ | |// +-----+ | |/ |VPWS | | PE3 | +-----+ Figure 5 Multiple PE nodes can exist between the PSN and the ATM network. Each of these PE nodes will advertise reachability to the AESA embedded IPv4/IPv6 addresses. In the ATM network, these addresses will be considered multi-homed addresses. When a tunnel from one PE node (e.g. PE1) to another (e.g. PE2) fails, the PE node should no longer advertise reachability. This will allow the alternate PE3 node to take over. Watkinson Expires January 2005 8 Framework for PNNI to PSN Interworking July 2004 3.4.2. Mutlihop Tunnel Routing over the PSN Attachment PSN Attachment Circuits tunnel Circuits Signalled + +-----+ ATM pseudo +-----+ | | wire | | | CE1 +---+ +---| CE2 | | | | +-----+ ---- +-----+ | | | +-----+ +---+---- | /PSN \ | ----+---+ +-----+ |VPWS\|---|------|---|/VPWS| | PE1 |===|======|===| PE2 | +-----+ | /|---|------|---|\ | +-----+ | | +---+---- |---|\ /|---| ----|---+ | | | CE3 +---+ | |---|\\ //|---| | +---+ CE4 | | | +-----+ ------ +-----+ | | +-----+ || || +-----+ +------+ | VPWS | | PE3 | +------+ Figure 6 In the absence of any direct tunnel to the desired PE node, the use of multiple hops as shown in Figure 6 is TBD. The use of splicing of pseudowires is discussed in [L2VPN-SIG] but only for use in Distributed VPLS. 3.5. OAM The handling of OAM depends on the type of endpoint interworking, as explained in [VPWS-IW-OAM]. 3.6. Summary The direction of call setup from ATM to PSN is the preferred model. Call setup from PSN to ATM will remain as future work item. 4. Security Considerations Additional security issues exist on top of those that are discussed in [L2VPN-FRMK]. There are security issues that apply to control access to the PSN by ATM SPVC users within the access network. PE1 may need access control procedures for ATM SPVC users when performing these procedures. Watkinson Expires January 2005 9 Framework for PNNI to PSN Interworking July 2004 5. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [DRAFT-METZ] Metz, C., ŸSwitched ATM L2VPN÷, draft-metz-switched- atm-l2vpn, June 2003. [L2TP] Townsley, W. M. et. al., ŸFrame-Relay Pseudo-Wire Extensions for L2TP÷, draft-ietf-l2tpext-pwe3-fr-02.txt, June 2003. [L2VPN-FRMK] Andersson, L. et. al., "L2VPN Framework", draft-ietf- l2vpn-l2-framework-03.txt, October 2003. [ATM-MPLS-v2] ATM Forum, ŸATM-MPLS Network Interworking, version 2.0÷, af-aic-0178.001, August 2003. [PNNI-VPN] Bocci, M. et. Al., ŸSignalling Interworking for ATM Pseudo Wires÷, draft-bocci-pnni-vpn-00.txt, February 2004. [PWE3-SPVC-IW] Swallow, G. et. al., ŸSoft Permanent Virtual Circuit Interworking between PWE3 and ATM÷, draft-swallow-pwe3-spvc-iw- 00.txt, October 2003. [ATM-UNI-41] ATM Forum, ŸATM User-Network Interface Signalling Specification, Version 4.1÷, af-sig-0061.002, April 2002. [L2VPN-IW] Sajassi, A., et al., ŸL2VPN Interworking÷, draft- sajassi-l2vpn-interworking-01.txt, March 2003. [EXTENDED-PID] Aissaoui, M., et al., ŸExtended MPLS/PW PID÷, draft- aissaoui-extended-pid-01.txt, October 2003. [PWE3-CP-EXT] Shah, M. et. al., ŸDynamic Parameters Signaling for MPLS-based Pseudowires÷, draft-shah-pwe3-control-protocol- extension-01.txt, June 2003. [L2VPN-SIG] Rosen, E. et. al., ŸProvisioning Models and Endpoint Identifiers in L2VPN Signaling÷, draft-rosen-ppvpn-l2-signaling- 03.txt, May 2003. [FRF.8.1] Frame Relay Forum, ŸFrame Relay / ATM PVC Service Interworking Implementation Agreement÷, FRF.8.1, February 2000. [FRF.5] Frame Relay Forum, ŸFRF Frame Relay/ATM PVC Network Interworking Implementation Agreement÷, FRF.5, December 1994. [PWE3-CONTROL] Martini, L., et al., ŸPseudowire Setup and Maintenance using LDP÷, draft-ietf-pwe3-control-protocol-04.txt, October 2003. [VPWS-IW-OAM] Aissaoui, M., et al., "OAM Procedures for VPWS Interworking÷, draft-aissaoui-l2vpn-vpws-iw-oam-00.txt, February 2004. Watkinson Expires January 2005 10 Framework for PNNI to PSN Interworking July 2004 6. Author's Addresses David Watkinson Alcatel Phone: +1 613 7846847 Email: david.watkinson@alcatel.com Mustapha Aissaoui Alcatel Phone: +1 613 7846912 Email: mustapha.aissaoui@alcatel.com Matthew Bocci Alcatel Phone: +44 20 8883 2782 Email: matthew.bocci@alcatel.co.uk 7. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 8. Full Copyright Statement "Copyright (C) The Internet Society (2004). Except as set forth below, authors retain all their rights. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this Watkinson Expires January 2005 11 Framework for PNNI to PSN Interworking July 2004 document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for rights in submissions defined in the IETF Standards Process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Watkinson Expires January 2005 12