[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Internet Engineering Task Force                               J. Ubillos
Internet-Draft                             Swedish Institute of Computer
Intended status: Experimental                                    Science
Expires: March 21, 2011                                            M. Xu
                                                                 Z. Ming
                                                     Tsinghua University
                                                                 C. Vogt
                                                                Ericsson
                                                      September 17, 2010


                    Name-Based Sockets Architecture
                  draft-ubillos-name-based-sockets-03

Abstract

   This memo defines Name-based sockets. name-based sockets allow
   application developers to refer to remote hosts (and it self) by name
   only, passing on all IP (locator) management to the operating system.
   Applications are thus relieved of re-implementing features such as
   multi-homing, mobility, NAT traversal, IPv6/IPv4 interoperability and
   address management in general.  The operating system can in turn re-
   use the same solutions for a whole set of guest applications. name-
   based sockets aims to provide a whole set of features without adding
   new indirection layers, new delays or other dependences while
   maintaining transparent backwards compatibility.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on March 21, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Ubillos, et al.          Expires March 21, 2011                 [Page 1]

Internet-Draft       Name-Based Sockets Architecture      September 2010


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     3.1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . 3
     3.2.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . 3
     3.3.  Compatibility goals . . . . . . . . . . . . . . . . . . . . 4
       3.3.1.  Network compatibility . . . . . . . . . . . . . . . . . 4
       3.3.2.  Application compatibility . . . . . . . . . . . . . . . 4
     3.4.  name-based sockets overview . . . . . . . . . . . . . . . . 4
     3.5.  Protocol overview . . . . . . . . . . . . . . . . . . . . . 5
   4.  Initial name exchange . . . . . . . . . . . . . . . . . . . . . 5
     4.1.  Name format . . . . . . . . . . . . . . . . . . . . . . . . 7
     4.2.  Service names (and port numbers)  . . . . . . . . . . . . . 7
     4.3.  Transport selection . . . . . . . . . . . . . . . . . . . . 7
   5.  API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
   8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . 9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 9
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 9
     9.3.  URL References  . . . . . . . . . . . . . . . . . . . . . . 9

















Ubillos, et al.          Expires March 21, 2011                 [Page 2]

Internet-Draft       Name-Based Sockets Architecture      September 2010


1.  Conventions

   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].

2.  Terminology

   Locator - An IP address (v4 or v6) on which a host can be reached.

   Name - A character string (max 255 chars long) on which a host can be
   identified.

3.  Overview

3.1.  Introduction

   name-based sockets provide a unified interface which caters to the
   application developers who wish to simply open up a communication to
   a remote host by its name and have the operating system perform the
   management of locators.

   It does so by providing a new address family (AF_NAME) which allows
   the developer to use a name instead of an IP (or other locator).

3.2.  Motivation

   Network communication has for very long been based on the assumption
   that applications should deal with the IP (locator) management.  This
   is based on the legacy notion that an IP does not change during a
   session and that a session is a communication between two given IPs
   (locators).  This situation has changed, locators change during a
   session, and a device/host might have multiple locators, hosts may be
   behind NA(P)Ts or be on different locator domains (e.g.  IPv4/IPv6).
   Today, this is mostly left to the individual applications to solve.
   This adds complexity to the applications making it a challenge in it
   self just to meet the networking demands of applications.

   Name-based sockets aims to fix this by pushing the locator management
   to the operating system, without introducing any new limitations or
   delays.

   By approaching the problem at the socket() level, existing
   abstraction frameworks can easily benefit from a change.  By allowing
   the existing abstractions to simply pass along the name the whole way
   down to the socket() call, the abstraction or whole framework are
   able to benefit by name-based sockets.




Ubillos, et al.          Expires March 21, 2011                 [Page 3]

Internet-Draft       Name-Based Sockets Architecture      September 2010


   Note that name-based sockets do not aim to replace all socket() based
   communications.  There are of course cases which are limited due to
   obvious boot-strapping problems.  E.g. a DHCP client, or an DNS-
   querying client would do better in not using a name oriented
   architecture.

3.3.  Compatibility goals

3.3.1.  Network compatibility

   1.  Minimal changes to "on the wire" protocol.

   2.  No changes to added 'features'

3.3.2.  Application compatibility

   The objective is to maintain the (BSD) socket() semantics commonly
   used today.  It is important that the transition for developers
   should be trivial.

   Maintaining these semantics allows existing abstraction frameworks to
   integrate name-based sockets to their frameworks.  Socket
   abstractions are often used to simplify the use of a service e.g.
   HTTP.  In those cases, they do not add functionality at the network
   or transport layer.  These kinds of abstraction frameworks would
   quickly be able to make use of the extra functionality provided by
   name-based sockets.

