Internet DRAFT - draft-ford-tuba-whitepaper
draft-ford-tuba-whitepaper
Network Working Group Peter Ford
INTERNET DRAFT LANL
Expires: September 1994 Mark Knopper
AADS
20 March 1994
TUBA as IPng: A White Paper
<draft-ford-ipng-tuba-whitepaper-00.txt>
Draft 0.5
Status of this Memo
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.
Distribution of this memo is unlimited.
This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
Please check the 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
current status of any Internet Draft.
1 Executive Summary
1.1 Introduction
TUBA (TCP and UDP with Bigger Addresses) is a solution for IPng.
TUBA has two components: a replacement for the IPv4 network layer
protocol and a transition strategy. The TUBA transition strategy is
fully documented in another "Transition Plan for TUBA/CLNP," draft-
tuba-transition-00.txt, by D. Piscitello. The TUBA concept for IPng
was originally presented in RFC 1347 [4] in June, 1992.
As the customer base of the Internet grows and the demand for new
services continues, it is anticipated that new functionality in the
Internet suite of protocols will be introduced, e.g., security [42],
multicasting [10], autoconfiguration[29], mobility, resource
reservation, and enhanced support for policy-based routing. Many of
these problems can and are being addressed within the IPv4 context
and can be analogously implemented in TUBA systems. For several of
these functions, there are standardization efforts and experimental
implementations in progress for CLNP. Other functions, like
autoconfiguration in the ES-IS protocol, have been largely completed.
The TUBA working group is tracking the efforts of the CDPD (cellular
digital packet data [48]) group in the use of CLNP in mobile
internets. Efforts in the IETF Source Demand Routing Protocol (SDRP)
Working Group [46] can be applied to CLNP to solve policy routing
issues such as provider selection.
Ford, Knopper [Page 1]
TUBA White Paper TUBA as IPng: A White Paper 20 March 1994
This White Paper discusses engineering considerations along with
general characteristics of TUBA in order to bring about a greater
understanding of this approach for the IPng Directorate and the wider
IETF community. References to existing and in-progress documents are
provided.
1.2 Brief Overview of TUBA
TUBA replaces the Internet network layer, IPv4, with the OSI
connectionless network layer protocol, CLNP [8]. TUBA systems allow
the current Internet applications, such as Telnet, FTP, Mosaic and
Electronic Mail, to operate using CLNP as the network layer protocol.
CLNP shares most of the architectural features and functionality of
IPv4, but is distinguished by its use of flexible, variable length
addresses called Network Service Access Points (NSAPs). The IETF OSI
operations planning (NOOP) group has developed an NSAP addressing
plan [2] that meets the objective of addressing for an Internet
of the size anticipated in the next century. The flexibility of
NSAPs allows the embedding of other network layer addresses, such as
IPv4 and Novell IPX. Other organizations have selected NSAPs for
addressing, such as the ATM Forum's use of NSAPs for addressing
within ATM networks.
The use of the CLNS MIB [34] allows management of CLNP systems using
SNMP.
The routing architecture for CLNP has already been specified,
standardized, and implemented in products. Routing protocols used
with CLNP include IDRP [15], IS-IS [14], and ES-IS [13]. The TUBA
routing architecture and protocols (IDRP and IS-IS) follow IPv4's
CIDR architecture and protocols (BGP and OSPF). IDRP and IS-IS are
sufficiently flexible that they can be used to route multiple network
layer protocols including IPv4, IPX and SIPP.
2 Engineering Considerations:
2.1 Scaling.
The ability of the Internet to scale to a practically unlimited
number of nodes (10^12 - 10^16) is one of the major driving forces
behind IPng. One may argue that this is the only problem that can't
be solved within the IPv4 context. If one expects IPng to last for
several decades, then it is important that IPng should be capable to
scale well beyond the current requirements.
To adequately scale, the new IPng must meet the requirements:
Ford, Knopper [Page 2]
TUBA White Paper TUBA as IPng: A White Paper 20 March 1994
1) Meet the total size requirement: 10^12 to 10^16 nodes.
2) Allow for evolution of the variety of addressing and
routing plans of the Internet. 3) There is
no single trusted party who will determine all
addressing and routing plans. 4) There is some degree of
fault isolation; if party X fails to generate a
reliable and workable routing and addressing
plan,then only those elements of the system that
depend on X will be impacted. 5) The overhead of routing
through such an internet will grow much slower than
linearly with respect to the number of nodes that
comprise the internet.
These requirements dictate a hierarchic structure to meet the desired
scaling properties.
TUBA easily meets the requirement to address and hierarchically
organize 10^12 - 10^16 nodes. TUBA uses variable length NSAPs, and
the common addressing profiles for NSAPs specify NSAPs of up to 20
octets. If 20 bytes is not enough, CLNP can carry network layer
addresses of up to 255 octets long.
The only scalable routing technology that is known to grow less than
linearly is the technique of hierarchical routing described in
Kleinrock and Farouk [50]. This technique is based on the following
two assumptions: (a) network topology is hierarchical in nature, and
(b) network addresses assigned to network nodes reflect the network
topology. The first assumption is outside the scope of the IPng, but
has to do with how different networks interconnect with each other.
While we can't predict the future, the current Internet fits quite
well into the hierarchical topology model. The second assumption,
topologically significant addressing, is satisfied by using
provider-based addressing. This technique is already deployed in the
current Internet in the context of CLNP ("NSAP Address Guidelines")
and IPv4 (Classless Inter-Domain Routing (CIDR)).
It is generally well accepted that hierarchical address assignment
implies relatively low utilization of the address space. Thus an IPng
that should be capable of supporting an internet of 10^12 - 10^16
nodes should have a much larger address space to accomodate low
utilization. Support for variable length addresses in TUBA allows
flexible, yet efficient way of dealing with large internets where
address space utilization is relatively low.
NSAPs also allow for multiple domains of administration of routing
and addressing plans thorugh the use of Address Format Identifiers
(AFIs). An AFI is the leading byte of an NSAP. This allows new
addressing and routing plans to be introduced over the course of
Ford, Knopper [Page 3]
TUBA White Paper TUBA as IPng: A White Paper 20 March 1994
time. It also allows parties who are not necessarily part of the
Internet community to separately develop addressing and routing
plans, implement and operate their networks, and at any later point
in time to join their internet with the Internet. At first blush,
this would appear to provide the opportunity of introducing routing
chaos. The truth is that since separate addressing plans are
identified by different AFIs, an internet can simply import a single
route for an AFI and use it to route traffic between itself and the
foreign network.
Hierarchial addressing in TUBA is complemented by the OSI routing
protocols (IDRP, IS-IS, ES-IS) that can explore the hierarchy to
reduce the volume of routing information, thus providing the required
scaling properties. Scaling characteristics of IDRP are analyzed in
Rekhter, Y., "Forwarding Database Overhead for Inter-Domain Routing",
ACM CCR, Vol 23, No. 1, January 1993, and in Rekhter, Y., "IDRP
Protocol Analysis: Storage Overhead", ACM CCR, Vol 22, No 2, April
1992. IDRP is described in Rekhter, Y., "Inter-Domain Routing
Protocol (IDRP)", Internetworking: Research and Experience, VOl 4,
1993.
It is important to understand that while hierarchical routing
provides a powerful mechanism for scaling, it is in no way forces all
the routes to follow the hierarchy. The OSI routing protocols
support "mask and match" exploration of the hierarchical structure,
so that at any point of the system, one can take advantage of
multiple positions in the hierarchy. The inter-domain routing
protocol used by TUBA (IDRP) allows to support both the routing
along the strict hierarchy, as well as routing that doesn't follow
the hierarchy.
2.2 Timescale
TUBA depends on significant longevity of the IPv4 Internet. All
efforts should be made to extend the lifetime of the IPv4 address
space. Transition to any IPng will take a significant amount of time
(>4 years) and thus any IPng will require that IPv4 last a long time.
2.3 Transition and deployment
The TUBA transition strategy is fully documented in another
"Transition Plan for TUBA/CLNP," draft-tuba-transition-00.txt, by D.
Piscitello.
The transition strategy for TUBA is based on coexistence of TUBA/IPng
with IPv4, with incremental deployment and upgrade of both IPv4 and
CLNP. CLNP is deployed in the network infrastructure, and on hosts,
as co-existent protocols with IPv4 during an indeterminable
Ford, Knopper [Page 4]
TUBA White Paper TUBA as IPng: A White Paper 20 March 1994
transition period. Tunneling may be necessary to span areas which
have not completed the transition.
2.4 Security
Access control, authentication, data integrity, and confidentiality
are recognized as security services that are required in the current
as well as future global Internet. A widely recognized solution to
providing these services is through a secure network layer packet
encapsulation protocol supported by a key management protocol for
exchanging security information associated with a particular instance
of communication.
The Internet, through the IETF IPSEC Working Group, is currently
working towards an encapsulation protocol solution for IPv4. TUBA,
as a functionally isomorphic datagram protocol, also requires an
encapsulation protocol; it is desirable that the same protocols that
provide these security services for IPv4 also provide them for CLNP.
TUBA-knowledgeable people attend the IPSEC WG to encourage this
convergence, although it is not explicitly part of their charter.
There are at least two existence proofs that a single security
encapsulation protocol can be used to support both IPv4 and CLNP.
The SDNS protocol, SP3 [42], and the connection-less portion of the
OSI Network Layer Security Protocol [43], NSLP-CL, provide the same
sets of security services for both IPv4 and CLNP. SP3 specifically
allows for both IPv4 and CLNP packets to be encapsulated by the SP3
protocol. NLSP-CL, while originally designed to provide security for
CLNP, has been shown to provide the same set of services for IPv4.
The Internet Draft I-NLSP (Integrated Network Layer Security
Protocol) [44], describes in detail how NLSP-CL can provide these
services for both IPv4 and CLNP. Hughes Networking has an
implementation of NLSP-CL that provides these security services for
IPv4. While the IPSEC Working Group is chartered to provide a set of
security protocols only for IPv4, the protocol that they are
designing can provide the same security services for CLNP.
The key management protocol work of the IPSEC WG has not yet gotten
off the ground. Assuming that the encapsulation protocol for IPv4
and CLNP is the same, it follows that the key management protocol
developed by the IPSEC WG also could be used to support secure
operation of both datagram protocols. Since key management is viewed
as an application, such dual use is not expected to pose any
significant technical hurdles.
2.5 Configuration, administration and operation
Ford, Knopper [Page 5]
TUBA White Paper TUBA as IPng: A White Paper 20 March 1994
The biggest configuration requirement in any network is that of the
hosts. TUBA provides fully automated administration of network
addresses, with the option of having the host supply the System ID
portion of the address. This capability is present in shipping
product today. Registration of these addresses in the DNS will be
possible when the appropriate DNS changes have been completed.
Higher-layer system configuration can be accomplished using DHCP.
Address administration in a network is simplified by the absence of
the "subnet" model--it is not necessary to administer subnet
addresses; instead, the granularity of address administration is at
the routing area level. This makes it easy to add LAN segments
without address adminstration overhead, as well as allowing hosts to
be moved from one LAN segment to another without changing network
addresses.
Router administration is also simplified by the lack of subnet
addresses; routers need at most one address per area in which they
participate. The IS-IS routing protocol also greatly simplifies
router administration, as summarization of routing information is
fully automatic at area boundaries. Typically, the only
configuration necessary on a router is to assign a network address
and decide which interfaces IS-IS will be running on.
All of the standard tools for network management (ping, traceroute,
SNMP) are or will be available for use with TUBA. [37]
2.6 Mobile hosts
Wireless technology, including RF and Infrared, enables a new
paradigm - mobile computing. Portable computers and the highly
portable Personal Data Assistants (PDAs) can either communicate by
wireless technology, or can plug into the Internet analogously to the
current use of cellular phones that acquire cells when they a set up
for roaming. While mobile computing can be supported in a variety of
ways, in the context of IPng this implies support for the network
layer mobility, where a host can change its attachment point(s) to a
network without necessarily changing its network layer address (by
which it is know in the directory service).
Work in currently under way within the IETF's mobile-ip WG to define
how network layer mobility will be supported in the context of IPv4.
It is expected that this work can be used almost directly in the
context of TUBA, substituting CLNP for IPv4 and making sure the
routing protocol can support NSAPs.
Since CLNP doesn't assume the traditional IPv4 subnet model, this
Ford, Knopper [Page 6]
TUBA White Paper TUBA as IPng: A White Paper 20 March 1994
will further simplify support for network layer mobility by allowing
a mobile host to acquire its temporary address via ES-IS
autoconfiguration functionality. Moreover, ES-IS functionality will
allow two hosts (where at least one of the hosts is mobile) attached
to a common Link Layer subnetwork to communicate directly with each
other without any third party involved. This is certainly an
improvement over network layer mobility in IPv4, since the IPv4
subnet model makes direct communication without a third party
problematic, if not impossible.
2.7 Flows and resource reservation
An important requirement of IPng is the support of "flows" (that is,
somewhat connection-oriented capabilities in order to reserve
resources and/or guarantee certain characteristics to particular
applications, hosts or users). Work is in progress on flows for CLNP
(see [9]).
2.8 Policy Based Routing
Support for policy based routing for CLNP can be based on the Unified
Architecture as described in RFC1322, in (Estrin, D., Rekhter, Y.,
Hotz, S., "Scalable Inter-Domain Routing Architecture", SIGCOMM
1992). Support for most of the routing requirements is realized via
IDRP. Support for specialized routing requirements is realized via
domain-level source routing mechanisms, like SDRP or GRE. A
combination of domain-level source routing and IDRP allows
straightforward support for such policy based routing features as
selecting an indirect provider (as described in I-D draft-rekhter-
select-providers-01.txt), or selecting a direct provider (as describe
in draft-rekhter-direct-provider-00.txt).
CLNP allows a host to have one or more addresses (NSAPs) assigned to
it. The ability to assign multiple addresses to a host could be a
useful mechanism to address certain requirements for policy based
routing. Different prefixes for a host could be used to indicate
different routes to that host.
2.9 Topological flexibility.
IPv4 is based on the subnet model, where each link is assigned a
unique number (known as the subnet number). Emergence of new
technologies (like ATM and SMDS) poses a certain challenge to the
traditional IP subnet model (see draft-braden-shared-media-00.txt).
Likewise, support for network layer mobility is impeded by the subnet
Ford, Knopper [Page 7]
TUBA White Paper TUBA as IPng: A White Paper 20 March 1994
model. As the demand for reliable connectivity increases, the need
to eliminate
single points of failure will drive an increase in the number of
multi-point attached hosts. All that suggests that IPng needs an
addressing model more flexible than the current IPv4 model. The CLNP
model, where subnets (aka areas) are logical, and not bound to a
particular data link may be more suitable to deal with all these
issues.
2.10 Applicability
The key to broadening the potential applicability for TUBA as IPng is
in the flexible NSAP addressing. Part of the attractiveness of IPv4
is in its use in private and application-specific nets, and CLNP
retains that quality. If anything the niche applicability aspect will
continue with usage in large hidden networks such as mobile and
wireless devices, large scale cable TV distribution networks, or
corporate networks which may or may not be globally reachable. Use of
CLNP will support continued phenomenal growth of the Internet: in
number of hosts (supported by large address space), managing routing
tables (prefix-based aggregation for NSAP addressing was the basis
for the CIDR design for IPv4), and conserving host and router
resources (the connectionless datagram model allows stateless
forwarding and both existing and new routing protocol standards can
be used with CLNP/TUBA).
NSAP addresses provide for a high degree of structure in order to
carry variable semantics. Some examples of addresses which can be
carried in NSAPs include class D addresses for multicast groups,
provider selection, encapsulated multi-protocols e.g. DECnet, IPX,
IPv4, etc., and data link layer addresses for switch fabric
infrastructure.
2.11 Datagram Service
The TUBA datagram service is described in ISO 8473 and in RFC 1561
(D. Piscitello, "Use of ISO CLNP in TUBA Environments"). Significant
features of the CLNP datagram service include optional 16-bit
fletcher checksum, NSAP addressing, and the congestion experienced
bit. RFC 1561 describes a means of using CLNP in a manner which is
semantically very similar to IPv4 except with bigger and more
structured addresses.
2.12 Accounting
Like security, accounting or charging and billing can be done at the
Ford, Knopper [Page 8]
TUBA White Paper TUBA as IPng: A White Paper 20 March 1994
application layer or within the internetwork itself. To allow
expected features to be supported, eventually both layers must
provide support. No standards for connectionless network layer
(including IPv4 or CLNP) accounting exist at this time, however some
preliminary work has emerged. The CDPD specification includes an
agreement on implementation of network layer accounting and billing
record transmission for settlement between providers [47]. Bellcore
has done some work on an Internet Billing Server, and there is work
being done in the IP Accounting working group. IPv4 and CLNP share
qualities with respect to accounting and it is expected that work
will proceed in parallel with both protocols.
2.13 Support of communication media
IPng must be at least as adaptable as IPv4 to operation over various
communications media. It will be required to operate over
essentially any communication media that might reasonably support
packet-based data transfers. From a perspective of the network layer
protocol, there are three important areas that must be considered for
suitability with respect to particular media: link-speed, error
characteristics, and topology.
Link-speed is perhaps the most often discussed issue: can IPng
provide adequate performance over very slow links, and can it be
processed fast enough for very fast links? In both cases the answer
to these questions for TUBA is yes, with the low-speed support
provided through CLNP header compression (see TUBA Transition ID for
reference) and with the possibility of high-speed support. At least
one router vendor has preliminary results indicating that IP and CLNP
can be switched at similar very high rates. It should be noted that
header processing rates are of concern mainly in the router area
where protocol optimizations can reasonably be expected to take
place, while hosts are mainly concerned with TCP and higher layer
performance issues, which remain essentially unchanged with TUBA.
Error characterists of communications media vary greatly, but
normally are hidden from the network layer protocol by link-layer
checksums that catch most errored frames before they are ever
processed. The issues of delivering packets with errored headers to
hosts are a topic much too large to discuss here, but it should be
noted that the CLNP header checksum is much stronger than IPv4, and
would therefore provide greater assurance against misdelivery of
packets due to errors undetected by the link-layer. CLNP also
provides an escape mechanism which allows the header checksum to be
skipped, enabling cheaper high-speed implementations in environments
that are deemed suitable to unprotected network layer header usage.
Ford, Knopper [Page 9]
TUBA White Paper TUBA as IPng: A White Paper 20 March 1994
The topology issues for individual communication media revolve mainly
around addressing capabilities: broadcast vs multicast vs point-to-
point, and the MAC-layer to IPng layer address resolution, etc.
2.14 Robustness and fault tolerance
The semantics of global network layer addressing and hop-by-hop
forwarding in CLNP allow a high degree of robustness with simple
dynamic re-routing as in IPv4. Stability and robustness may be
increased with use of protocols such as IS-IS which include
specification for resource exhaustion conditions.
2.15 Technology pull
There are a number of factors that should "pull" the Internet in the
direction of incorporation of additional features at the network
layer, and a few of these are listed next. There is nothing specific
in CLNP and the TUBA approach to immediately support these features
however there are no known limits or drawbacks that will prevent
further development of these protocols.
a) Multicast transmission and multiple content types;
b) The trend toward ubiquitous access to the Internet via switching
and integration with telephony technologies (e.g. public Internet
jacks);
c) Support of accounting and chargeback for services. This may
influence the evolution of a number of services that would not be
introduced if billing was not possible;
d) Availability of large scale parallel computers;
e) Network interface virtual hardware, or physical interfaces for
Internet access being provided on devices carrying alternative
traffic;
f) Software defined networks allowing closed user groups and multiple
communities to be served with the appearance of separately provided
networks;
g) Widespread deployment of switched infrastructure such as ATM,
SMDS, and Frame Relay may allow relaxation of the current geographic
boundaries for Internet routing, e.g. network providers using the
switch fabric may be able to peer directly though they are located in
different continents.
Ford, Knopper [Page 10]
TUBA White Paper TUBA as IPng: A White Paper 20 March 1994
2.16 Action items
The Internet community has been extremely focused on the packet
format for IPng. At the same time significant requirements have been
established for IPng including multicast, support for mobility,
security, policy based routing, etc. The TUBA working group supports
designing IPng to meet these requirements, and indeed believes that
there will be future requirements over and beyond the set of
requirements currently identified.
It is this unpredictability which drives the TUBA effort to opt for
flexibility in its IPng efforts. For example, it is unrealistic to
expect that we understand what addressing and routing plans will be
needed 5 years out, let alone 10-20 years from now. Thus, the TUBA
effort has adopted NSAPs to meet the requirements for addressing.
The Flexibility of NSAPs will allow the adoption of new addressing
and routing structures as the Internet evolves.
There are several other key areas where the IPng efforts have
identified that the current degree of flexibility in either the
design or common implementations of key components of the Internet is
insufficient to meet future evolution of the Internet:
1) The current DNS representation of information other than Names
and IPv4 addresses is quite limited. To add a new type to the
DNS requires recompilation of both servers and resolver
libraries.
2) Common API for the DNS. Even Posix does not have a defined
standard for basic functionality as gethostbyname(char *) ->
Internet_Addr. Winsock addresses this, but the current spec
does not adequately handle for variable length addresses.
3) Socket APIs. Current socket APIs need to be made to work on
opaque handles. Most of todays internet application base is
too familiar with the internal representation of Internet
addresses. An API that allows coding the following simple
code sequence would benefit application developers
tremendously: read(hostname)
host_addr<-gethostbyname(hostname)
s<-socket(host_addr)
3 Security Considerations
Network layer security provided by the TUBA protocols for IPng is
discussed in section 2.4 of this memo. Application layer security is
mentioned but outside the scope of TUBA itself.
4 Acknowledgements
Ford, Knopper [Page 11]
TUBA White Paper TUBA as IPng: A White Paper 20 March 1994
Grateful thanks are extended to Ross Callon, Richard Colella, Dave
Katz, Tracy Mallory, Bill Manning, Doug Montgomery, Dave Piscitello
and Yakov Rekhter for contribution and review of this paper.
5 Author's Addresses
Peter Ford
Los Alamos National Laboratory
Los Alamos, NM 87544
Phone: 505-665-0058
Email: peter@goshawk.lanl.gov
Mark Knopper
Ameritech Advanced Data Services
339 E. Liberty, Suite 310
Ann Arbor, MI 48104
Phone: 313-913-0800
Email: mak@aads.net
Bibliography
[1] Postel, J., Transmission Control Protocol (TCP). STD 7,
RFC 793, September 1981.
[2] Postel, J., Internet Protocol (IP). STD 5, RFC 791,
September 1981.
[3] Rekhter, Y., and Li, T., Architecture for IP Address
Allocation with CIDR, RFC 1518, September 1993.
[4] Callon, R., TCP/UDP over Bigger Addresses (TUBA), RFC
1347, May 1992.
[5] Piscitello, D., Use of ISO CLNP in TUBA environments,
RFC 1562, December 1993.
[6] ISO/IEC 8348-1992. International Standards Organization-
-Data Communications--OSI Network Layer Service and
Addressing.
[7] Callon, R., R. Colella, and R. Hagens, NSAP Addressing Guidelines
for the Internet, RFC 1237, July 1991 (note obsolete by [48]).
[8] ISO/IEC 8473. International Standards Organization --
Data Communications -- Protocol for Providing the
Connectionless-mode Network Service, ISO/IEC 8473:1992,
Edition 2.
[9] Callon, R., "A proposal for adding flow support to
CLNP", Internet-Draft
[10] Marlow, D., "Host group extensions for CLNP Multicast",
Internet-Draft
Ford, Knopper [Page 12]
TUBA White Paper TUBA as IPng: A White Paper 20 March 1994
[11]
[12] Partridge, C., "Criteria for choosing IPv7 Selection",
Internet-draft.
[13] ISO/IEC 9542. International Standards Organization --
Telecommunications and Information Exchange between
Systems -- End System to intermediate system routeing
exchange protocol for use in conjunction with the
protocol for providing the connectionless-mode network
service (ISO/IEC 8473), ISO 9542:1988.
[14] ISO/IEC 10589, Intermediate system to intermediate
system routeing exchange protocol for use in
conjunction with the protocol for providing the
connectionless-mode network service (ISO/IEC 8473), ISO
10589:1992.
[15] ISO/IEC 10747, Protocol for exchange of interdomain
routeing information among intermediate systems to
support forwarding of ISO/IEC 8473 PDUs, ISO /IEC
10747:1992.
[16] Piscitello, D., Assignment of System Identifiers for
TUBA/CLNP hosts, RFC 1526, November 1993.
[17] Katz, D., Tunneling the OSI Network Layer over CLNP
(EON), Internet-draft.
[18] Hanks. S, T. Li, D. Farinacci, P. Traina, Generic
Routing Encapsulation over IPv4 networks, Internet-
draft, September 1993.
[19] Hanks. S, T. Li, D. Farinacci, P. Traina, Generic
Routing Encapsulation, Internet-Draft, September 1993.
[20] Leiner, B., Rehkter, Y., The Multiprotocol Internet,
RFC 1560, December 1993.
[21] Callon, R., and Perlman, R., Integrated IS-IS, RFC
1195.
[22] Tsuchiya, P. NAT paper from SIGCOMM/CCR.
[23] H. W. Braun, P.Ford, Y.Rekhter,"CIDR and the Evolution
of the Internet Protocol", Proceedings of INET '93,
August 1993.
[24] Callon, "how to extend IP", Internet-draft in
preparation.
[25] Piscitello, D., FTP Operation Over Big Address Records
(FOOBAR), RFC 1545, October 1993.
[26] Manning, Colella, DNS RRs for NSAPAs, RFC in
preparation
[27a] Rose, M., SNMP over OSI. RFC 1418, 1993 March.
[27b] Rose, M., SNMP over OSI. RFC 1283 1991 December
[28] Katz, "Suggested System ID Option for the ES-IS
Protocol", Internet-Draft in preparation
[29] Katz, "Dynamic Assignment of OSI NSAP Addresses in the
Internet", Internet-Draft in preparation.
[31] Mogul, J., and S. Deering, RFC 1191, MTU Discovery.
Ford, Knopper [Page 13]
TUBA White Paper TUBA as IPng: A White Paper 20 March 1994
[31] Piscitello, D.,"MTU discovery for CLNP-based hosts",
Internet-Draft in preparation.
[32] Whyman, "ICAO CLNP Header Compression
algorithm",available by anonymous FTP, in compressed
postscript form, from comm.cenaath.cena.dgac.fr as
/atn/icao-clnp-compress-ps.zand
[33] IPv4 header compression RFCs
[34] Satz, G., Request for Comments 1238, Connectionless-
mode Network Service Management Information Base - for
use with Connectionless Network Protocol (ISO 8473) and
End system to Intermediate System Protocol (ISO 9452)",
Internet Architecture Board, June 1991.
[35] Gilligan, R., and B. Hinden, "IPAE: The SIPP
Interoperability and Transition Mechanism", Internet-
draft, November 1993.
[36] Katz, D., P. Ford, "TUBA: Replacing IP with CLNP",
March 24 1993.
[37] Wittbrodt, C., and S. Hares, Essential Tools for the
OSI Internet, Request for Comments 1574, March 1994.
[38] Wittbrodt, C., and S. Hares, CLNP Ping (Echo), Request
for Comments 1575, March 1994.
[39] Bound, J., IPng Host Implementation Analysis, IPng
white paper, February 1994.
[40] Phil Karn, electronic mail message to ipsec@ans.net
entitled "Re: IPSEC & ROAD", 29 November 1992.
[42] SDNS, "Security Protocol 3 (SP3)," Specification
SDN.301/Revision 1.5, May 1989.
[43] ISO/IEC, "Information technology -- Open Systems
Interconnection -- Network Layer Security Protocol,"
International Standard 11577, November 1993.
[44] Glenn, K. Robert, "Integrated Network Layer Security
Protocol," Internet Draft (draft-glenn-layer-security-
00.txt), September 1993 (work in progress).
[45] Hanks, S., Li, T., Farinacci, D., Traina, P., Generic
Routing Encapsulation (GRE), draft-hanks-gre-00.txt,
work in progress, September, 1993.
[46] Estrin, D., Zappala, D., Li, T., Rekhter, Y., Source Demand
Routing: Packet Format and Forwarding Specification (Version 1),
draft-estrin-sdrp-03.txt, work in progress, September, 1993.
[47] Cellular Digital Packet Data System Specification, Release 1.0,
July 19, 1993.
[48] Colella, R., Callon, R., Gardner, E., Rekhter, Y., Guidelines
for OSI NSAP Allocation in the Internet,
draft-ietf-osinsap-allocation-00.txt, work in progress,
December 25, 1993.
[49] Hares, S., Scudder, J., IDRP for IP, draft-hares-idrp-05.txt,
work in progress, September, 1993.
[50] Kleinrock, L., Farouk, K., Hierarchical Routing
Ford, Knopper [Page 14]
TUBA White Paper TUBA as IPng: A White Paper 20 March 1994
for Large Networks, Computer Networks 1, 1977.
[51] Fuller, V., Li, T., Yu, J., Varadhan, K., Classless Inter-Domain
Routing (CIDR): an Address Assignment and Aggregation Strategy,
Request for Comments 1519, September, 1993.
Ford, Knopper [Page 15]
