home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
ipae
/
ipae-minutes-92oct.txt
< prev
next >
Wrap
Text File
|
1993-02-17
|
4KB
|
110 lines
INTERIM_MEETING_REPORT_
Reported by Dave Crocker/TBO
Minutes of the IP Address Encapsulation Working Group (IPAE)
This meeting was held at Sun Microsystems on October 8, 1992
The major topic of the meeting has been documented in a note sent by Bob
Hinden, concerning a change to the IPAE header, to make it be the same
as the SIP header. (i.e., make IPAE = IP+SIP, plus transition rules.)
This was a somewhat unexpected turn of events, except in hindsight. A
number of forces seem to have been moving us in this direction and there
was a very strong feeling, by the end of the meeting, that this change
vastly cleans up the entire scenario for the Internet, giving it the
least transition pain and the most amenable longer-term protocol, since
it is the closest to current IP AND it has a mechanism for adding new
services (via its own mini-layer.)
Reminder: SIP has a mailing list. To join, send to:
sip-request@caldera.usc.edu
Two other items were covered:
ICMP
The 64-bit data limit for ICMP continues to be a problem. We discussed
more about the handling of ICMP messages sent by interior, unmodified
routers, which therefore contain only the within-commonwealth IP
addresses of the interior router and the border IPAE router and don't
have the full IPAE address of the originating host available.
We had generally believed that this was an unfortunate, but not serious,
problem. It was then observed that it _is_ a significant problem for
MTU Discovery. The originating host really does need to get the ICMP
feedback.
We adopted the framework that a commonwealth which does IPAE/IP
tunneling -- i.e., the interior routers are not IPAE knowledgeable --
can be viewed much the same as IP over X.25, with the border routers
treating the commonwealth as an underlying data-link environment.
Hence, feedback from interior routers is like feedback from interior
X.25 packet switches. We would not expect those raw messages to be
forwarded back to the originating host.
We would expect the border routers to record the feedback and translate
it. In this case, this means that the border router needs to cache MTU
information about IP addresses inside its commonwealth. When it gets an
IPAE datagram, it needs to check its size against the cache (cache =
dest IP addr + MTU) and either fragment the datagram or send back an
1
ICMP Too Big.
Basic language for the spec is: IPAE routers which are the IP
recipients of IP/ICMP messages must cache ``Can't Fragment'' (``Too
Big'').
Router Table Size
We did an extended case analysis of the current and projected sizes for
3 different router tables: The Source Information Base is the raw stuff
that comes in from the routing protocol(s). The Real-Time Table is used
for doing that actual data-handling of actual packets. The Policy table
is whatever set of contingent rules are needed to turn the first table
into the second. I have intentionally not used more typical terms for
the tables, since we ran into some nomenclature confusion during the
discussion.
Note that the IPAE secton is divided into two, since the border routers
need to maintain a set of IPAE routing tables as well as a set of IP
routing tables (for the commonwealth.)
SOURCE INFO BASE REAL-TIME TABLE POLICY
(Variable, xmit (Variable, compute (Static)
+ storage overhead) + storage overhead)
Now: All nets*neighbors All nets All nets
IPAE: (Same as Source All nets
Info Base, but (includes the
IP: Attached cwlth without the IPAE/IP address
nets "* neighbors" map needed during
component) transition while
IPAE: CWlth hierarchy, IP addresses
only as needed. are still unique)
(e.g., [all
countries
+ attached
metro/provider]
* neighbors)
2