Network Working Group E.M. Spiegel Internet-Draft G. Swallow Expires: December 16, 2005 C. Metz S. Brim Cisco Systems June 14, 2005 AII Types for ATM and Frame Relay to MPLS Control Plane Interworking draft-spiegel-pwe3-aii-types-atm-fr-control-iw-00 Status of this Memo 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. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. 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. This Internet-Draft will expire on December 16, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes work in progress in the MFA Forum on ATM and Frame Relay to MPLS Control Plane Interworking. Two implementation agreements are being defined, one for network interworking (between Spiegel, et al. Expires December 16, 2005 [Page 1] Internet-Draft AII Types for ATM/FR to MPLS CP IW June 2005 two client network endpoints that communicate across an IP/MPLS network) and one for SPVC interworking (from a client network endpoint to an IP/MPLS network endpoint). Both network interworking and SPVC Interworking use standard PWE3 control for establishment of the pseudowires that transport the ATM or Frame Relay data connections across the IP/MPLS network. New AII type codepoints from the "First Come First Served" range are requested. The need for these codepoints and proposed usage is described. Table of Contents 1. ATM and Frame Relay to MPLS Control Plane Interworking Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. New AII Types . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Network Interworking . . . . . . . . . . . . . . . . . . . 6 2.1.1 ATM/FR Control Channel . . . . . . . . . . . . . . . . 6 2.1.2 ATM/FR Network Interworking SVC/SPVC . . . . . . . . . 7 2.2 SPVC Interworking . . . . . . . . . . . . . . . . . . . . 8 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1 Normative References . . . . . . . . . . . . . . . . . . . 11 5.2 Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . 13 Spiegel, et al. Expires December 16, 2005 [Page 2] Internet-Draft AII Types for ATM/FR to MPLS CP IW June 2005 1. ATM and Frame Relay to MPLS Control Plane Interworking Motivation Many service providers derive significant revenues by offering and delivering VC-based services across dedicated Frame Relay and ATM networks. In a desire to reduce capital and operational expenditures many of these same providers have embarked upon a strategy of convergence where many per-service networks (including Frame Relay and ATM) and their attendant technologies and services are migrated to a single IP/MPLS packet switched network (PSN). Native Frame Relay and ATM networks employ dynamic signaling and routing protocols to expedite connection setup and recovery. PNNI is an example of one such protocol used to dynamically setup switched ATM connections across a native ATM network [ATMF.pnni1.1]. Pseudo-wire (PW) technology enables tunneling of ATM and FR connections through an IP/MPLS network. When transitioning to the IP/MPLS network, service providers will expect ATM (and Frame Relay) signaling and routing protocols (e.g. PNNI) to interwork with PW signaling and IP routing protocols for the purpose of establishing connections across the IP/MPLS network. This will allow the service providers to maintain the provisioning and resiliency models they are accustomed to for these VC-based services. The MFA Forum is specifying two implementation agreements that define methods by which the control plane functions of a client (i.e. ATM, Frame Relay) network can be interworked with corresponding IP/MPLS control plane functions: o "ATM and Frame Relay to MPLS Control Plane Interworking" [MFA.atm- fr-mpls-control-niw], which defines control plane network interworking. The net result is an ability to dynamically establish switched connections between client network endpoints that cross an IP/MPLS network. In the integrated case, the Label Edge Routers (LERs) run both the client (ATM or FR) control plane and the pseudowire control plane, with each client virtual connection mapped to a single pseudowire that is established on demand. o "Soft Permanent Virtual Circuit Interworking between MPLS Pseudowires and ATM: Unmapped Mode" [MFA.mpls-atm-spvc-iw], which specifies mechanisms to dynamically establish connections from a client network endpoint to an IP/MPLS network endpoint. This preserves the essential reasons for using SPVCs, namely, keeping configuration limited to the edge nodes supporting a particular connection and allowing the network to be able to recover in the event of the failure of any facility between those two edge nodes. A generalized architecture is defined in "Service Mediation Spiegel, et al. Expires December 16, 2005 [Page 3] Internet-Draft AII Types for ATM/FR to MPLS CP IW June 2005 between Layer-2 and MPLS Networks Architecture" [MFA.l2-service- mediation], which refers to this type of interworking as "service mediation" rather than "SPVC interworking". In addition, the ATM Forum is specifying an alternative method for ATM to MPLS control plane network interworking in "ATM-MPLS Network Interworking Signalling Specification Version 1.0" [ATMF.mpls-niw- sig1.0] and "ATM-MPLS Control Plane Network Interworking" [ATMF.mpls- control-niw]. Spiegel, et al. Expires December 16, 2005 [Page 4] Internet-Draft AII Types for ATM/FR to MPLS CP IW June 2005 2. New AII Types Both network interworking (integrated case) and SPVC Interworking use PWE3 control [I-D.ietf-pwe3-control-protocol] for establishment of the pseudowires that transport the ATM or Frame Relay data connections across the IP/MPLS network. Establishment of the pseudowire is triggered dynamically when an ATM or Frame Relay control plane message is received at a Label Edge Router (LER). This precludes the possibility of per pseudowire provisioning at the LER that initiates establishment of the pseudowire. In particular, it is not possible to use preconfigured PW IDs. It is also not possible to dynamically select 32-bit PW IDs that are always distinct from the 32-bit PW IDs manually provisioned for other pseudowires between the same two LERs. The possibility of call collision would arise if the PW ID value dynamically selected by this LER has already been manually provisioned for a different pseudowire on the other LER, but has not yet been provisioned at this LER. For these reasons, the Generalized PW ID FEC element is used. As described in [I-D.ietf-pwe3-control-protocol], the Generalized PW ID FEC element uses attachment identifier formats that are application specific: The details of how to construct the AGI and AII fields identifying the pseudowire endpoints are outside the scope of this specification. Different pseudowire application, and different provisioning models, will require different sorts of AGI and AII fields. The specification of each such application and/or model must include the rules for constructing the AGI and AII fields. For ATM and Frame Relay to MPLS control plane interworking, the information to be carried in the PWE3 signaling messages must be derived from the information received in the client control messages, along with per interface, per system, or per network information known to the LER. The TAII that identifies the target pseudowire endpoint must be constructed from information present in the client control messages such as call references, connection identifiers, and called party addresses. This draft documents the request for four new AII type codepoints for ATM and Frame Relay to MPLS control plane interworking, as described in Table 1. Spiegel, et al. Expires December 16, 2005 [Page 5] Internet-Draft AII Types for ATM/FR to MPLS CP IW June 2005 AII Type Description Application ------------------------------------ ----------- ATM/FR Control Channel Network IW ATM/FR Network Interworking SVC/SPVC Network IW FR Port and Connection Identifier SPVC IW ATM Port and Connection Identifier SPVC IW Table 1: New AII Types And Their Applications When the application is network interworking, the AII format is defined in [MFA.atm-fr-mpls-control-niw]. The ATM/FR Control Channel format is also defined in [ATMF.mpls-control-niw]. When the application is SPVC interworking, the AII format is defined in [MFA.mpls-atm-spvc-iw]. The following subsections motivate the need for each of the new AII types, and describe how the new AII formats will be used. No restrictions are defined on the contents of the AGI. The AGI can be used in the same manner as for other pseudowires as described in [I-D.ietf-l2vpn-signaling], such as a "VPN Identifier". 2.1 Network Interworking 2.1.1 ATM/FR Control Channel The support of dynamic client (ATM or Frame Relay) connections across an intermediate IP or MPLS network requires the transport of client signaling messages and, depending on the configuration, client routing and link management messages between the LERs. Some client layer protocols (i.e. ATM) employ reserved native client encapsulation headers (i.e. ATM uses VPI/VCI values) to identify connections associated with various protocols or functions. These values may have a per-interface context which means that a native client node can receive the same client encap header from other native client nodes with the understanding that {client encap header, interface} provides a combination that uniquely identifies the sender. MPLS PWs on the other hand usually use a per-platform label range. Before client control messages can be carried across a PSN tunnel, the LER at each end of the PSN tunnel must be made aware of the labels that will carry the control channel traffic for that instance of the client control plane between the LERs. These client control channels must be identified so that the data on the corresponding control PW is delivered to the correct instance of the client control Spiegel, et al. Expires December 16, 2005 [Page 6] Internet-Draft AII Types for ATM/FR to MPLS CP IW June 2005 plane and not forwarded out an egress interface. For both versions of control plane network interworking (defined by the MFA Forum in [MFA.atm-fr-mpls-control-niw] and by the ATM Forum in [ATMF.mpls-control-niw]), the native client control channel to PW label bindings are distributed using PWE3 control as defined in [I-D.ietf-pwe3-control-protocol]. To remain consistent with the signaling procedures for the establishment of data-bearing PWs [MFA.atm-fr-mpls-control-niw], LDP signaling of control PWs employs the Generalized ID FEC element. A new AII type codepoint is required to identify this PW as an ATM or Frame Relay control channel. The AII format for ATM and Frame Relay control channels consists of a Control Channel Type field, defined by the MFA Forum in [MFA.atm-fr- mpls-control-niw] and the ATM Forum in [ATMF.mpls-control-niw], and a Control Plane Instance Identifier (CPII) that is used to distinguish between multiple client control plane instances running between the same two LERs, in the same group (in which case pseudowires established in response to those client control plane instances would use the same AGI value in the pseudowire control plane). This is due to the possibility of multiple different control planes being used between the two LERs, e.g. ATM and Frame Relay, or due to multiple instances of the same client control plane being used between the two LERs. 2.1.2 ATM/FR Network Interworking SVC/SPVC In order to dynamically establish network interworking data connections across the IP/MPLS network, in the integrated case both the client (ATM or Frame Relay) and pseudowire control planes run between the LERs at the edges of the IP/MPLS network [MFA.atm-fr- mpls-control-niw]. Mechanisms must be defined so that an LER can correlate an incoming PW Label Mapping message with an ATM or Frame Relay attachment circuit created in response to client control plane messages. In ATM and Frame Relay to MPLS control plane network interworking, the attachment circuits on both ends of the IP/MPLS network are created dynamically in response to client control plane messages. This precludes the possibility of using preconfigured identifiers as the common handles for correlation between the client control plane and the pseudowire control plane. This suggests that the AII should be used to carry the information correlating the client control plane and the pseudowire control plane. The AIIs can be based on information learned from the client control plane messages that trigger creation of the attachment circuits. This has the advantage that no additions need be specified Spiegel, et al. Expires December 16, 2005 [Page 7] Internet-Draft AII Types for ATM/FR to MPLS CP IW June 2005 to PWE3 control or the client control protocols. Instead, only the structure of the AIIs used in PWE3 control needs to be specified for this application. The most obvious choice is to base the AII format on the identifiers used in the client control plane to identify the calls/connections that client control plane messages are associated with. Specifically, a new AII format is defined based on the call reference value and the call reference flag used in the client (ATM or Frame Relay) control plane between the LERs, along with the same Control Plane Instance Identifier (CPII) mentioned in section 2.1.1 above for the control channels [MFA.atm-fr-mpls-control-niw]. 2.2 SPVC Interworking For ATM and Frame Relay SPVCs, the called party address identifies both the target node and port, and the target connection identifiers (VPI/VCI or DLCI) are carried as literals in the Called party SPVC information element. In pseudowire control plane signaling, an IP address identifies the target node, and the (T)AI identifies the attachment circuit within the context of the target node. For ATM and Frame Relay to MPLS SPVC Interworking, methods of translating between the target port (identified by all or part of the called party address) and connection identifiers (VPI/VCI or DLCI) into a TAI are being defined. An AII format which indicates that it was derived from such a translation is needed. Two new AII formats are proposed, one each for ATM and Frame Relay [MFA.mpls-atm-spvc-iw]. The AIIs are composed of port identifiers concatenated with the connection identifiers (VPI/VCI for ATM attachment circuits and DLCI for Frame Relay attachment circuits). This allows for a straightforward mapping from the client (ATM or FR) control plane information for identifying the SPVC target to the TAIs that identify the target in the pseudowire control plane. The names proposed for these two new AII type codepoints are 'FR port and connection identifier' and 'ATM port and connection identifier'. These names do not specifically refer to SPVC interworking, since the format will be general enough that it could be reused for other applications. Spiegel, et al. Expires December 16, 2005 [Page 8] Internet-Draft AII Types for ATM/FR to MPLS CP IW June 2005 3. IANA Considerations Four new AII type codepoints are requested for ATM and Frame Relay to MPLS control plane interworking, as described in Table 2. AII Type Codepoint AII Type Description ------------------ ------------------------------------ TBD ATM/FR Control Channel TBD ATM/FR Network Interworking SVC/SPVC TBD FR Port and Connection Identifier TBD ATM Port and Connection Identifier Table 2: New AII Type Codepoints The new AII type codepoints are requested from the "First Come First Served" range of the AII Type, described in [I-D.ietf-pwe3-iana- allocation]. Spiegel, et al. Expires December 16, 2005 [Page 9] Internet-Draft AII Types for ATM/FR to MPLS CP IW June 2005 4. Acknowledgements The authors would like to thank the many members of the MFA Forum that have assisted with this draft directly or indirectly through contributions to the referenced implementation agreements, including David Sinicrope, Rao Cherukuri, Peter Busschbach, Tom Walsh, Nikhil Shah, Andy Malis, John Kenney, Hamid Ould-Brahim, Elizabeth Hache, Jeffrey Sugimoto, Daniel Proch, and Matthew Bocci. Spiegel, et al. Expires December 16, 2005 [Page 10] Internet-Draft AII Types for ATM/FR to MPLS CP IW June 2005 5. References 5.1 Normative References [ATMF.mpls-control-niw] "ATM-MPLS Control Plane Network Interworking", ATM Forum fb-aic-0206.000 (work in progress), May 2005. [I-D.ietf-l2vpn-signaling] Rosen, E. and V. Radoaca, "Provisioning Models and Endpoint Identifiers in L2VPN Signaling", draft-ietf-l2vpn-signaling-03 (work in progress), February 2005. [I-D.ietf-pwe3-control-protocol] Martini, L., "Pseudowire Setup and Maintenance using LDP", draft-ietf-pwe3-control-protocol-16 (work in progress), March 2005. [I-D.ietf-pwe3-iana-allocation] Martini, L. and M. Townsley, "IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)", draft-ietf-pwe3-iana-allocation-09 (work in progress), April 2005. [MFA.atm-fr-mpls-control-niw] Metz, C., Brim, S., Spiegel, E., Busschbach, P., Cherukuri, R., and A. Malis, "ATM and Frame Relay to MPLS Control Plane Interworking", MFA Forum mpls2005.053.02 (work in progress), July 2005. [MFA.mpls-atm-spvc-iw] Swallow, G. and E. Spiegel, "Soft Permanent Virtual Circuit Interworking between MPLS Pseudowires and ATM: Unmapped Mode", MFA Forum mpls2005.064.00 (work in progress), April 2005. 5.2 Informative References [ATMF.mpls-niw-sig1.0] "ATM-MPLS Network Interworking Signalling Specification Version 1.0", ATM Forum af-cs-0197.000, August 2003. [ATMF.pnni1.1] "Private Network-Network Interface Specification Version 1.1 (PNNI 1.1)", ATM Forum af-pnni-0055.002, April 2002. [MFA.l2-service-mediation] Spiegel, et al. Expires December 16, 2005 [Page 11] Internet-Draft AII Types for ATM/FR to MPLS CP IW June 2005 Ould-Brahim, H., Sugimoto, J., Hache, E., Wright, G., Busschbach, P., and H. Shah, "Service Mediation between Layer-2 and MPLS Networks Architecture", MFA Forum mpls2005.061.00 (work in progress), April 2005. Authors' Addresses E. Mickey Spiegel Cisco Systems 170 W. Tasman Drive San Jose, California 95134 USA Phone: +1 408 526 6408 Email: mspiegel@cisco.com George Swallow Cisco Systems 1414 Massachusetts Avenue Boxborough, Massachusetts 01719 USA Email: swallow@cisco.com Chris Metz Cisco Systems 170 W. Tasman Drive San Jose, California 95134 USA Email: chmetz@cisco.com Scott Brim Cisco Systems 146 Honness Lane Ithaca, New York 14850 USA Email: sbrim@cisco.com Spiegel, et al. Expires December 16, 2005 [Page 12] Internet-Draft AII Types for ATM/FR to MPLS CP IW June 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Spiegel, et al. Expires December 16, 2005 [Page 13]