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

Versions: 00

Network Working Group                                         D. Crocker
Internet-Draft                               Brandenburg InternetWorking
Expires: August 9, 2004                                         A. Doria
                                                                    ETRI
                                                        February 9, 2004


              Framework for Common Endpoint Locator Pools
                       draft-crocker-celp-00.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 9, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   Classic Internet transport protocols use a single source IP Address
   and a single destination IP Address, as part of the identification
   for an individual transport data flow. This is problematic for
   multihomed hosts and for mobile hosts, collectively needing
   "multiaddressing" support. The basic goal, then, is to find a method
   for multiaddressing that makes the smallest possible change to the
   architecture and to current systems, while maintaining flexibility
   for different emerging solutions.  This draft proposes a framework
   for methods for creating Common Endpoint Locator Pools that can be
   used by and among the proposed solutions.




Crocker & Doria          Expires August 9, 2004                 [Page 1]

Internet-Draft                    CELP                     February 2004


Acknowledgment

   Thanks go to those who participated in the original SLAP discussion,
   many of whose ideas and words on the list have been borrowed for this
   draft. The contributors include Brian Carpenter, Spenser Dawkins,
   Christian Huitema, and Pekka Nikander.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1 Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.2 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Basic Proposal . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.1 Variable Granularity . . . . . . . . . . . . . . . . . . . . .  5
   3.2 Security Threats . . . . . . . . . . . . . . . . . . . . . . .  6
   3.3 Changes elsewhere in the architecture  . . . . . . . . . . . .  6
   3.4 Pool synchronization . . . . . . . . . . . . . . . . . . . . .  6
   3.5 Endpoint Congestion Management . . . . . . . . . . . . . . . .  6
   3.6 Coordination with other efforts  . . . . . . . . . . . . . . .  6
       References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  8
       Intellectual Property and Copyright Statements . . . . . . . .  9




























Crocker & Doria          Expires August 9, 2004                 [Page 2]

Internet-Draft                    CELP                     February 2004


1. Introduction

   This draft attempts to capture and expand upon the discussion on
   Shared Locator Address Pool (SLAP) that was held on the Multi6
   mailing list.

   Classic Internet transport protocols use a single source IP Address
   and a single destination IP Address, as part of the identification
   for an individual transport data flow.  For example, TCP includes
   these in its definition of a connection and its calculation of the
   header checksum.  Hence a classic transport association is tied to a
   particular IP Address pair. This is problematic for multihomed hosts
   and for mobile hosts, collectively needing "multiaddressing" support.
   Both have access to multiple IP Addresses -- a "pool" of
   topologically-related locators -- but they are prevented from using
   more than one within an existing transport exchange.   For a host to
   use a different IP Address pair, participants must initiate a new
   exchange.  In the case of TCP, this means a new connection.

   In recent years, there have been efforts to overcome many of these
   limitations, through different approaches at different places in the
   Internet architecture. Some modify the IP infrastructure, with
   embedded redirection services.  Some define transport enhancements to
   support a set of locators directly, and some define a layer between
   classic IP and classic transport. Each of the existing proposals has
   notable limitations in functionality, implementation, deployment or
   use. A discussion of the architectural choices and summary of
   existing multiaddressing projects is in [CHOICE]. The locator schemes
   offered in these efforts comes in two varieties; transport based and
   wedge based.  In the former, multiaddressing support is made an
   integral part of a particular transport service. In the wedge based
   approach, multiaddressing support resides in a functional layer
   between IP and transport.

   Transport-based locator-pool schemes ( [SCTP], [DCCP], [TCP-MH] )
   multiplex their control exchange in with data traffic. Also, the
   transport layer can naturally obtain information on the quality of
   different paths. For example, SCTP can perform measurements across
   several paths simultaneously, and can then map flows on one or
   another path. TCP-MH can detect that the current path has stopped
   working well, for example if the frequency of repetition becomes too
   high, and can decide to try another path. Wedge-layer approaches (
   [HIP], [LIN6], [MAST], [MIP6] ) must conduct their control exchange
   on a separate logical channel. If a host must do this exchange on a
   separate channel, with every other host it talks to, the aggregate
   overhead can be high. Hence transport based schemes have an the
   potential advantage of saving on number of packets.




