home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
sipp
/
sipp-minutes-93nov.txt
< prev
next >
Wrap
Text File
|
1994-02-19
|
30KB
|
753 lines
CURRENT_MEETING_REPORT_
Reported by Robert Hinden/Sun Microsystems
Minutes of the Joint Sessions of the SIP and PIP Working Groups
These minutes are based on the notes taken by Christian Huitema and Bob
Hinden.
The Simple Internet Protocol Working Group (SIP) and the P. Internet
Protocol Working Group held two joint sessions. The first session was
on Monday, November 1. The second session was held on November 4. Both
sessions were carried on the Internet Multicast.
The agenda distributed prior to the meeting was reviewed and updated for
the meeting.
SIPP Merger Overview (Steve Deering)
The purpose of the merger is to keep the simplicity and transition
features of SIP and the advanced routing capabilities of Pip---while
making them easier to use and to understand. The mailing lists have
been merged, and Bob Hinden is writing a charter for the merged group.
This has resulted in some changes in the specifications, and in some
terminologies. The changed terms are:
SIP --> SIPP
system --> node
anyone address --> cluster address
Source route header --> Routing header
The new terminology:
o The uniqueness scope of an address; for example the uniqueness
scope of the loopback address is just one single node.
o The routing scope of an address, which is generally global to the
Internet, but can sometimes be restricted e.g., for a ``local use
address.''
Routing scope is always less than uniqueness scope, but not necessarily
equal to it.
SIPP Overview and Issues (Steve Deering)
The address semantics have changed. Addresses identify nodes or set of
nodes, not interfaces. A node may have several addresses, which may, in
some instances, be tied to an interface.
The packet format has not changed, except for the ``reserved'' field
which is now called ``flow label.'' The 64-bit addresses are still
composed of an IP address and a 32-bit prefix. The 64-bit SIPP address
space is 10 million times larger than the global telephone number space.
The address formats are:
- classic: prefix, customer ID, node ID.
-----------------------------------------
|c| provider ID | customer ID | node ID |
-----------------------------------------
- cluster:
-----------------------------------------
|c| provider ID | 0...................0 |
-----------------------------------------
- local use address:
-----------------------------------------
| 0..0 | subnet | IEEE 802 address |
-----------------------------------------
- multicast address:
-----------------------------------------
| 1..1 | flags + | group ID |
| | scope | |
-----------------------------------------
The addresses are ``provider oriented.'' The current SIP addressing
drafts are obsolete. New SIPP versions will be submitted.
Options are encoded as a sequence of headers. SIPP options currently
defined are fragmentation, routing and hop-by-hop options. Options for
end-to-end security and flow set-up are under development. Options are
not limited to 40 bytes like IP.
The format of the routing header is:
--------------------------------------------
| Payload | Number of | Next | Reserved |
| | Addresses | Address | |
--------------------------------------------
| Reserved |
| |
--------------------------------------------
| |
+ Address[0] +
| |
--------------------------------------------
| |
+ Address[1] +
| |
--------------------------------------------
| |
. .
. .... .
. .
| |
--------------------------------------------
| |
+ Address[n] +
| |
--------------------------------------------
The minimum packet length has not changed. The routing header uses
64-bit chunks rather than the 16-bit chunks of Pip. Paul Francis
mentioned that the advantage of this approach was ``simplicity of
handling.'' The addresses have their own routing scope, which relieves
the need for the ``routing contexts'' which were present in Pip.
Noel Chiappa observes that the routing header is more traditional source
routing rather than Pip ``flows.'' Paul Francis said this was incorrect
and that the Pip routing was not intended as flows.
The 28 bits of the flow-label will be structured according to one of two
possible formats:
----------------------------------------
| DP | 0 | TOS|
----------------------------------------
----------------------------------------
| DP | flow-ID |
----------------------------------------
o 4 bits of ``drop priority''
o 4-bit TOS is traditional IP type of service
o 24-bit flow-ID is a pseudo random number chosen by source to
identify special flow state along path
The reason that the flow-ID is random, based on an idea from Dave Clark,
is that it makes it easy to use a subset of it (bit slice) as a ``hash
code'' for access to a flow table within the routers. To a question on
TOS, it is observed that this really is a heritage from IPv4, although
current experience in IPv4 networks is rather bleak. There was
considerable discussion leading to the suggestion to drop IPv4 TOS.
SIPP Routing and Addressing (Paul Francis, Ramesh Govindan)
Paul Francis presented the use of the routing header. All packets are
identified with 64-bit addresses which are unique with the scope, but
may need additional 64-bit addresses to complement an insufficient
routing scope. There is also a need for mobile hosts, or when special
policies are required.
The SIPP addresses are contiguous bit-wise maskable (similar to IP with
CIDR). This poses conditions for extended addresses:
o Single hierarchy element cannot straddle 64-bit boundary.
o Top and bottom 64 bits have to be both globally unique; one could
perhaps release this requirement for ``middle'' addresses.
Currently SIPP assumes hierarchical provider addresses.
The cluster address is similar to an ``anycast address,'' i.e., it
addresses any of the routers sharing a prefix. If a packet arrives from
``outside,'' it is accepted by the first node that matches the prefix;
if from within the node, it is accepted by the first router that
operates at ``that prefix length.'' In the current state of the art,
they will have to be ``hand configured.''
Examples of such addresses are:
o Provider.0: accepted by first router in provider network, used for
provider selection.
o Provider.subnet.0: can be used for mobility support.
The local use addresses provide an 8-bit fixed prefix and an 8-bit
``subnet number'' in complement to the 48-bit IEEE-802 address. The
local use addresses can be used over a multi-subnet site. It could be
used exclusively for a site not connected to the Internet.
The address sequence has to be ``manipulated'' by the hosts. This is
really what the merger with Pip is all about. Note that the SIPP header
format did not change in the merger.
Hosts should be able to:
o Represent their own address as a sequence, not just a single 64-bit
address.
o Reverse an address sequence.
If hosts do this from the start, new semantics can be added to the
Internet, for example extended addresses, without having to update any
internet hosts.
The group mentions that there should be a minimum size specification,
e.g., ``at least three components.'' This applies to local
configuration, nodes should be able to process arbitrarily long routing
headers. Similarly, a limit is needed for DNS configuration (size of
record) and for ``reverse look up'' in the DNS (depth of the tree).
Also, the ``error behavior'' should be specified -- what should be done
if the host receives a packet that it cannot understand.
Paul then presented the literal notation for the source route mechanism:
<X, Y, Z>. Two kinds of address sequence have been defined: source
capable and not source capable. For example, a multicast address is not
``source capable'': it cannot be used as a source address in a packet.
Suppose a sequence <S0, S1, .. , Si, Dj, Dj-1, .. D0>, i.e., the
source chain then the destination chain. In most cases the chain will
have exactly two elements <S, D>. This was only true in Pip for local
communications. Paul presented the mechanism for building and reversing
source routes, and mentioned the open issue: whether routes should be
stored in the internet program, in the transport or in the application.
Ramesh Govindan presented different examples of sophisticated routing
using the SIPP routing header. This included:
o Basic routing involving only the DNS. Sequence has two elements,
reversal is trivial.
o Selection of the first hop provider. Sequence has three elements;
change of provider within the association life time is easy.
o Item with ``extended addresses,'' with four elements in the
sequence.
o Examples are also given for multicast, including source routing
prior to multicasting.
o Multicast is also possible with extended addresses: this allows
recipients to reply to the source address.
o Mobility examples are also given: the address sequence includes
the identification of the ``base station.'' Note that the ``mobile
cluster'' scenario is not presented! Address extension can also be
used for auto-configuration:
1. Hosts creates a ``local wire'' address.
2. Host will receive a local cluster address, e.g., by receiving
advertisement. It can combine his hardware address with this
prefix, to form either a 64-bit address if the prefix is short
enough, or an extended address otherwise.
Several members of the group question the ``automatic reversal'' of
source routes in the case of ``provider selection.'' There are clearly
several degrees of liberty at this stage.
IPAE Specification Overview and Issues (Bob Gilligan/Erik Nordmark)
A new specification has been written by Bob Gilligan, Erik Nordmark and
Bob Hinden. This is based on the original specification by Dave
Crocker, and one year of work and discussion. The components of the
specification are:
o Encapsulation within IPv4 for ``tunnelling.''
o 64-bit SIPP addressing scheme is compatible with IPv4 plan:
6 6 3 3 0
3 2 2 1 0
+---+-------------+--------------+
| c | Site Prefix | IPv4 address |
+---+-------------+--------------+
The ``c'' bit explains whether the host is SIPP capable or not.
o Host algorithms for direct interoperability with IPv4 hosts.
o Translation agent between SIPP and IPv4.
Bill Simpson questioned the change of vocabulary from ``commonwealth''
to ``site''---as commonwealth implied a larger kind of object. Steve
Deering believes no name for these objects is really needed. Christian
Huitema noted the need for a conventional 32-bit prefix, removing the
need for ``mapping tables'' as long as hosts are capable of IP routing.
John Curran mentioned the relation between site table and provider IDs:
if one changes provider, then one changes prefixes, thus one has to
change the ``mapping table.'' The upper 32 bits carry an assumption
about provider connectivity. The picture has changed a lot since the
advent of CIDR; if CIDR really solves the routing table explosion, then
the ``mapping table'' is not necessary. As Steve Deering mentions, the
group really hates the mapping tables.
Jim Bound mentioned the complexity of transition for a host, and
suggested that the group emphasize the inherent simplicity of the 64-bit
approach.
A list of remaining IPAE issues came out when revising the
specification.
o How do translators set the IPv4 ID field when doing SIPP to IPv4
translation? One idea was to keep a counter for IDs, another to
put a hash function, a third to use a pseudo random generator.
o What to do with the TOS field? Should it map to SIPP
TOS/Channel-ID? There is no general consensus. Dave Clark supports
that TOS are complementary to channel IDs, which may lead to
revisit the specification versus TOS and Drop preferences.
o How should translators handle IPv4 packets with the DF bit set?
Erik Nordmark shows the following scenarios:
____________________________________________
|_Ipv4_Source__SIPP____________IPv4_________|
| |
| DF not set Fragment to 576 copy ID |
| incl frag head DF not set |
| |
|_DF_set_______No_frag_header__DF_set,_ID=0_|
___________________________________________
|_SIPP_source____IPv4______________________|
| |
| Frag header Copy ID field |
| DF not set |
| |
| No frag header Generate pseudo unique ID |
|________________DF_not_set_______________ |
This last case is ugly. One could in fact mandate the presence of
the fragmentation header whenever a SIPP host sends a packet to an
IPv4 host. The ``c'' bit in the source address mentions the real
source, but using it is not very elegant. So, the decision is to
correct the last case to:
________________________________
|_SIPP_source____IPv4___________|
| |
| Frag header Copy ID field |
| DF not set |
| |
| No frag header Generate ID = 0|
|________________DF_set_________|
This implies that the rules for MTU discovery have to be changed.
If a host receives a ``packet too long'' ICMP with a length lower
than the minimum length, then it should send the next packet with
the fragment header! The group agreed to this.
o Should IPAE hosts be required to do path MTU discovery on their
tunnels? Steve Deering explains that the MTU can sometimes be
lower than the 576 minimum, which will imply using fragmentation.
The idea is that MTU discovery should be recommended, but still
optional.
o ICMP checksum: using a different checksum for IP and SIPP version
of ICMP is really a pain. The consensus was that correctness is
more important than the complexity in this case.
Erik Nordmark presented the problems of keeping state when
``tunnelling'' is used:
o ICMP packet too big: Need to memorize the tunnel MTU, for either
immediate transcription.
o ICMP TTL exceeded: Need to memorize the tunnels TTL,
o ICMP ``unreachable'': Signals an incorrect tunnel.
These ``states'' should really be ``soft state,'' i.e., updated
cautiously. The SIPP design helps the error handling, as the initial
hop limit was present in the first bytes of the packet. This helps
computing the ``exact length'' of the tunnel.
The state can be discarded for garbage collection (reduce the memory
requirement) and also for detecting improvements -- for example if a
remote router suddenly becomes reachable. The MTU increases will
regularly be probed by the source, so the absence of remote ICMP may be
an indication of the absence of problem.
Neighbor Discovery/ARP (Bill Simpson)
The protocol has been renamed ``neighbor discovery'' after the merging.
It has two packets: ``where are you'' stating the address looked for,
and ``I am here,'' with variable parameters. All packets include a
``media type'' and ``MAC address'' parameter, so that one does not need
ARP.
Bill questioned the need for further usage of the ``change prefix''
parameter, which is used to broadcast ``changes of providers.'' This is
now well done, with prefix length, old address and new address.
Another questioned feature was the passing of information about other
routers and other subnets---use discovery as a router protocol, or at
least as a replacement for ``OSPF hellos.'' The particular format of
this ``routing information'' is hotly debated; in particular it is
suggested to separate information on the router address and information
on the ``connected subnets.'' For each subnet, there are
``preferences'' and ``priority,'' as well as a ``zone'' used for local
addresses, and ``MRU'' indicating the maximum packet length used by the
routers. The utility of several fields, or even the very utility of
this parameter, is debated:
o MRU is generally understood as ``not needed.''
o The parameters taken from OSPF and IS-IS should go away.
o ``Zone'' is an inappropriate name for ``local scope subnets,''
which should just be passed as particular subnets.
The ``system heard'' parameter is essential for support of eliminating
the ``hidden transmitter'' problem. For each system heard, this pass
various parameters: quality of reception, advertisement number, etc.
This seems too complex to many listeners.
Steve Deering requested the removal of the ``service advertisements.''
Bill also presented ``transit informations'' and ``redirects.'' Further
discussion is clearly needed!
SIPP OSPF (Rob Coltun)
Rob proposes the acronym ``OSPPF'': bigger addresses, more protocols.
For carrying big addresses, one needs to:
o Provide ``link state ID'' independent of address. Currently, an
LSA is identified by [Router ID, LS-ID], where LS-ID represents the
``network number.'' A 32-bit locally unique ID will be used in
OSPPF.
o Advertisement will have to carry long address in addition to LS-ID.
The schema of the LSA is:
----------------------
| Advertising router |
----------------------
| Link State ID |
----------------------
| Type |
----------------------
| |
| Address |
| |
----------------------
| Router ID |
----------------------
| ... |
----------------------
There is agreement that the ``advertising router'' should be a 64-bit
field; in general, routers should be identified by their 64-bit
identifying address. The LSA is identified by the combination of
advertising router and LS-ID; the LS-ID has to be unique within the
router, i.e. can be a random 32-bit number. It is not even necessary
to keep the same number during different ``instantiations,'' e.g., after
a reboot, as the old segments will either be replaced or fade away.
Indeed, this implies that the LS-ID cannot be overloaded.
For the big addresses, one has to carry a length field (in bytes) and
the number of significant bits; thus it makes sense to also carry a
``type'' field, which enables for running other protocols in parallel:
-----------------------------
| Type | Len | Mask size |
-----------------------------
| Address |
-----------------------------
| |
-----------------------------
The ``type'' field is used to specify e.g., IP or SIPP, which means that
OSPPF has dual protocol capability.
Rob then addressed the ``hierarchical'' problem. Two levels are
probably enough (200 routers per area imply 40,000 routers). It is easy
to do a multiple level version, e.g., to accommodate regionals which
want to integrate their clients as OSPF areas, and also because inter
domain routing requires a lot of work. There is however a general
agreement that such developments should be discussed in the OSPF group,
and that the SIPP version should really be a straight forward
transcription of OSPF to 64-bit addresses.
SIPP Service Interfaces and DNS Changes (Sue Thomson)
Sue Thompson presented the changes to the DNS for storing address
sequences and for supporting the transition. These are:
o A new ``ASEQ'' record, a sequence of 64-bit elements, which does
not cause additional processing.
o A new ``inverse look-up name,'' which was defined similarly to that
of the initial SIP, and used a PTR query. There is however a
consensus on a ``per octet'' break up that seems more rational
given the ``bit mask'' nature of the address. This will be
represented as a sequence of hex tokens, without leading zeros.
Jim Bound would like the DNS interfaces to strip the upper parts of the
address sequence when they are not necessary. This will have to be
specified in the routing architecture.
There are two transition issues:
1. Whether resolvers should return A records if no ASEQ address is
present. According to Sue, resolvers will have to ask for both
ASEQ and A.
2. Whether the additional section should only include A records, or
also ASEQ records. Decision is that if the query is received from
a SIPP host, then ASEQ should also be returned.
Sue is going to implement the specification in bind 4.9.
Auto Configuration and DHCP (Jim Bound)
The DHCP protocol is very straightforward. DHCP is sitting in the
application layer, so has to traverse the entire stack; after a simple
``connection'' exchange, the client is returned a set of configuration
information, e.g., an address. In some cases, databases have to be
updated. Steve Deering mentioned that dynamic updates of the DNS are
not really required; one might as well preallocate name and address
types.
John Wroklavski mentioned that auto-configuration is the ``single most
important'' design part of IPng; it should work in a large set of
environments. Jim Bound mentioned that DHCP can really be used without
problem, and that making a SIPP option is really straightforward.
Ohta asked whether SIPP/DHCP will have ``relay agents.'' In fact, we
don't need them as SIPP stations can very easily use a hardware address.
Thus, the group will be able to use multicast to find the DHCP server,
including with diameters larger than 1 (outside the local net): there
is no need for relays, routers do the job easily. Paul Francis proposed
to write a specific document explaining how network layer mechanisms can
be used to help auto-configuration, but also for discovering DNS
servers, gopher servers, etc. Jim insisted that we have to be concerned
by automatic configuration of the DNS, i.e., register automatically IP
address and DNS name bindings.
Jim Bound will prepare a ``64-bit'' version of DHCP.
Address Assignment Issues (Paul Francis)
Given the difficulties of managing geographic addresses, there is
agreement that only ``provider'' addresses should be used in the short
term. The immediate assignment is:
-----------------------------
|1| 31 bits | 32 bits |
|C| something | IP address |
-----------------------------
Detail of IP address under CIDR:
-----------------------------------------------------
| Provider ID | Subscriber ID | subnet ID | Node ID |
-----------------------------------------------------
Without CIDR, the address is:
-----------------------------------------------------
| network number | subnet ID | Node ID |
-----------------------------------------------------
These addresses will be a ``legacy'' of the pre-CIDR era. Provider,
subscriber, subnet and host is a good hierarchy; but eventually growth
will force us beyond 32 bits. Thus, at least the provider ID should be
pushed into the higher 31 bits of the SIPP address.
The proposal is to:
o Push provider part in upper 31 bits.
o Leave room below provider for subscriber and ``subProvider'' parts.
o Leave room above provider ID for contingencies.
This gives the following structure:
--------------------------------------------------------------
| 8 bits | 24 bits | m bits | p bits | 32-m-p |
--------------------------------------------------------------
| C 0..0 | provider Id | subscriber Id | subnet ID | Node ID |
--------------------------------------------------------------
The provider ID will be assigned ``from the left,'' which means that
they are followed by a number of zeros, which allow for future growth of
the ``subscriber ID'' part. There was a general consensus to proceed
with this plan for address assignment.
Attendees
Kenneth Albanese albanese@icp.net
Steve Alexander stevea@lachman.com
James Allard jallard@microsoft.com
Susie Armstrong susie@mentat.com
Randall Atkinson atkinson@itd.nrl.navy.mil
Anders Baardsgaard anders@cc.uit.no
William Barns barns@gateway.mitre.org
Stephen Batsell batsell@itd.nrl.navy.mil
Nutan Behki nebhki@newbridge.com
Steven Bellovin smb@research.att.com
Tom Benkart teb@acc.com
Ram Bhide ram@nat.com
Erik-Jan Bos erik-jan.bos@surfnet.nl
Jim Bound bound@zk3.dec.com
Scott Bradner sob@harvard.edu
Monroe Bridges monroe@cup.hp.com
Ronald Broersma ron@nosc.mil
Al Broscius broscius@bellcore.com
Ross Callon rcallon@wellfleet.com
Peter Cameron cameron@xylint.co.uk
George Chang gkc@ctt.bellcore.com
David Conrad davidc@iij.ad.jp
Matt Crawford crawdad@fncent.fnal.gov
John Curran jcurran@nic.near.net
Michael Davis mike@dss.com
Chuck de Sostoa chuckd@cup.hp.com
Stephen Deering deering@parc.xerox.com
Avri Doria avri@locus.com
Donald Eastlake dee@skidrow.lkg.dec.com
Havard Eidnes havard.eidnes@runit.sintef.no
Robert Enger enger@seka.reston.ans.net
Roger Fajman raf@cu.nih.gov
Stefan Fassbender stf@easi.net
Carlos Fernandez carlos@plk.af.mil
Eric Fleischman ericf@atc.boeing.com
Richard Fox rfox@metricom.com
Paul Francis Francis@thumper.bellcore.com
Atanu Ghosh atanu@cs.ucl.ac.uk
Robert Gilligan Bob.Gilligan@Eng.Sun.Com
Ramesh Govindan rxg@thumper.bellcore.com
Jari Hamalainen jah@rctre.nokia.com
Herluf Hansen hha@tbit.dk
Dimitry Haskin dhaskin@wellfleet.com
Marc Hasson marc@mentat.com
Robert Hinden hinden@eng.sun.com
Kathy Huber khuber@wellfleet.com
Christian Huitema Christian.Huitema@sophia.inria.fr
Phil Irey pirey@relay.nswc.navy.mil
Kevin Jackson kjackson@concord.com
Ronald Jacoby rj@sgi.com
Dale Johnson dsj@merit.edu
Timo Jokiaho timo.jokiaho@ntc.nokia.com
Rick Jones raj@cup.hp.com
Akira Kato kato@wide.ad.jp
Elizabeth Kaufman kaufman@biomded.med.yale.edu
Hiroshi Kawazoe kawazoe@trl.ibm.co.jp
Edwin King eek@atc.boeing.com
Andrew Knutsen andrewk@sco.com
John Krawczyk jkrawczy@wellfleet.com
Tony Li tli@cisco.com
Kanchei Loa loa@sps.mot.com
Allison Mankin mankin@cmf.nrl.navy.mil
Peram Marimuthu peram@wg.com
Greg Minshall minshall@wc.novell.com
Randy Miyazaki randy@lantron.com
Andrew Myles andrew@mpce.mg.edu.au
Rina Nathaniel rina@rnd-gate.rad.co.il
Sath Nelakonda sath@lachman.com
Erik Nordmark nordmark@eng.sun.com
Masataka Ohta mohta@cc.titech.ac.jp
Steve Parker sparker@ossi.com
Ismat Pasha ipasha@icm1.icp.net
Michael Patton map@bbn.com
Charles Perkins perk@watson.ibm.com
Eric Peterson elpeterson@eng.xyplex.com
Benny Rodrig brodrig@rnd-gate.rad.co.il
Michal Rozenthal michal@fibronics.co.il
Dallas Scott scott@fluky.mitre.org
Isil Sebuktekin isil@nevin.bellcore.com
Vincent Shekher vin@sps.mot.com
Ming Sheu msheu@vnet.ibm.com
William Simpson Bill.Simpson@um.cc.umich.edu
Frank Solensky solensky@ftp.com
James Solomon solomon@comm.mot.com
Tae Song tae@novell.com
Michael Speer michael.speer@sun.com
Vladimir Sukonnik sukonnik@process.com
Steve Suzuki steve@fet.com
Susan Thomson set@bellcore.com
Akihiro Tominaga tomy@sfc.wide.ad.jp
Thuan Tran thuan@xylogics.com
Hoe Trinh htrinh@vnet.ibm.com
Keisuke Uehara kei@cs.uec.ac.jp
Chuck Warlick chuck.warlick@pscni.nasa.gov
Chris Wheeler cwheeler@cac.washington.edu
Walter Wimer walter.wimer@andrew.cmu.edu
Jane Wojcik jwojcik@bbn.com
David Woodgate David.Woodgate@its.csiro.au
Liang Wu ltwu@bellcore.com
Jean Yao yao@cup.hp.com
Shinichi Yoshida yoshida@sumitomo.com
Jessica Yu jyy@merit.edu
Weiping Zhao zhao@nacsis.ac.jp