Network Working Group E.M. Spiegel Internet-Draft G. Swallow Expires: August 26, 2006 C. Metz S. Brim Cisco Systems February 22, 2006 AII Types for ATM and Frame Relay to MPLS Control Plane Interworking draft-spiegel-pwe3-aii-types-atm-fr-control-iw-01 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 August 26, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes work in progress in the MFA Forum on ATM and Frame Relay to MPLS Control Plane Interworking. Two specifications are being defined, one for client-server interworking (between two Spiegel, et al. Expires August 26, 2006 [Page 1] Internet-Draft AII Types for ATM/FR to MPLS CP IW February 2006 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 client-server 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 "Expert Review" 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 Client-Server Interworking . . . . . . . . . . . . . . . . 6 2.1.1 ATM/FR Control Channel . . . . . . . . . . . . . . . . 6 2.1.2 ATM/FR Client-Server 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 August 26, 2006 [Page 2] Internet-Draft AII Types for ATM/FR to MPLS CP IW February 2006 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 defining two specifications that describe 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: Client- Server" [MFA.atm-fr-mpls-control-cs], which defines client-server control plane interworking. The net result is an ability to dynamically establish switched connections between client network endpoints that cross an IP/MPLS network. 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" [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. In addition, the ATM Forum is specifying an alternative method for Spiegel, et al. Expires August 26, 2006 [Page 3] Internet-Draft AII Types for ATM/FR to MPLS CP IW February 2006 ATM to MPLS client-server control plane 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 August 26, 2006 [Page 4] Internet-Draft AII Types for ATM/FR to MPLS CP IW February 2006 2. New AII Types Both client-server interworking 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 August 26, 2006 [Page 5] Internet-Draft AII Types for ATM/FR to MPLS CP IW February 2006 AII Type Description Application ------------------------------------------ ---------------- ATM/FR Control Channel Client-Server IW ATM/FR Client-Server Interworking SVC/SPVC Client-Server 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 client-server interworking, the AII format is defined in [MFA.atm-fr-mpls-control-cs]. 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 Client-Server 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 August 26, 2006 [Page 6] Internet-Draft AII Types for ATM/FR to MPLS CP IW February 2006 plane and not forwarded out an egress interface. For both versions of client-server control plane interworking (defined by the MFA Forum in [MFA.atm-fr-mpls-control-cs] 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-cs], 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-cs] 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 Client-Server Interworking SVC/SPVC In order to dynamically establish client-server interworking data connections across the IP/MPLS network, 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-cs]. 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 client-server control plane 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 August 26, 2006 [Page 7] Internet-Draft AII Types for ATM/FR to MPLS CP IW February 2006 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-cs]. 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 August 26, 2006 [Page 8] Internet-Draft AII Types for ATM/FR to MPLS CP IW February 2006 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 Length AII Type Description -------- -------- ------------------------------------------ TBD 1 to TBD ATM/FR Control Channel TBD 3 to TBD ATM/FR Client-Server Interworking SVC/SPVC TBD TBD FR Port and Connection Identifier TBD TBD ATM Port and Connection Identifier Table 2: New AII Type Codepoints The new AII type codepoints are requested from the "Expert Review" range of the AII Type, described in [I-D.ietf-pwe3-iana-allocation]. Spiegel, et al. Expires August 26, 2006 [Page 9] Internet-Draft AII Types for ATM/FR to MPLS CP IW February 2006 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 specifications, 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 August 26, 2006 [Page 10] Internet-Draft AII Types for ATM/FR to MPLS CP IW February 2006 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., "Provisioning, Autodiscovery, and Signaling in L2VPNs", draft-ietf-l2vpn-signaling-06 (work in progress), September 2005. [I-D.ietf-pwe3-control-protocol] Martini, L., "Pseudowire Setup and Maintenance using the Label Distribution Protocol", draft-ietf-pwe3-control-protocol-17 (work in progress), June 2005. [I-D.ietf-pwe3-iana-allocation] Martini, L., "IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)", draft-ietf-pwe3-iana-allocation-15 (work in progress), November 2005. [MFA.atm-fr-mpls-control-cs] Metz, C., Brim, S., Spiegel, E., Busschbach, P., Cherukuri, R., and A. Malis, "ATM and Frame Relay to MPLS Control Plane Interworking: Client-Server", MFA Forum mpls2005.188.04 (work in progress), December 2005. [MFA.mpls-atm-spvc-iw] Swallow, G. and E. Spiegel, "Soft Permanent Virtual Circuit Interworking between MPLS Pseudowires and ATM", MFA Forum mpls2005.064.03 (work in progress), July 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. Spiegel, et al. Expires August 26, 2006 [Page 11] Internet-Draft AII Types for ATM/FR to MPLS CP IW February 2006 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 August 26, 2006 [Page 12] Internet-Draft AII Types for ATM/FR to MPLS CP IW February 2006 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 (2006). 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 August 26, 2006 [Page 13]