Internet Engineering Task Force Arifumi Matsumoto INTERNET DRAFT Kenji Fujikawa Yasuo Okabe Kyoto University 23 June 2003 Basic Socket API Extensions for LIN6 End-to-End Multihoming Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 describes a method for multihoming support in application layer. We extend the basic socket API(Application Programming Interface) and propose some new interfaces for multihoming. Multihoming nodes are expected to have multiple addresses. The existing socket APIs, however, are not designed to manipulate multiple addresses in a connection. Proposed APIs help an application to handle multiple addresses, to avoid connection failure and to do load-balancing possibly. Right now, the proposed APIs are for LIN6 nodes, one of the mobile protocols. This is because LIN6's addressing architecture, which is called "8+8", is very friendly and consistent with multihoming. In this document, we propose a host- based multihoming solution and which is called end-to-end multihoming. In end-to-end multihoming, a fault-tolerant connection Arifumi Expires 23 December 2003 [Page 1] draft-arifumi-lin6-multihome-api-00.txt 23 June 2003 can be achieved relying not on routers but on the pair of end-nodes only. 1. Introduction This document describes a method of host-based multihoming, which is implemented in the application layer. We extend the basic socket interface for IPv6[RFC2553] and propose some new interfaces for multihoming. Multihoming nodes are expected to have multiple addresses. The existing socket APIs, however, are not designed to manipulate multiple addresses in a connection. Proposed APIs make multiple addresses visible to an application and help an application to handle multiple addresses, to avoid connection failure and to do load-balancing possibly. Right now, the proposed APIs are for LIN6 nodes only. LIN6(Location Independent Network Architectur for IPv6)[LIN6], which is developed by M. Ishiyama, M. Kunishi and F. Teraoka, is one of the mobile network protocols. LIN6 is more efficient and simpler than other existing mobile network protocols are and this is mainly because of its addressing architecture. In LIN6 an IPv6 address is divided into two parts, ``locator'' and ``identifier,'' and DNS and ``Mapping Agents'' are used for the mapping of an identifier and its locators. This LIN6's addressing architecture is called "8+8", and is very friendly and consistent with multihoming. In this document, we propose a host-based multihoming solution, which is called end-to-end multihoming[E2E], combined with LIN6 mobile protocol. In end-to-end multihoming, a fault-tolerant connection can be achieved relying not on routers but on the pair of end-nodes only. On a LIN6 node, an existing application can be executed without any modifications to the application itself. Even if a node is multihomed and has multiple addresses, however, existing applications don't benefit from having multiple up-stream access lines. With our APIs, you can make an application that actively make use of multihoming. Although our APIs are such capable and easy to use, it is nonsense to remake all the existing applications in order to deploy multihoming. In case of TCP, the detection and avoidance of connection failure can be implemented in the transport layer by ack packet's timeout and so on. In case of UDP, however, it is nealy impossible to do the same in the transport layer. Those processes have to be done in the application layer. Thus, our APIs are mainly suitable for making multihome-ready UDP applications. Now we are planning to implement improved TCP for end-to-end multihoming. This memo describes LIN6 protocol overview, our C language APIs Arifumi Expires 23 December 2003 [Page 2] draft-arifumi-lin6-multihome-api-00.txt 23 June 2003 specification, an example of how to use the API in order to write an multihoming-capable applications and some notes on the deployment of this multihoming method. 2. LIN6 Protocol Overview In conventional network architectures including IPv4 and IPv6, the network address of a node denotes both its identity and its location. In LIN6 architecture, we divide a 128bit-long IPv6 address into two parts. The first half is called ``locator'' and the second half ``identifier''. A locator only depicts a location and an identifier only depicts an identity. A LIN6 node can identify a corresponding node by examining only the second half of an IP address. This is independent of the first half, which may be changed when the node moves. The separation of an IP address also makes it possible to support multihoming without any inconsistency. A LIN6 node located in the multihomed network has multiple global locators. Even if an network trouble occurred on one link, a corresponding LIN6 node detects it and can resume communication by using another locator and another link. In this method, a fault-tolerant connection is achieved relying only on the pair of end-nodes, not on routers. We call this method ``end-to-end multihoming.'' 3. Multihoming Support for LIN6 When a LIN6 node moves and detects its movement (changing of its locator), the node sends a location update message packet to its corresponding nodes and can continue to communicate seamlessly. On the other hand, when a network trouble occurred between two nodes, the connection will be lost, even if one or both nodes are multihomed. In such a case, a node is expected to detect network troubles by some error packets such as ICMP Host Unreach or by acknowledgement timeout. By changing destination or source locator, the traffic possibly circumvents the point of failure and hopefully the connection can be resumed. Especially when a node is located under those sites whose site exit routers perform policy routing based on the outgoing packet's source address, changing the source locate is more meaningful. In the LIN6 addressing architecture, a host is identified by only the latter half of its address, thus a connection is identified by only the latter half of the source address and the destination addresse. Therefore a LIN6 node can change a destination locator and a source locator even when a connection is established. Arifumi Expires 23 December 2003 [Page 3] draft-arifumi-lin6-multihome-api-00.txt 23 June 2003 These processes of detecting errors and changing locators is expected to be implemented in an application or in the transport layer. The existing socket APIs, however, are not designed to manipulate multiple addresses in a connection. Thus, we design new APIs to write an multihome-ready application. Proposed APIs make multiple addresses visible to an application and help an application to handle multiple addresses, to avoid connection failure and to do load- balancing possibly. Note that on a LIN6 node, an existing application can be executed without any modifications to the application itself. Even if a node is multihomed and has multiple addresses, however, existing applications don't benefit from having multiple up-stream access lines. With our APIs, you can make an application that actively make use of multihoming. 3.1. API Overview The main newly designed APIs are listed below. o socket() We define a new address family "AF_ALIN6" and a new protocol family "PF_ALIN6". If you specify "PF_ALIN6" for socket()'s protocol family, you will get multihome-ready socket and you can manipulate foreign and local locators through the socket. PF_ALIN6 socket is available for IPPROTO_TCP and IPPROTO_UDP. o getaddrinfo2() This API returns locators of a specified corresponding node by making a query to the node's Mapping Agent. This is an extented form of the exisiting socket library function getaddrinfo(). Getaddrinfo2() performs the functionality of getaddrinfo(), name- to-address translation, and also aquires an identifier-to-locators mapping if the latter half of the IPv6 address is an LIN6 identifier. The return value is not a linked list of struct addrinfo, but a linked list of struct addrinfo2, described below, which includes target node's locators. struct addrinfo2 { int ai_flags; /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST */ int ai_family; /* PF_XXX */ int ai_socktype; /* SOCK_XXX */ struct sockaddr *ai_addr; /* binary address */ ... size_t ai_ntloc; /* number of target locator */ struct lin6_prefix* ai_tloc; /* target locators */ }; Arifumi Expires 23 December 2003 [Page 4] draft-arifumi-lin6-multihome-api-00.txt 23 June 2003 ai_tloc is the pointer to the first entry of the locator array. ai_ntloc is the number of entries in the array. o getsockopt()/setsockopt() We define new options for getsockopt() and setsockopt(). These socket APIs are used for get and set options on sockets. We introduce new options LIN6_LOCALADDROPTS, LIN6_FOREIGNADDROPTS, LIN6_LOCALLOCATOR and LIN6_FOREIGNLOCATOR to manipulate socket behavior and to get/set the locator of the protocol control block(PCB) in the kernel. When a connection error is detected an application can try another locator by using the setsockopt() with the option LIN6_FOREIGNLOCATOR and an new locator of the target host. Next, we show the programming example below. 3.2. Simple Example. 3.2.1 Establishment of an Connection After getting corresponder's locators by getaddrinfo2(), this example applicaton below tries to connect to an acquired address. Getaddrinfo2() returns a pointer to a linked list of struct addrinfo2. If the address family specified in the returned struct addrinfo2 is AF_ALIN6, there may be multiple locators in it. This application tries to connect to the corresponding node using each locator until connection establishment succeeds. struct addrinfo2 hints, *res, *res0; struct sockaddr_lin6 slin6; int error, sock; int ntloc; /* name to address resolution */ memset(&hints, 0, sizeof(hints)); hints.ai_family = PF_UNSPEC; hints.ai_socktype = SOCK_STREAM; error = getaddrinfo2("mob.foo","http", &hints,&res0); if (error) { errx(1, "%s", gai_strerror(error)); /*NOTREACHED*/ } /* look for valid address */ sock = -1; for(res = res0; res; res = res->ai_next) { sock = socket(res->ai_family, res->ai_socktype, Arifumi Expires 23 December 2003 [Page 5] draft-arifumi-lin6-multihome-api-00.txt 23 June 2003 res->ai_protocol); if (sock < 0) continue; if (res->ai_family==AF_ALIN6) { memcpy(&slin6, res->ai_addr, sizeof(slin6)); ntloc = ai_ntloc; for(i=0;iai_ntloc;i++) { /* try each target locator */ bcopy(res->ai_tloc[i], slin6.slin6_locator, sizeof(struct locator)); if (connect(sock, (struct sockaddr*)&slin6, res->ai_addrlen)==0) goto connected: } sock = -1; } else { ntloc = 0; if (connect(sock,res->ai_addr, res->ai_addrlen) < 0) { close(sock); sock = -1; } break; } } if (sock < 0) err(1); freeaddrinfo(res0); connected: freeaddrinfo2(res0); } 3.2.2 Connection Recovery After the connection establishment this application may catch some error signals caused by ICMP Error Message. This application tries another locator acquired before if available and tries to continue connection. void sig_handler(int sig) { /* error signal handler */ if (ntloc>0) { /* change locator */ if (setsockopt(sock, IPPROTO_IPV6, LIN6_FOREIGNLOCATOR, ai_tloc[++i], sizeof(struct lin6_prefix)) < 0) { ... Arifumi Expires 23 December 2003 [Page 6] draft-arifumi-lin6-multihome-api-00.txt 23 June 2003 } } } 4. Deployment Considerations Although our APIs are such capable and easy to use, it is nonsense to propose to remake all the existing applications in order to deploy multihoming. In case of TCP, the detection and avoidance of connection failure can be achieved in the transport layer by ack packet's timeout and so on. In case of UDP, however, it is nealy impossible to do the same in the transport layer. Those processes have to be done in the application layer. Thus, our APIs are mainly suitable for making multihome-ready UDP applications. We have already implemented this multihoming method for UDP. Now we are planning to implement reliable transport protocol for end-to-end multihoming. This can be a modification to the existing transport protocol TCP or adoption of a brand new transport protocol, such as SCTP[RFC2960]. 5. Acknowledgement Thanks to the many people who made suggestions and provided feedback to this document, including: Fumio Teraoka, Masahiro Ishiyama, Masataka Ohta, Mitsunobu Kunishi and members and staffs in okabe laboratory and minoh laboratory. 6. References [LIN6] M. Ishiyama, M. Kunishi, K. Uehara, H.Esaki, F. Teraoka, ``LINA: A New Approach to Mobility Support in Wide Area Networks,'' IEICE Trans. Communications, Vol E84-B, No 8, Aug 2001, pp.2076-2086. [E2E] M. Ohta, ``The Architecture of End to End Multihoming,'' Internet-draft, IETF (Nov 2002), draft-ohta-e2e-multihoming-03.txt. [RFC2553] R. Gilligan, S. Thomson, J. Bound, W. Stevens, ``Basic Socket Interface Extensions for IPv6 ,'' RFC2553, IETF (Mar 1999). [RFC2960] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxson, ``Stream Control Transmission Protocol,`` RFC2960, IETF (Oct 2000). Arifumi Expires 23 December 2003 [Page 7] draft-arifumi-lin6-multihome-api-00.txt 23 June 2003 7. Authors' Addresses Arifumi Matsumoto Graduate School of Informatics Kyoto University Yoshida-Honmachi, Sakyo-ku, Kyoto 606-8501 JAPAN Tel: +81 75-753-7468 Fax: +81 75-753-7472 Email: arifumi@net.ist.i.kyoto-u.ac.jp Kenji Fujikawa Graduate School of Informatics Kyoto University Yoshida-Honmachi, Sakyo-ku, Kyoto 606-8501 JAPAN Tel: +81 75-753-7468 Fax: +81 75-753-7472 Email: fujikawa@real-internet.org Yasuo Okabe Integrated information Network System Kyoto University Yoshida-Honmachi, Sakyo-ku, Kyoto 606-8501 JAPAN Tel: +81 75-753-7468 Fax: +81 75-753-7472 Email: okabe@i.kyoto-u.ac.jp Arifumi Expires 23 December 2003 [Page 8]