Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/sip/sip-pip-minutes-93nov.txt

Text File | 1994-02-08 | 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         [e-mail]
Steve Alexander          [e-mail]
James Allard             [e-mail]
Susie Armstrong          [e-mail]
Randall Atkinson         [e-mail]
Anders Baardsgaard       [e-mail]
William Barns            [e-mail]
Stephen Batsell          [e-mail]
Nutan Behki              [e-mail]
Steven Bellovin          [e-mail]
Tom Benkart              [e-mail]
Ram Bhide                [e-mail]
Erik-Jan Bos             [e-mail]
Jim Bound                [e-mail]
Scott Bradner            [e-mail]
Monroe Bridges           [e-mail]
Ronald Broersma          [e-mail]
Al Broscius              [e-mail]
Ross Callon              [e-mail]
Peter Cameron            [e-mail]
George Chang             [e-mail]
David Conrad             [e-mail]
Matt Crawford            [e-mail]
John Curran              [e-mail]
Michael Davis            [e-mail]
Chuck de Sostoa          [e-mail]
Stephen Deering          [e-mail]
Avri Doria               [e-mail]
Donald Eastlake          [e-mail]
Havard Eidnes            [e-mail]
Robert Enger             [e-mail]
Roger Fajman             [e-mail]
Stefan Fassbender        [e-mail]
Carlos Fernandez         [e-mail]
Eric Fleischman          [e-mail]
Richard Fox              [e-mail]
Paul Francis             [e-mail]
Atanu Ghosh              [e-mail]
Robert Gilligan          [e-mail]
Ramesh Govindan          [e-mail]
Jari Hamalainen          [e-mail]
Herluf Hansen            [e-mail]
Dimitry Haskin           [e-mail]
Marc Hasson              [e-mail]
Robert Hinden            [e-mail]
Kathy Huber              [e-mail]
Christian Huitema        [e-mail]
Phil Irey                [e-mail]
Kevin Jackson            [e-mail]
Ronald Jacoby            [e-mail]
Dale Johnson             [e-mail]
Timo Jokiaho             [e-mail]
Rick Jones               [e-mail]
Akira Kato               [e-mail]
Elizabeth Kaufman        [e-mail]
Hiroshi Kawazoe          [e-mail]
Edwin King               [e-mail]
Andrew Knutsen           [e-mail]
John Krawczyk            [e-mail]
Tony Li                  [e-mail]
Kanchei Loa              [e-mail]
Allison Mankin           [e-mail]
Peram Marimuthu          [e-mail]
Greg Minshall            [e-mail]
Randy Miyazaki           [e-mail]
Andrew Myles             [e-mail]
Rina Nathaniel           [e-mail]
Sath Nelakonda           [e-mail]
Erik Nordmark            [e-mail]
Masataka Ohta            [e-mail]
Steve Parker             [e-mail]
Ismat Pasha              [e-mail]
Michael Patton           [e-mail]
Charles Perkins          [e-mail]
Eric Peterson            [e-mail]
Benny Rodrig             [e-mail]
Michal Rozenthal         [e-mail]
Dallas Scott             [e-mail]
Isil Sebuktekin          [e-mail]
Vincent Shekher          [e-mail]
Ming Sheu                [e-mail]
William Simpson          [e-mail]
Frank Solensky           [e-mail]
James Solomon            [e-mail]
Tae Song                 [e-mail]
Michael Speer            [e-mail]
Vladimir Sukonnik        [e-mail]
Steve Suzuki             [e-mail]
Susan Thomson            [e-mail]
Akihiro Tominaga         [e-mail]
Thuan Tran               [e-mail]
Hoe Trinh                [e-mail]
Keisuke Uehara           [e-mail]
Chuck Warlick            [e-mail]
Chris Wheeler            [e-mail]
Walter Wimer             [e-mail]
Jane Wojcik              [e-mail]
David Woodgate           [e-mail]
Liang Wu                 [e-mail]
Jean Yao                 [e-mail]
Shinichi Yoshida         [e-mail]
Jessica Yu               [e-mail]
Weiping Zhao             [e-mail]