As per Relevance of the word requirements, we have this rfc below:
Network Working Group A.
Request for Comments: 1676 D.
Category: Informational C.
INFN/
August 1994
INFN Requirements for an
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This document was submitted to the IETF IPng area in response to
1550. Publication of this document does not imply acceptance by
IPng area of any ideas expressed within. Comments should
submitted to the big-internet@munnari.oz.au mailing list
This white paper is sent by INFN network team, the Italian
Institute for nuclear physics, whose network, named INFNet, is
nationwide network founded to provide the access to existing
and international HEP laboratory and to facilitate
between the researchers. With this paper we would like to
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,
we think that it could be useful to submit the opinions and
that come from our network experience
1. General
The problems that are to be solved in IP internet are mainly three
1. address
2. flat address
3. routing efficiency, flexibility and capacity
The aim of IPng study should be to define a plan that solves
these problems as a whole and not each of them separately
The general requirements that we underline for this transition are
Ghiselli, Salomoni & Vistoli [Page 1]
RFC 1676 INFN Requirements for an IPng August 1994
- transparency to the final user: user applications should not
influenced
- flexibility: Simplify the suitability to new
technology and to topology changes due to new services
or to different users needs
2. Application and Transport
Starting from the top of the OSI model, we think that the
applications should not be influenced by the migration plan.
means that the TCP (the transport layer) must maintain the
interfaces and services to the upper layers. Anyway, it is
necessary to foresee the use of a different transport services.
possibility to use different transport should be offered to
applications. Therefore a transport selector field is needed
3. Network layer: service and
We assume that the network layer must continue to provide the
datagram service as IP does. CLNS could be a solution and a
starting point for the IPng. The main advantage is that
solution has been profitable tested and it is already available
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
there is already operational experience. The corresponding address
the NSAP, is 20 bytes long. It is long enough to scale the
data network environment. Its hierarchical format can be
in a really flexible way, satisfying hierarchical routing and
based routing needs and simplifying the distributed
and management. A lot of work has been already done in the
of the countries in order to define NSAP formats satisfying both
requirements of administrative delegation and routing performances
4. Routing
We don't consider the decision about the routing protocol to
adopted for the IPng to be fundamental. Even if this choice is
important to obtain good performances, the routing protocols can
changed or improved at any time, because there is no influence
the End Systems configuration. Relationships between
aggregation, hierarchical topology and hierarchical routing
must be taken into account in IPng plan. These issues could
administration and topological flexibility of the IPng and solve
flat problem of the IPv4. The IPng routing protocols should
policy-based features. The IPv4 network topology is very complex
it will continue to enlarge during the transition. It would be
difficult or impossible to manage it without the "policy" tools.
Ghiselli, Salomoni & Vistoli [Page 2]
RFC 1676 INFN Requirements for an IPng August 1994
multicast capability as well as any other new features that fit in
datagram network should be supported. Regarding the Source
feature, since we think that it deeply modifies the aim and
"philosophy" of a connectionless network and it also introduces
heavy complication in the end nodes and routers software, we don'
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
any evolution. What it should be recommended is to be compatible
the above network layer
6. Transition and
We faced the problem of the transition of the DECNET global
to DECNET/OSI over CLNS. This activity is now proceeding to the
step and based on this experience we would underline some points
we found important during the transition deployment. The
must be planned and developed in a distributed way. This means
every organization should have the possibility to plan and
their network migration without loosing connectivity with
existing global internet. Of course, the compatibility with the IPv
world must be maintained, this mean that a new generation system
interwork with both the IPv4 and IPng nodes, using the
applications
However, it is important to define a deadline for the
compatibility in order to avoid huge software maintenance in the
systems and a "multi-topology" management. We think that a
stack approach could simplify very much the transition, whereas
translation mechanism would need a widely and deep coordination
order to maintain the global connectivity during the
period. The dual stack is simpler and could be easily developed,
it is important to push in order to have pure IPng with
connectivity as soon as possible; this could happen when there are
more "IPv4 only" hosts
Indeed, the drawback of the dual stack configuration is that
continue to suffer for the IPv4 address space exhaustion and that
must continue to support the IPv4 routing protocols
infrastructure. We don't think that the tunnel solution
interconnect the IPv4 isle could give good performances to the users
Then, it is important to maintain the IPv4 connectivity and the
stack software support in the End System software in a
timeframe, or the transition will never end
Ghiselli, Salomoni & Vistoli [Page 3]
RFC 1676 INFN Requirements for an IPng August 1994
Security
Security issues are not discussed in this memo
Authors'
Davide
INFN-
National Institute of Nuclear Physics - National Networking
V.le Ercolani, 8
40138 Bologna -
Phone: +39 51 6098-260
Fax: +39 51 6098 135
EMail: Salomoni@infn.
Cristina
INFN-
National Institute of Nuclear Physics - National Networking
V.le Ercolani, 8
40138 Bologna -
Phone: +39 51 6098-260
Fax: +39 51 6098 135
EMail: Vistoli@infn.
Antonia
INFN-
National Institute of Nuclear Physics - National Networking
V.le Ercolani, 8
40138 Bologna -
Phone: +39 51 6098-267
Fax: +39 51 6098 135
EMail: Ghiselli@infn.
Ghiselli, Salomoni & Vistoli [Page 4]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
