Internet DRAFT - draft-ghiselli-whitepaper-req
draft-ghiselli-whitepaper-req
Internet Draft Expire: Sept. 1994
An IPng Requirements White Paper
<draft-ghiselli-ipng-whitepaper-req-00.txt>
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.
A. Ghiselli
D. Salomoni
C. Vistoli
INFN/CNAF
Italy
January-1994
Abstract:
This white paper is sent by INFN network team, the Italian National
Institute for nuclear phisics, whose network, named INFNet, is a
nationwide network founded to provide the access to existing national and
international HEP laboratory and to facilitate communications between the
researchers.
With this paper we would like to emphasize the key points that we would
to consider if charged with IPng plan. We do not really expect to add
original items to the selection, but we think that it could be useful to
submit the opinions and ideas that come from our network experience.
1. General Requirements
The problems that are to be solved in IP internet are mainly three:
1. address exaustion
2. flat address space
3. routing efficiency, flexibility and capacity.
The aim of IPng study should be to define a plan that solves all these
problems as a whole and not each of them separetely.
The general requirements that we underline for this transition are:
- transparency to the final user: user applications should not be
influenced.
- flexibility: Simplify the suitability to new communication
technology and to topology changes due to new services provided or to
different users needs.
2. Application and Transport Level
Starting from the top of the OSI model, we think that the users
applications should not be influenced by the migration plan.
It means that the TCP (the transport layer) must maintain the same
interfaces and services to the upper layers.
Anyway, it is also necessary to foresee the use of a different transport
services. The possibility to use different transport should be offered
to the applications. Therefore a transport selector field is needed.
3. Network layer: service and address
We assume that the network layer must continue to provide the same
datagram service as IP does.
CLNS could be a solution and a reliable starting point for the IPng.
The main advantage is that this solution has been profitable
tested and it is already available on many systems.
It is not, of course, deployed as widely as IPv4 is, since it is
a newer technology, but it is widely configured and and there is
already operational experience.
The corresponding address, the NSAP, is 20 bytes long.
It is long enough to scale the future data network environment.
Its hierarchical format can be organized in a really flexible way,
satisfying hierarchical routing and policy based routing needs and
simplifying the distributed administration and management.
A lot of work has been already done in the majority of the countries in
order to define NSAP formats satisfying both the requirements of
administrative delegation and routing performances.
4. Routing protocols
We don't consider the decision about the routing protocol to be adopted
for the IPng to be fundamental.
Even if this choice is very important to obtain good performances, the
routing protocols can be changed or improved at any time, because there
is no influence into the End Systems configuration.
Relationships between NSAP aggregation, hierarchical topology and
hierarchical routing algorithm must be taken into account in IPng plan.
These issues could improve administation and topological flexibility of
the IPng and solve the flat problem of the IPv4.
The IPng routing protocols should include policy-based features.
The IPv4 network topology is very complex and it will continue to
enlarge during the transition. It would be very difficult or impossible
to manage it without the "policy" tools.
The multicast capability as well as any other new features that fit
in a datagram network should be supported.
Regarding the Source Routing feature, since we think that it deeply
modifies the aim and the "philosophy" of a connectionless network and
it also introduces an heavy complication in the end nodes and routers
software, we don't consider it a major issue.
5. Layer 2 or communication infrastructure media support.
This is an open field, rapidly changing, then it must be left open to
any evolution. What it should be recommended is to be compatible with
the above network layer.
6. Transition and Deployment
We faced the problem of the transition of the DECNET global network
to DECNET/OSI over CLNS. This activity is now proceding to the last step
and based on this experience we would underline some points that we found
important during the transition deployment.
The transitions must be planned and developed in a distribiuted way.
This means that every organization should have the possibility to plan
and start their network migration without loosing connectivity with
the existing global internet.
Of course, the compatibility with the IPv4 world must be mantained, this
mean that a new generation system must interwork with both the IPv4 and
IPng nodes, using the same applications.
However it is important to define a deadline for the backward
compatibility in order to avoid huge software maintenance in
the user systems and a "multi-topology" management.
We think that a dual stack approach could simplify very much the
transition, whereas a translation mechanism would need a widely and
deep coordination in order to mantain the global connectivity during
the transition period.
The dual stack is simpler and could be easily developed, but it
is important to push in order to have pure IPng with global
connectovity as soon as possible; this could happen when there are
no more "IPv4 only" hosts.
Indeed, the drawback of the dual stack configuration is that you
continue to suffer for the IPv4 address space exaustion and that you
must continue to support the IPv4 routing protocols and
infrasctructure.
We don't think that the tunnel solution to interconnect the IPv4 isle
could give good performances to the users.
Then, it is important to mantain the IPv4 connectivity and the dual
stack software support in the End System software in a determinated
timeframe, or the transition will never end.
