Network Working Group Prashant Vashisht Internet-Draft Flextronics Software Systems Expires: November 17, 2006 May 16, 2006 Issues in Migrating ISODE to X.25 draft-pvashisht-isode-x25-migration-issues-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. 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 November 17, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract ISODE (International Standard Organization Development Environment) is one of the most mature implementation of the ISO (International Standard Organization) protocol stack. The majority of the ISODE implementation work over TCP. This draft presents some of the possible issues that MAY arise while porting the ISODE protocol stack over X.25. pvashisht Expires November 17, 2006 [Page 1] Internet-Draft Issues in Migrating ISODE to X.25 May 2006 1. Introduction ISODE is an implementation of ISO protocol stacks. It implements the various ISO layer protocols, namely, Transport layer, Session layer, Presentation Layer and Application layer. The transport layer could run on various network layers but the most commonly used ones are TCP/IP (refer RFC 1006) and X.25. ISODE has primarily a very good support to run the protocol stack over TCP/IP. This has been facilitated by the fact that TCP/IP has a very wide acceptance and over the last few decades, it has become the de-facto standard. Though ISODE does provide the framework to support the X.25 as the underlying network layer but still it may require some level of effort to migrate to X.25 seamlessly. This draft addresses the issues that may arise when a vendor attempts to port the ISODE stack over X.25. 2. Motivation The figure below presents a brief overview of the ISODE protocol stack. +-+-+-+-+-+-+-+-+-+-+-+-+ | Application Layer | +-+-+-+-+-+-+-+-+-+-+-+-+ | Presentation Layer | +-+-+-+-+-+-+-+-+-+-+-+-+ | Session Layer | +-+-+-+-+-+-+-+-+-+-+-+-+ | Transport Layer | +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ | TCP/IP | | X.25 | +-+-+-+-+-+ +-+-+-+-+-+ Though TCP/IP based ISODE implementation are quite common but it may happen that a vendor might be required to provide a X.25 based ISODE implementation depending upon the requirement of the customer (who may be supporting a legacy X.25 network). Such a requirement would necessitate the need for porting the ISODE protocol stack over the X.25. pvashisht Expires November 21, 2006 [Page 2] Internet-Draft Issues in Migrating ISODE to X.25 May 2006 The ISODE designers were generous enough to provide a framework for facilitating the migration of ISODE over X.25 but still there could be issues in the porting, which are triggered by the implementation of the X.25 layer and the interface it exposes to the ISO transport layer. In this draft, we address several such issues and possible mechanism to resolve them. 3. Applicability The issues mentioned in this draft shall apply to more or less all the implementations of ISODE (version 8 or later), which need to be migrated from TCP/IP to X.25 The issues mentioned in successive sections shall be applicable to any network service provider or service implementer, who wants to provide support for X.25 layer under ISODE. 4. Migration Issues This section presents the various issues that may need to be addressed when porting ISODE from TCP/IP to ISODE. 4.1 Support from X.25 card driver TCP/IP is presently used in all kinds of networks and the support for the same is already present in majority of the operating systems. For X.25 the major source of support is from the X.25 driver for the X.25 card hardware. The way the X.25 card is programmed has a lot to do with the overall porting complexity. The kind of buffering mechanism used in the driver, the performance of the overall ISODE implementation could also be impacted. Similarly, the interface with the driver (polled or interrupt based) could also impact the overall functionality. The best way should be to benchmark the functionality based on individual requirements, taking into account the CPU load utilization, buffering constraints, and interrupt latency. pvashisht Expires November 17, 2006 [Page 3] Internet-Draft Issues in Migrating ISODE to X.25 May 2006 4.2 Socket abstraction layer The existing ISODE implementation relies heavily on the sockets. The socket descriptors are also used as session (or association) descriptors across various upper layers. Therefore, it makes sense to continue to exploit the existing mechanism to the maximum extent possible. This shall require implementation of an interface layer between the ISO transport layer and the X.25 network layer. This layer shall provide the socket abstraction to the ISO transport layer. Though some of the operating systems do provide the support for X.25 based sockets but the actual needs to be verified with respect to the support for the X.25 card that a vendor may be using. In either case, a socket based abstraction layer could solve a lot of overheard in the porting exercise. This shall provide additional benefit of the continual use of the "select" call, which works mainly with socket descriptors. Many of the ISODE based applications rely on the "select" call to multiplex among the various simultaneous connections ( also referred to as associations). Though the implementers are free to implement any other interface scheme but it may complicate the overall integration of the ISODE protocol stack with the underlying X.25 layers. 4.3 ISO Transport layer requirements There are various kinds of ISO transport layers available (ranging from TP0 to TP4), which differ in the number of transport layer facilities provided by them. The simplest one is TP0, which provides the basic transport layer functionality and segmentation and reassembly. For TCP/IP based ISODE implementation, it was quite easy to multiplex multiple ISO transport over a single TCP connection. But in case of X.25 based implementation, this shall require some tweaking at the ISO transport layer and also at the socket abstraction layer (section 4.2). pvashisht Expires November 17, 2006 [Page 4] Internet-Draft Issues in Migrating ISODE to X.25 May 2006 This is largely dictated by the requirement of the upper layer (e.g. an upper layer may want to establish multiple transport connections over a single X.25 virtual circuit for cost saving). Such a requirement would require modifications to the ISODE transport layer to provide support for the mapping of multiple transport layer connections to a single network connection (as required to support TP2). Similarly, other modifications may be required to the ISODE transport layer to support other features (e.g. Error recovery). 4.4 Implementation specific issues There could be some other issues (as outlined below), which have more to do with the specifics of the implementation rather than the protocol. Depending upon whether the ISODE protocol stack is used in a thread-safe environment or not, the implementer may be required to provide additional mechanism to ensure the thread safety of the ISODE protocol stack. The X.25 layer may be seamlessly integrated with ISODE (which is running in the user space) OR it may be possible that the X.25 card driver is a part of the operating system kernel. In the latter scenario, the implementer may have to implement mechanism for communication between the ISODE transport layer and the X.25 network layer. Unlike TCP, where the user could get the information about the disconnection of underlying network connection easily, it might be a bit challenging task to get such an information from the X.25 network layer asynchronously. Though, there may be implementations which could provide such a support but more often than not, such a mechanism might be required to be built upon the underlying X.25 layer. 4.5 Performance Issue The TCP/IP is mostly implemented in the operating system kernel and is known to operate on all kinds of media. Most common implementation seen these days start from 10/100 Base-T. Whereas, the X.25 is mostly used for slower networks and is present today mostly because of the legacy reasons. pvashisht Expires November 17, 2006 [Page 5] Internet-Draft Issues in Migrating ISODE to X.25 May 2006 Therefore, it shall not be wise to compare the performance of ISODE implementations over TCP/IP with that of ISODE implementation over X.25. Still, it is imperative to optimize the performance of a X.25 based ISODE implementation by taking support from the underlying hardware (e.g. increasing the number of buffers in the X.25 driver, tweaking the polling interval, maximizing the queue sizes etc.) 5.3. Security Considerations This memo raises no security issues. It is believed that any security mechanisms shall be implemented at the appropriate layer (as required). The transport layer as discussed in this memo doesn't provide any security mechanisms. 6. References [1] ISODE documentation manual. pvashisht Expires November 17, 2006 [Page 6] Internet-Draft Issues in Migrating ISODE to X.25 May 2006 Author's Address Prashant Vashisht Flextronics Software Systems Plot 31 Sector 18 Electronic City, Gurgaon, Haryana 122015 India. Phone: +91 124 234 6666 Email: prashant.vashisht@flextronicssoftware.com pvashisht Expires November 17, 2006 [Page 7] Internet-Draft Issues in Migrating ISODE to X.25 May 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. pvashisht Expires November 17, 2006 [Page 8]