3.4.  name-based sockets overview

   name-based sockets provide a new socket interface.  It is implemented
   using a new address family (AF_NAME).  This means that the sockets
   are only used by applications who explicitly invoke it.  The result
   is that applications that do use name based sockets are very aware of
   the set of features they are provided with, hence they know not to
   re-implement them.  Current implementations are implemented as kernel
   modules, however a user-space library implementation ought to work
   just as well.

   By using DNS as the ID/Locator mapping structure, we do not introduce
   any new indirections.  Please note that the responding host does not
   need to do any reverse-DNS resolution (explained below).  We part
   from the assumption that most application network calls start with a
   FQDN.

   The exchange of names is performed in-band, by piggy-backing the
   needed information on the first couple of packets exchanged.  The
   consequence is:



Ubillos, et al.          Expires March 21, 2011                 [Page 4]

Internet-Draft       Name-Based Sockets Architecture      September 2010


   o  No extra delays

   o  No extra features until the name exchange has ended.

   o  As a result of this, we also achieve backwards compatibility (a
      name exchange which never completes)

3.5.  Protocol overview

   name-based sockets work by performing a name exchange in the
   beginning of a communication.  It does this in an non-blocking way.
   In practice what happens is that the first few packets are exchanged
   in a normal legacy fashion.  However, to these packets, extra
   information about the corresponding hosts names are piggy-backed.  If
   a name exchange is successful, the extra features provided by name-
   based sockets are enabled.  If the exchange does not succeed, normal
   legacy communication continues unaffected.

   The name of each host is either its FQDN, its IP in IPv6.arpa format
   or an arbitrary nonce.  It may or may not be authenticated.  In the
   ordinary case, the name is not authenticated, thus the receiver does
   not need to perform a reverse or forward lookup, hence not adding any
   further delays to the first packet(s).  The motivation for this is to
   avoid any additional "first-packet" delays.

   Once the name exchange has been performed successfully the complete
   feature set will be made available to the communication
   automatically.

   The expected API for a socket using AF_NAME is the same as for e.g.
   TCP (SOCK_STREAM).  This is also the case for SOCK_DGRAM and similar
   protocols, for all practical purposes, the functionality remains
   unchanged, however, as state is created in both ends, connection
   oriented semantics are more intuitive.

4.  Initial name exchange

   When the sender sends the first packet to the receiver it appends its
   own name as an IP-Option/IPv6-Extension header.  It repeats this for
   a predefined amount of time or packets.  On the receiving end, if the
   receiver supports name-based sockets it appends its own name in the
   same fashion for a predefined amount of time or packets.  Should the
   receiver not be able to interpret the name, the option/extension
   header is ignored and the legacy communication precedes as normal.

   This kind of name exchange has two consequences.  First and foremost
   that there are no extra delays on the initial packets.  Secondly that
   the complete feature set provided by name based sockets will not be



Ubillos, et al.          Expires March 21, 2011                 [Page 5]

Internet-Draft       Name-Based Sockets Architecture      September 2010


   available until a few packets have been exchanged.

   In figure 1 the exchange is depicted.  The first packet from the
   sender has its own name appended to it.  The next few packets sent
   will also have the name appended to it for a predefined number of
   packets (X in the figure) or until a reply including a name extension
   is received.  On the receiving end, should an incoming packet have a
   name extension, the receiver begins to append its own name to the
   sent packets.  It does so for a predefined number of packets (X in
   the figure).


   .--------.                         .----------.
   | Sender |                         | Receiver |
   '--------'                         '----------'
       |                                   |
       |                                   |
       |       .-------------------.       |
       | ------|    Data packet    |-----> |  Packet received.
       |       |+ name piggybacked |       |  The first response
       |       '-------------------'       |  packet will have
       | ---------->                       |  the receiver name
       | ------->                          |  piggy backed to it.
       | ---->  .-----------------------.  |
       | ->     | name piggybacked      |  |
       |        | until reply or X pkts |  |
       |        '-----------------------'  |
       |                                   |
       |                                   |
       |                                   |
       |        .-------------------.      |
       | <------|    Data packet    |----- |
       |        |+ name piggybacked |      |
       |        '-------------------'      |
       |                       <---------- |
       |                          <------- |
       |       .------------------.  <---- |
       |       | name piggybacked |     <- |
       |       | until X pkts     |        |
       |       '------------------'        |
       |                                   |
       |                                   |

   Figure 1







Ubillos, et al.          Expires March 21, 2011                 [Page 6]

Internet-Draft       Name-Based Sockets Architecture      September 2010


4.1.  Name format

   Names can be provided in any of three ways.

   o  FQDN.  The Fully Qualified Domain Name of the host.  This will
      allow e.g.  DNSsec to provide authenticity of the name.

   o  ip6.arpa.  Using one of the hosts interfaces addresses as a name.

   o  Nonce.  A one-use only session identifier.

