GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1678

Network Working Group E. Britton Request for Comments: 1678 J. Tavs Category: Informational IBM

                                                           August 1994
           IPng Requirements of Large Corporate Networks

Status of this Memo

 This memo provides information for the Internet community.  This memo
 does not specify an Internet standard of any kind.  Distribution of
 this memo is unlimited.

Abstract

 This document was submitted to the IETF IPng area in response to RFC
 1550.  Publication of this document does not imply acceptance by the
 IPng area of any ideas expressed within.  Comments should be
 submitted to the big-internet@munnari.oz.au mailing list.  This draft
 summarizes some of the requirements of large corporate networks for
 the next generation of the Internet protcol suite.

Executive Overview

 As more and more corporations are using TCP/IP for their mission-
 critical applications, they are bringing additional requirements,
 summarized below, the satisfaction of which would make TCP/IP even
 more appealing to businesses.  Since these are requirements rather
 than solutions, we include capabilities that might be provided in
 protocol layers other than the one that IPv4 occupies; i.e., these
 items might lie outside the scope typically envisioned for IPng, but
 we'll refer to them as IPng requirements nonetheless.  When we
 mention potential solutions, it is not to suggest that they are the
 best approach, but merely to clarify the requirement.
 Among business users the major requirements we see for IPng are:
  1. - smooth migration from, and coexistence with, IPv4;
  2. - predictable levels of service for predictable costs;
  3. - security; and
  4. - accommodation of multiple protocols suites.
 We also mention several more specific requirements.
 IPng must have a viable strategy for migration from, and coexistence
 with, IPv4.  IPv4 and IPng must coexist well, because they will need
 to do so for several years.  To encourage IPv4 users to upgrade to

Britton & Tavs [Page 1] RFC 1678 IPng Requirements of Large Corporate Networks August 1994

 IPng, IPng must offer compelling advantages and an easy migration
 path.
 Corporate networks must meet promised levels of service while
 controlling costs through efficient use of resources.  The IETF
 should consider both technical solutions (such as service classes and
 priorities) and administrative ones (such as accounting) to promote
 economy.
 Many businesses will not connect to a network until they are
 confident that it will not significantly threaten the
 confidentiality, integrity, or availability of their data.
 Corporations tend to use multiple protocols.  Numerous forces stymie
 the desire to settle on just one protocol for a large corporation:
 diverse installed bases, skills, technical factors, and the general
 trend toward corporate decentralization.  The IETF needs a strategy
 for heterogeneity flexible enough to accommodate the principal
 multiprotocol techniques, including multiprotocol transport,
 tunneling, and link sharing.
 Some of these requirements might be satisfied by more extensive
 deployment of existing Internet architectures (e.g., Generic Security
 Service and IPv4 type of service).  The current Internet protocols
 could be enhanced to satisfy most of the remaining requirements of
 commercial users while retaining IPv4.  Nevertheless, some
 corporations will be scared away from TCP/IP by the publicity about
 the address space until the IETF sets a direction for its expansion.

Migration and Coexistence

 As the use of IPv4 continues to grow, the day may come when no more
 IPv4 network addresses will be left, and no additional networks will
 be able to connect to the Internet.  Classless Inter-Domain Routing
 (CIDR, RFC 1519) and careful gleaning of the address space will
 postpone that cutoff for several years.  The hundreds of millions of
 people on networks that do get IPv4 addresses won't be affected
 directly by the exhaustion of the address space, but they will miss
 the opportunity to communicate with those less lucky.
 Because the Internet is too large for all its users to cutover to
 IPng quickly, IPng must coexist well with IPv4.  Furthermore, IPv4
 users won't upgrade to IPng without a compelling reason.  Access to
 new services will not be a strong motivation, since new services will
 want to support both the IPng users and the IPv4 users.  Only
 services that cannot exist on IPv4 will be willing to use IPng
 exclusively.  Moreover, if IPng requires more resources (e.g.,
 storage, memory, or administrative complexity) than IPv4, users will

Britton & Tavs [Page 2] RFC 1678 IPng Requirements of Large Corporate Networks August 1994

 not install IPng unless it has clear benefits over IPv4.  Indeed, the
 millions of users of low-end systems (DOS, sub-notebooks) might not
 ever be able to use IPng if it takes more memory.  Thus there will be
 a long period of coexistence between IPng and IPv4, so the
 coexistence needs to be quite painless, and not based on any
 assumption that IPv4 use will diminish quickly.

