Network Working Group                                        A. Ghiselli
Request for Comments: 1676                                   D. Salomoni
Category: Informational                                       C. Vistoli
                                                              INFN/CNAF
                                                            August 1994


                    INFN Requirements for an IPng

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.

Overview

  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 [email protected] mailing list.

Abstract

  This white paper is sent by INFN network team, the Italian National
  Institute for nuclear physics, 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 exhaustion

     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 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 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
  administration 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



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 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 proceeding 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 distributed 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 maintained, 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 maintain 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
  connectivity 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 exhaustion and that you
  must continue to support the IPv4 routing protocols and
  infrastructure.  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 maintain the IPv4 connectivity and the dual
  stack software support in the End System software in a determined
  timeframe, or the transition will never end.





Ghiselli, Salomoni & Vistoli                                    [Page 3]

RFC 1676             INFN Requirements for an IPng           August 1994


Security Considerations

  Security issues are not discussed in this memo.

Authors' Addresses

  Davide Salomoni
  INFN-CNAF
  National Institute of Nuclear Physics - National Networking Center
  V.le Ercolani, 8
  40138 Bologna - Italy

  Phone:  +39 51 6098-260
  Fax:    +39 51 6098 135
  EMail: [email protected]


  Cristina Vistoli
  INFN-CNAF
  National Institute of Nuclear Physics - National Networking Center
  V.le Ercolani, 8
  40138 Bologna - Italy

  Phone:  +39 51 6098-260
  Fax:    +39 51 6098 135
  EMail: [email protected]


  Antonia Ghiselli
  INFN-CNAF
  National Institute of Nuclear Physics - National Networking Center
  V.le Ercolani, 8
  40138 Bologna - Italy

  Phone:  +39 51 6098-267
  Fax:    +39 51 6098 135
  EMail: [email protected]














Ghiselli, Salomoni & Vistoli                                    [Page 4]


You are viewing proxied material from gopher.rbfh.de. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.