home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 3 / rfc1674.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  6.0 KB  |  172 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          M. Taylor
  8. Request for Comments: 1674                               CDPD Consortium
  9. Category: Informational                                      August 1994
  10.  
  11.  
  12.                     A Cellular Industry View of IPng
  13.  
  14. Status of this Memo
  15.  
  16.    This memo provides information for the Internet community.  This memo
  17.    does not specify an Internet standard of any kind.  Distribution of
  18.    this memo is unlimited.
  19.  
  20. Abstract
  21.  
  22.    This memo is a response to RFC 1550, "IP: Next Generation (IPng)
  23.    White Paper Solicitation".  The statements in this paper are intended
  24.    as input to the technical discussions within IETF, and do not
  25.    represent any endorsement or commitment on the part of the cellular
  26.    industry, the Cellular Digital Packet Data (CDPD) consortium of
  27.    service providers or any of its constituent companies.
  28.  
  29. Introduction
  30.  
  31.    This is a draft of the requirements for IPng as envisioned by
  32.    representatives of the Cellular Digital Packet Data (CDPD) consortium
  33.    of service providers.  As the leading service providers for this
  34.    nascent technology, which will provide the capability for mobility of
  35.    native mainstream connectionless network layer-based applications it
  36.    is our intention to support whatever form IPng takes.  However, there
  37.    are several requirements which we feel IPng must meet.
  38.  
  39. Mobility
  40.  
  41.    Since we will offer mobile services, our primary requirement is that
  42.    IPng not inhibit our support of mobility.  IPng must not impede
  43.    devices from being able to operate anywhere anytime.  Applications on
  44.    these mobile devices must look and feel the same to the user
  45.    regardless of location.  NPDUs should be self-contained and not
  46.    disallow the redirection inherent to our mobility solution, i.e.,
  47.    IPng must be connectionless.
  48.  
  49.    Further, since IPng provides an opportunity for design enhancements
  50.    above and beyond IPv4, we propose that native support for mobility be
  51.    regarded as an explicit IPng requirement.  Local area and wide area
  52.    wireless technology creates new opportunities for both TCP/IP and the
  53.    Internet.  Although the capability for mobility is orthogonal to the
  54.    wired or wireless nature of the data link in use, the rapid
  55.  
  56.  
  57.  
  58. Taylor                                                          [Page 1]
  59.  
  60. RFC 1674            A Cellular Industry View of IPng         August 1994
  61.  
  62.  
  63.    deployment wireless technology amplifies the requirement for
  64.    topological flexibility.
  65.  
  66.    As a by-product of mobility, the significance of "occasionally-
  67.    connected hosts" increases.  The ability to accommodate
  68.    occasionally-connected hosts in IPng is a requirement.
  69.  
  70. Scale
  71.  
  72.    In terms of scale, we envision some 20 to 40 million users by the
  73.    year 2007.  In this context a "user" can be anything from a vending
  74.    machine to a "road warrior".  These numbers are for North America
  75.    alone.  Worldwide, we anticipate that IPng should be able to support
  76.    billions of "users".  Of course, the sparseness of network address
  77.    assignments which is necessary for subnetting, etc., dictates that
  78.    IPng should support at least tens or hundreds of billions of
  79.    addresses.
  80.  
  81. Addressing
  82.  
  83.    In terms of addressing, we would expect addresses to be hierarchical.
  84.    In addition, a node with multiple links should require only a single
  85.    address although more than one address should also be possible.  The
  86.    mapping of names to addresses should be independent of location; an
  87.    address should be an address, not a route.  Variable-length
  88.    addressing is also required to ensure continued protocol (IPng)
  89.    extensibility.  Administration of address assignments should be
  90.    distributed and not centralized as it is now.
  91.  
  92. Security
  93.  
  94.    IPng should also support security mechanisms which will grow
  95.    increasingly important on the proverbial "information highway" for
  96.    commercial users.  Security services which may optionally be expected
  97.    from a Layer 3 entity such as IPng include peer entity
  98.    authentication, data confidentiality, traffic flow confidentiality,
  99.    data integrity and location confidentiality.
  100.  
  101. Accounting
  102.  
  103.    The ability to do accounting at Layer 3 is a requirement.  The CDPD
  104.    specification can be used as a model of the type of accounting
  105.    services that we need.
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Taylor                                                          [Page 2]
  115.  
  116. RFC 1674            A Cellular Industry View of IPng         August 1994
  117.  
  118.  
  119. Route Selection
  120.  
  121.    In the voice communications arena, "equal access" and choice of an
  122.    "interexchange carrier (IXC)" are issues that must be addressed.
  123.    Similar requirements for data may also exist.
  124.  
  125.    Source- and policy-based routing for inter-domain traffic can address
  126.    this requirement.  IPng must allow the selection of at least the
  127.    first transient network service provider based on the source host.
  128.  
  129. Data Efficiency
  130.  
  131.    The bandwidth of wide area wireless networks is a precious resource,
  132.    the use of which must be optimized.  IPng must allow optimal use of
  133.    the underlying Layer 2 medium.  Layer 3 Protocol Control Information
  134.    (PCI) should be as condensed as possible.  The protocol should be
  135.    optimized for data efficiency.
  136.  
  137.    Packet prioritization must also be supported by IPng in order to
  138.    optimize the use of low speed networks.  This requirement includes
  139.    both class and grade of service definitions for flexibility.
  140.  
  141. Transition
  142.  
  143.    The final requirement for IPng is that it must interoperate with IP
  144.    for the foreseeable future.  Bridging mechanisms must be supported
  145.    and a strategy for the transition from IPv4 to IPng must be defined.
  146.    Use of options fields, etc., are one mechanism to support the
  147.    requirement for IPng protocols to support IP addresses and headers.
  148.  
  149. Security Considerations
  150.  
  151.    See section on Security.
  152.  
  153. Author's Address
  154.  
  155.    Mark S. Taylor
  156.    Director of System Development
  157.    McCaw Cellular Communications, Inc.
  158.    Wireless Data Division
  159.    10230 NE Points Drive
  160.    Kirkland, WA 98033-7869 USA
  161.  
  162.    EMail: mark.s.taylor@airdata.com
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Taylor                                                          [Page 3]
  171.  
  172.