Service Level Agreements

 If a corporation depends on its network for applications that are
 critical to its business (such as airlines do for reservations, and
 brokerages do for stock and bond trades), then the corporation
 insists that the network provide the needed service level for a
 predictable cost, so they can allow for it in their budget ahead of
 time.  A service level agreement (SLA) is a contract between
 network's provider and users that defines the service level which a
 user will see and the cost associated with that level of service.
 Measurements in an SLA may include response times (average and
 maximum), availability percentages, number of active sessions,
 throughput rates, etc..  Businesses need to be able to predict and
 guarantee the service levels and costs (routing capacity, link
 bandwidth, etc.) for their traffic patterns on a TCP/IP network.
 IPng should allow control of the cost of networking, a major concern
 for corporations.  Teleprocessing lines are a significant cost in
 corporate networks.  Although the cost per bit-per-second tends to be
 lower on higher-bandwidth links, high-bandwidth links can be hard to
 get, particularly in emerging nations. In many places it is difficult
 to acquire a 64 kpbs line, and T1 service might not exist.
 Furthermore, lead times can be over six months.  Even in the US the
 cost of transcontinental T1 service is high enough to encourage high
 utilization.  Cost-conscious businesses want IPng to allow high
 utilization of teleprocessing links, but without requiring excessive
 processing power to achieve the high utilization.  There has been
 considerable speculation concerning the goodput through congested
 routes when using the Internet's current congestion control
 algorithms; instead, it should be measured in a range of realistic
 cases.  If peak-busy-hour goodput under congestion is near the
 theoretical maximum, publicize the data and move on to other
 requirements.  If not, then the IETF should seek a better standard
 (e.g., they might explore XTP's adaptive rate-based approach and
 other proposals).
 Functions, such as class of service and priority, that let an
 enterprise control use of bandwidth also may help meet service level
 agreements.  On the one hand, it has been said that the absence of
 these inhibits TCP/IP usage in corporate networks, especially when
 predictable interactive response times are required.  On the other

Britton & Tavs [Page 3] RFC 1678 IPng Requirements of Large Corporate Networks August 1994

 hand, few vendors have felt motivated to implement TCP's architected
 type-of-service, and priority tends to be handled in a non-standard
 way (e.g., to assure that interactive well-known ports, such as
 Telnet, get faster response times than non-interactive well-known
 ports, such as file transfer).  The IETF should sort out these
 apparently conflicting perspectives.  If the ad hoc techniques can be
 demonstrated to be adequate, then they should be standardized;
 otherwise, effective techniques should be developed and standardized.
 Commercial users often require the options of a higher level of
 service for a higher cost, or a lower level of service for a lower
 cost; e.g., some businesses pay top dollar to assure fast response
 time during business hours, but choose less expensive satellite
 services for data backup during the night.  Pervasive use of IPv4's
 type-of-service markings might satisfy this requirement.
 To discourage waste of bandwidth and other expensive resources,
 corporations want to account for their use.  Direct cost recovery
 would let an entity measure and benchmark its efficiency with minimal
 economic distortion.  Alternatives, such as placing these costs into
 corporate overhead or charging per connection, make sense when the
 administrative cost of implementing usage-based accounting is high
 enough to introduce more economic distortion than the alternatives
 would.  For example, connection-based costs alone may be adequate for
 a resource (such as LAN bandwidth) that is not scarce or expensive,
 but a combination of a connection cost and a usage cost may be more
 appropriate for a more scarce  or expensive resource (such as WAN
 bandwidth).  Balance must be maintained between the overhead of
 accounting and the granularity of cost allocation.

Security

 Many corporations will stick with their private networks until public
 ones can guarantee equivalent confidentiality, integrity, and
 availability.  It is not clear that additional architecture is needed
 to satisfy this requirement;  perhaps more wide spread use of
 existing security technology would suffice.  For example, the
 Internet could encourage wide deployment of Generic Security Service,
 and then solicit feedback on whether additional security requirements
 need to be satisfied.  Note that businesses are so concerned about
 network cost control mechanisms that they want them secured against
 tampering.  IPng should not interfere with firewalls, which many
 corporations consider essential.

Britton & Tavs [Page 4] RFC 1678 IPng Requirements of Large Corporate Networks August 1994

Heterogeneity

 Corporate users want the Internet to accommodate multiple protocol
 suites.  Several different protocol suites are growing in use, and
 some older ones will be used for many more years.  Although many
 people wish there were only one protocol in the world, there is
 little agreement on which one it should be.
 Since the marketplace has not settled on one approach to handling
 multiple protocols, IPng should be flexible enough to accommodate a
 variety of technical approaches to achieving heterogeneity.  For
 example, most networking protocols assume they will be the dominate
 protocol that transports all others;  protocol designers should pay
 more attention to making their protocols easily transported by
 others.  IPng needs to be flexible enough to accommodate the major
 multiprotocol trends, including multiprotocol transport networking
 (for an example, see X/OPEN document G306), tunneling (both IP being
 the tunnel and being tunneled), and link sharing (e.g., point-to-
 point protocol and frame relay).  Fair sharing of bandwidth by
 protocols with different congestion control mechanisms is a
 particularly interesting subject.