Crocker & Doria          Expires August 9, 2004                 [Page 3]

Internet-Draft                    CELP                     February 2004


   On the other hand, wedge based approaches can maintain
   multiaddressing information across transport associations and can
   maintain pools with different referential granularity.  That is, they
   can have a pool for all associations between two hosts or they can
   subdivide into different pools for different activities between the
   hosts. The logical terminus for these pools with a more narrow scope
   is called an "endpoint". Hence the next transport activity between
   two endpoints may well be able to use multiaddressing immediately and
   with no further administrative overhead. Further, wedge-based locator
   exchange protocols can be incorporated without necessitating
   modification to any host's IP or transport modules.  Wedge protocols
   may be invoked at any time, before or during a transport association.
   A host may initiate and conduct a classic, single IP-pair TCP
   connection. It may then separately query for remote host support of
   the wedge protocols and initiate a endpoint locator exchange to be
   used by that connectivity.  Either participant is then free to add or
   remove endpoint locators. Of course, use of a wedge protocol may
   instead be performed before a transport context is established, so
   that future contexts immediately have access to multiple endpoint
   locators.  Because many associations are short, initiation of a wedge
   protocol can be deferred entirely, choosing to apply it only for
   persistent associations.

   The objective of this framework is to permit benefits for all
   participants. A wedge layer scheme shares  "enhanced" transport
   service's lower-cost locator pool control exchange largess. A
   transport scheme shares the control exchange the wedge layer has
   already done, before the transport association is initiated.

1.1 Terminology

   Work on multiaddressing is forcing significant changes and greater
   precision, in the use of some common networking terminology. In this
   document, the term "address" is used in the introduction, for its
   familiarity, and then is restricted to be part of the label "IP
   Address", to refer to that protocol's locator values. Similarly use
   of the term "host" is restricted to refer to the assignee of one or
   more IP Addresses. For discussing multiaddressing pools, the term
   "endpoint" is used to refer to a pool with potentially smaller scope.
   In general, this document takes its terminology from [CHOICE].

1.2 Discussion Venue

   Discussion and commentary are encouraged about the topics presented
   in this document. The preferred forum is the
   <mailto:multi6@ops.ietf.org> mailing list, for which archives and
   subscription information are available at <http://ietf.org/
   html.charters/multi6-charter.html>.



Crocker & Doria          Expires August 9, 2004                 [Page 4]

Internet-Draft                    CELP                     February 2004


2. Basic Proposal

   The basic proposal can be described in the following three
   propositions:

   1.  An endpoint runs endpoint Locator Pools (LP) as a resource shared
       among different consumer services at the endpoint -- for example,
       a wedge layer service and an enhanced transport service --
       potentially with multiple maintainers. LPs might vary in their
       granularity.  Bigger grains makes it more likely that the pool
       will be shared.  A pool that is the finest grain (Connection)
       can't be shared, of course.
   2.  A Common Endpoint Locator Address Pool (CELP) capability is used
       by the different maintenance services, over different
       communication channels (for example, multiplexed on the transport
       channel, versus over an independent control channel.) The
       maintenance services also might use different "configurations",
       such as peer-to-peer exchange, versus third-party agent
       mediation.
   3.  Enhanced transport services access the pool directly. Legacy
       transport services access the pool via the IP wedge layer
       service. If an enhanced transport is one of the participants,
       then there really is no need for a wedge-layer service to conduct
       an exchange. This saves packets. Hence the wedge layer serves to
       use the information provided by the transport scheme and apply it
       to legacy transport and application services.

3. Issues

3.1 Variable Granularity

   One transport activity may wish (or need) to share its
   multiaddressing fate with another. Or it may wish to avoid the
   problems with that sharing, and tolerate the limitations that ensue.
   These choices can be achieved by having LPs with different scope.
   At the widest scope, all multiaddressing between a host-pair is
   shared by all transport associations between them.  Hence, the common
   pool is characterized by:

        {local, remote}

   For finer-grained sharing, the pool can be characterized with a
   variety of additional attributes. For example, and IPv6 flow might be
   used:

        {local, remote, flow label}

   or all activity for a specific application service might share the



Crocker & Doria          Expires August 9, 2004                 [Page 5]