4.2.  Service names (and port numbers)

   Services are identified by a string.  For compatibility reasons, it
   is reasonable to use the "Keyword" field as an identifier of the
   service in question.

   Excerpt from http://www.iana.org/assignments/port-numbers

   Keyword         Decimal    Description                     References
   -------         -------    -----------                     ----------
   http             80/tcp    World Wide Web HTTP
   http             80/udp    World Wide Web HTTP
   www              80/tcp    World Wide Web HTTP
   www              80/udp    World Wide Web HTTP
   www-http         80/tcp    World Wide Web HTTP
   www-http         80/udp    World Wide Web HTTP
   http             80/sctp   HTTP


   Keyword and port number mappings.

4.3.  Transport selection

   Often today, the transport protocol is implied by the service in
   question.  How this is handled remains to be defined.  It is however
   likely that a default transport protocol can be provided depending on
   which service is requested.

5.  API

   The API follows the connection oriented model, e.g.  TCP.  The
   available calls are:

   listen():  Prep for incoming session






Ubillos, et al.          Expires March 21, 2011                 [Page 7]

Internet-Draft       Name-Based Sockets Architecture      September 2010


      fd = listen( local_name, peer_name, service, transport );

   open():  Initiate outgoing session

      fd = open( local_name, peer_name, service, transport );

   accept():  Receive incoming session

      accept( peer_name, fd );

   read():  Receive data

      data = read( fd );

   write():  Send data

      write( fd, data );

   close():  Close session

      close( fd );

   Note: In the above examples

   local_name  The local identifier.  Either an explicit name or a
      wildcard (*).  As host may have multiple names, to choose which to
      listen to, a name must be chosen or a wildcard may be used.  In
      the latter case, on listening, any destination name is accepted;
      on send, an arbitrary name (valid for the host) may automatically
      be chosen by the socket.

   peer_name  The remote identifier.  Either an explicit name or a
      wildcard (*).  In the accept() function, a wildcard might be
      inserted.  In this case, all incoming packets will be accepted,
      independent of sender name.

   service  The service to be run.  In general this will correspond to
      the keyword field in the IANA Port Numbers registry.  E.g. http,
      ftp and ssh.

   transport  Transport refers to the chosen transport protocol.  This
      could be e.g.

      *  TCP (SOCK_STREAM)

      *  UDP (SOCK_DGRAM)





Ubillos, et al.          Expires March 21, 2011                 [Page 8]

Internet-Draft       Name-Based Sockets Architecture      September 2010


      *  SCTP (SOCK_SCTP)

      *  DCCP (SOCK_DCCP)

      *  NORM ...

      *  And so on ...

6.  Security Considerations

7.  IANA Considerations

   name-based sockets requires a new address family (AF_NAME) to be
   defined.

8.  Contributors

9.  References

9.1.  Normative References

   [RFC2119]                      Bradner, S., "Key words for use in
                                  RFCs to Indicate Requirement Levels",
                                  BCP 14, RFC 2119, March 1997.

9.2.  Informative References

   [RFC5533]                      Nordmark, E. and M. Bagnulo, "Shim6:
                                  Level 3 Multihoming Shim Protocol for
                                  IPv6", RFC 5533, June 2009.

   [RFC5534]                      Arkko, J. and I. van Beijnum, "Failure
                                  Detection and Locator Pair Exploration
                                  Protocol for IPv6 Multihoming",
                                  RFC 5534, June 2009.

   [I-D.cotton-tsvwg-iana-ports]  Cotton, M., Eggert, L., Mankin, A.,
                                  and M. Westerlund, "IANA Allocation
                                  Guidelines for TCP and UDP Port
                                  Numbers",
                                  draft-cotton-tsvwg-iana-ports-00 (work
                                  in progress), February 2008.

9.3.  URL References







Ubillos, et al.          Expires March 21, 2011                 [Page 9]

Internet-Draft       Name-Based Sockets Architecture      September 2010


Authors' Addresses

   Javier Ubillos
   Swedish Institute of Computer Science
   Kistagangen 16
   Kista
   Sweden

   Phone: +46767647588
   EMail: jav@sics.se


   Mingwei Xu
   Tsinghua University
   FIT Building  4-104, Tsinghua  University
   Beijing
   China

   EMail: xmw@cernet.edu.cn


   Zhongxing Ming
   Tsinghua University
   FIT Building  4-104, Tsinghua  University
   Beijing
   China

   EMail: mingzx@126.com


   Christian Vogt
   Ericsson
   200 Holger Way
   San Jose, CA  95134-1300
   USA

   EMail: christian.vogt@ericsson.com














Ubillos, et al.          Expires March 21, 2011                [Page 10]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/