1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
|
<pre>Network Working Group A. Ghiselli
Request for Comments: 1676 D. Salomoni
Category: Informational C. Vistoli
INFN/CNAF
August 1994
<span class="h1">INFN Requirements for an IPng</span>
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 <a href="./rfc1550">RFC</a>
<a href="./rfc1550">1550</a>. 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.
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.
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. General Requirements</span>
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:
<span class="grey">Ghiselli, Salomoni & Vistoli [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc1676">RFC 1676</a> INFN Requirements for an IPng August 1994</span>
- 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.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Application and Transport Level</span>
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.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Network layer: service and address</span>
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.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Routing protocols</span>
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
<span class="grey">Ghiselli, Salomoni & Vistoli [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc1676">RFC 1676</a> INFN Requirements for an IPng August 1994</span>
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.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Layer 2 or communication infrastructure media support.</span>
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.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Transition and Deployment</span>
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.
<span class="grey">Ghiselli, Salomoni & Vistoli [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc1676">RFC 1676</a> INFN Requirements for an IPng August 1994</span>
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: Salomoni@infn.it
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: Vistoli@infn.it
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: Ghiselli@infn.it
Ghiselli, Salomoni & Vistoli [Page 4]
</pre>
|