Internet-Draft                    CELP                     February 2004


   pool. This could be characterized by:

        {local, remote, IP protocol, Well-known port}

   or a single transport association might wish to have its own pool, as
   characterized by the classic connection identifier:

        {local, remote, IP protocol, local port, remote port}


3.2 Security Threats

   As described in [THREATS] there are redirection threats that may
   occur when multihoming is used. A CELP solution will need to respond
   to those threats as well to any exacerbation of DOS and other
   flooding attacks.

3.3 Changes elsewhere in the architecture

   In order to support a CELP solution, will other entities in the
   network need to modified? For example will changes be required in
   DNS, network management, or trace mechanisms?  Additionally, there is
   the need to determine whether third-party mediation services are
   required or even warranted.

3.4 Pool synchronization

   If several protocols are 'maintaining' the pool there arises a
   concern about synchronization of the state information in the pool.
   One consideration is the creation of a protocol to maintain CELP
   state. It is unclear whether this will be necessary.

3.5 Endpoint Congestion Management

   With a CELP mechanism, the transport may not see the locator
   information, instead seeing only an identifier. However, differential
   congestion control is needed at the locator level. This indicates
   that bringing congestion control into the core of the pool mechanism
   as part of creating pools may be necessary.

3.6 Coordination with other efforts

   Given the number of efforts in the IETF at the moment that are
   suggesting modification to the transport layer and below, it is
   necessary to coordinate with these efforts.

References




Crocker & Doria          Expires August 9, 2004                 [Page 6]

Internet-Draft                    CELP                     February 2004


   [CHOICE]   Crocker, D., "Choices for Support of Multiaddressing",
              draft-crocker-mast-analysis-00.txt (work in progress), Oct
              2003.

   [DCCP]     Handley, M., Floyd, S. and J. Padhye, "Datagram Congestion
              Control Protocol (DCCP)", draft-ietf-dccp-spec-05.txt
              (work in progress), Oct 2003.

   [HIP]      Moskowitz, R., Nikander, P. and Henderson, "Host Identity
              Protocol", draft-moskowitz-hip-08.txt (work in progress),
              Oct 2003.

   [LIN6]     Teraoka, F., Ishiyama, M. and M. Kunishi, "LIN6: A
              Solution to Mobility and Multi-Homing in IPv6",
              draft-teraoka-ipng-lin6-02.txt (work in progress), June
              2003.

   [MAST]     Crocker, D., "MULTIPLE ADDRESS SERVICE FOR TRANSPORT
              (MAST): AN EXTENDED PROPOSAL",
              draft-crocker-mast-proposal-01.txt (work in progress),
              Sept 2003.

   [MIP6]     Johnson, D., Perkins, C. and J. Arkko, "Mobility Support
              in IPv6", draft-ietf-mobileip-ipv6-24.txt (work in
              progress), June 2003.

   [SCTP]     Stewart, R., Xie, Q., Schwarzbauer, K., Morneault, K.,
              Sharp, C., Taylor, T., Rytina, I., Kalla, M., Zhang, L.
              and V. Paxson, "Stream Control Transmission Protocol", RFC
              2960 RFC 2960, Oct 2000.

   [TCP-MH]   Matsumoto, A., Kozuka, M., Fujikawa, K. and Y. Okabe, "TCP
              Multi-Home Options", draft-arifumi-tcp-mh-00.txt (work in
              progress), Oct 2003.

   [THREATS]  Nordmark, E. and T. Li, "",
              draft-nordmark-multi6-threats-00.txt (work in progress),
              Oct 2003.













Crocker & Doria          Expires August 9, 2004                 [Page 7]

Internet-Draft                    CELP                     February 2004


Authors' Addresses

   D. Crocker
   Brandenburg InternetWorking
   675 Spruce Drive
   Sunnyvale  94086
   USA

   Phone: +1.408.246.8253
   EMail: dcrocker@brandenburg.com
   URI:   http://brandenburg.com/


   Avri Doria
   ETRI

   EMail: avri@acm.org
   URI:   psg.com/~avri

































Crocker & Doria          Expires August 9, 2004                 [Page 8]

Internet-Draft                    CELP                     February 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2004). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Crocker & Doria          Expires August 9, 2004                 [Page 9]

Internet-Draft                    CELP                     February 2004


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Crocker & Doria          Expires August 9, 2004                [Page 10]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/