Flow and Resource Reservation

 Corporate users are becoming more interested in transmitting both
 non-isochronous and isochronous information together across the same
 link.  IPng should coexist effectively with the isochronous protocols
 being developed for the Internet.
 The Internet protocols should take advantage of services that may be
 offered by an underlying fast packet switching service. Constant-
 bit-rate and variable-bit-rate services typically require
 specification of, and conformance to, traffic descriptors and
 specification of quality-of-service objectives from applications or
 users.  The Internet's isochronous protocols should provide
 mechanisms to take advantage of multimedia services that will be
 offered by fast packet switching networks, and must ensure that
 quality-of-service guarantees are preserved all the way up the
 protocol stacks to the applications.  Protocols using available-bit-
 rate services may achieve better bandwidth utilization if they react
 to congestion messages from a fast packet switching network, and if
 they consider consequences of cell discard (e.g., if one cell of an
 IP datagram is discarded, it would be a waste to continue forwarding
 the rest of the cells in that datagram; also, selective retransmit
 should be revisited in this context).
 When the Internet protocol suite allows mixing of non-isochronous and
 isochronous traffic on one medium, it should provide mechanisms to

Britton & Tavs [Page 5] RFC 1678 IPng Requirements of Large Corporate Networks August 1994

 discourage inappropriate reservation of resources; e.g., a Telnet
 connection probably doesn't need to reserve 45Mbps.  Accounting,
 class-of-service, and well-known-port distinctions are possible ways
 to satisfy that requirement.

Mobile Hosts

 Wireless technology opens up opportunities for new TCP/IP
 applications that are specific to mobile hosts.  In addition to
 coordinating with organizations developing wireless standards, the
 IETF also should encourage the specification of new TCP/IP
 applications enabled by wireless, such as connectionless messaging.
 IPng should deal well with the characteristics (delay, error rates4,
 etc.) peculiar to wireless.

Topological flexibility

 Today a TCP/IP host moved to a different subnet needs a new IP
 address.  Such moves and changes can become a significant
 administrative cost.  Moreover, mobile hosts require flexible
 topology.  Note how the wireless world is trying to defeat the subnet
 model of addressing either by proxy or by IPaddress servers.  Perhaps
 IPng needs an addressing model more flexible than subnetting, both to
 reduce the administrative burden and to facilitate roaming users.
 The need to eliminate single points of failure drives the business
 requirement for multi-tail attachment of hosts to networks.
 Corporate users complain that TCP/IP can non-disruptively switch a
 connection from a broken route to a working one only if the new route
 leads to the same adapter on the end system.

Configuration, Administration and Operation

 Businesses would like dynamic but secure updating of Domain Name
 Servers, both to ease moves and changes and to facilitate cutover to
 backup hosts.  In this vein, secure and dynamic interaction between
 DNS and Dynamic Host Configuration Protocol (DHCP, RFC 1541) is
 required.  The IETF should encourage wide deployment of DHCP, and
 then solicit feedback on whether additional configuration
 requirements need to be satisfied.

Policy-Based Routing

 Policy-based routing is a more a solution than a requirement.
 Businesses rarely require a general purpose policy architecture,
 although they do state requirements that policy-based routing could
 satisfy.  For example, corporations do not want to carry for free the

Britton & Tavs [Page 6] RFC 1678 IPng Requirements of Large Corporate Networks August 1994

 transit traffic of other enterprises, and they may not want their
 sensitive data to flow through links controlled by certain other
 enterprises.  Policy-based routing is one possible way to satisfy
 those requirements, but there seems to be a concern that general
 purpose policy-based routing may have high administrative cost and
 low routing performance.

Scaling

 If IPng satisfies the scaling requirement of the Internet, then it
 satisfies it for corporate networks a fortiori.

Conclusions

 Enhancements to the Internet protocol suite, together with wider
 deployment of some of its existing architectures, could satisfy these
 requirement of commercial customers while retaining IPv4.  Expansion
 of the address space eventually will be necessary to allow continued
 Internet growth, but in RFC 1518 Tony Li and Yakov Rehkter have shown
 that from a technical perspective the addressing issue of IPng is not
 an immediate concern.
 Nevertheless, the TCP/IP community should establish a direction for
 enlargement of the address space, because unfounded publicity about
 the address space is scaring away potential TCP/IP users.  If the
 IETF does not provide direction on how its address space will grow,
 then people may use non-standard, and probably incompatible,
 approaches.

Security Considerations

 The IETF should encourage wide deployment of GSS API, and then
 solicit feedback on whether additional security requirements need to
 be satisfied.  Businesses are so concerned about network cost control
 mechanisms that they want them secured against tampering.  IPng
 should not interfer with firewalls, which many corporations consider
 essential.  See other comments on Security throughout this memo.

Britton & Tavs [Page 7] RFC 1678 IPng Requirements of Large Corporate Networks August 1994

Authors' Addresses

 Edward Britton
 IBM Corp.
 E69/503
 P.O.Box 12195
 Research Triangle Park, NC 27709
 Phone: (919) 254-6037
 EMail: brittone@vnet.ibm.com
 John Tavs
 IBM Corp.
 E69/503
 P.O.Box 12195
 Research Triangle Park, NC 27709
 Phone: (919) 245-7610
 EMail: tavs@vnet.ibm.com

Britton & Tavs [Page 8]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1678.txt · Last modified: 1994/08/04 23:42 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki