home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
tpix
/
tuba-tpix-minutes-93nov.txt
< prev
Wrap
Text File
|
1994-02-16
|
7KB
|
184 lines
CURRENT_MEETING_REPORT_
Reported by Mark Knopper/Merit
Minutes of the Joint Session of the TUBA and TPIX Working Groups
The two groups met jointly during the second scheduled TUBA session,
primarily to discuss the CATNIP proposal. Several other TUBA items
remained to be discussed after the first meeting.
Ross Callon began by introducing his ideas on CLNP header compression
and flow setup, in relation to the CATNIP ideas. A compressed header
would include a ``handle'' consisting of destination and source
addresses, and quality of service; a data unit identifier; and
time-to-live. This would be compressed into 8 bytes or less. The
handle is similar to a ``source route.''
Rob Ullman presented the CATNIP paper. The CATNIP protocol can be mixed
together on a datalink with IPv4, IPX, and CLNP.
o The header includes: a 4-bit field set to 7 to identify the
protocol; a set of flags (DAO destination address omitted, SAO
source address omitted, RFD report fragmentation done, and MRO
mandatory router option); the Header size (1 byte, in words); time
to live (2 bytes); FCI forward cache identifier (RhandleS);
datagram length (32 bits); transport protocol (16 bits); checksum;
destination and source addresses; and options.
o The MRO bit set to zero means routers do not have to look at
options. The header can be 1020 bytes long, which allows long
source route lists, etc.
o With CATNIP, the NSEL would not have to be used for protocol ID, as
there is a 16-bit transport protocol field.
o Network layer addresses are NSAPs, with AFI, IDI and DSP.
o Internet Addresses would have a length of 7, and include a specific
AFI to be assigned to Internet, and an Administrative Domain
(2-byte code) currently set to 0.0.
o IPX Addresses can be carried by CATNIP, using another AFI (to be
assigned also). The length of the address field for IPX would be
13, and the address field will contain the IPX network number, a
4-byte network identifier followed by a MAC address (IEEE 802
6-byte value or other identifier).
o ISO has offered to do the assignment of the Internet AFI.
Discussion: it could be 39, with Internet having its own ICD.
o IPX network identifiers can now be acquired from Novell. Novell
should acquire an ICD and live under AFI 47.
o Use of FCI may include: flow setup, ICMP feedback, routing
protocol, multicast tree setup, RSVP, SDRP, etc.
Abbreviated summary of discussion:
o OSI routing protocols can be used for CATNIP without changes.
o NSAPs allow multiple address and routing plans.
o Flow setup can be done at the data link layer, and could be
demultiplexed before the network layer, therefore FCI is not needed
in this case.
o Why is there no explicit TOS field? Suggestion: issue ICMP to
turn on TOS for particular cache value, routers store with handle.
o Ross Callon expanded on his earlier comments: What CATNIP is doing
is defining a new protocol that lends itself to compression. Ross
came up with the same approach when trying to come up with a
solution to compression. His approach had 8-bit TTL, no transport
protocol field, moved things around for alignment, used different
FCI handle size, had data unit ID, datagram length smaller, and
total 3 x 32 bit fields. If left in checksum, can omit destination
in some cases.
o FCI is used by a host if the host is participating in reservation
process. The host may want to check if different FCI or zero comes
in, in case of preferred FCI not being chosen (e.g.). But normally
the host is just going to set FCI to zero and ignore the field.
o What is the advantage of carrying IPv4 in CATNIP rather than in a
multiprotocol environment fashion? It is easier to administer
networks based on one protocol, and also easier for router vendors
to optimize one protocol more than others.
o Compression is address omission. This is no more than 60%
compression, or in average cases 50% only. Compression is for slow
links (tradeoff with CPU), or for address removal to allow CPU
saving in router hops. The CDPD (cellular digital packet data)
CLNP compression algorithm gets down to 6-8 bytes.
TUBA Transition Plan (Dave Piscitello)
Dave worked with Tracy Mallory and Jim Bound to develop an outline of a
transition plan.
A transcript of Dave's slides follows:
o ``techniques''
- dual stack: systems encouraged to be dual during transition
- encapsulation:
* IPv4 in CLNP (EIN) and CLNP in IPv4 (EON)
- translation
* mapping CLNP ito IPv4 and reverse (tricky)
o end systems
- principles behind dual stack operation, use of nameservice
o management
- guidelines for SNMP operation, SMI extension, MIBs
- ``Tools'' operation (ping, traceroute, tracedump, tcpdump)
- other tools?
- dynamic configuration
- registry tools for routing
- compression/CATNIP
o nameservice infrastructure, changes to DNS
o multicast groups of IPv4 and TUBA hosts
o applications requiring a change, description/resolution
- ftp, 822mail, boot/discovery protocols, X, NFS/RPC, ``r''
protocols
o APIs (sklower email, DEC idea, etc.)
o NSAPA allocation
o security
o timeframe/timeline
This outline was well received as a good start to a transition plan
paper. Some of the points included in the transcript were comments
added from the attendees. It was also suggested that the transition
plan paper be very clear about where changes are need to hosts as
distinguished from routers.
ISO Liaison (Peter Ford)
Peter gave an overview of the current status of the liaison between ISOC
and ISO.
Vint Cerf and Jack Houldsworth had discussions at the last IETF. ISOC
recently forwarded two letters to ISO---these are Internet-Drafts. Also
there is an Internet-Draft, ``Liaison between Internet and other
Standardization Agencies,'' by Christian Huitema on this topic.
For TUBA, the issue is change control. Lyman Chapin is working on
document distribution. RFC 1310 bis contains language about ceding all
copyright control to IETF from ISO. Document review and comments are
encouraged. The document can be found in the Internet-Drafts directory.
One issue is how can the IETF take documents from other standards bodies
into the Internet Standards process?
Concerning the Memorandum of Understanding between ISO and ISOC, Peter
felt that convergence in the network layer should be suggested. Also
there should be an address change control for the base network protocol
document. The SC6 contribution is in line with this.
Peter Furniss is a SC21 member. Both groups claim to be more open than
the other. ISO did not understand how IETF/ISOC process works and comes
to consensus. Scott Bradner pointed out that RFC 1310 is a description
of our process and can be used to help communicate to other groups.
It was discussed that either ISO can retain change control and IETF can
have official liaison to ISO; or the IETF can take a clone of CLNP and
diverge (with report back to ISO).
CLNP Routing in Europe (Alex Reijnierse)
Alex presented a connectivity diagram of the CLNP Internet from the
European (Europanet) perspective.