CURRENT_MEETING_REPORT_

Reported by Steve Deering/Stanford

Minutes:

This was the third meeting of the Router Discovery Working Group.

Steve Deering started by apologizing for not having produced a draft
specification of the proposed router discovery protocol in time for this
meeting, and promised to do so before the July IETF meeting.

He then reviewed the current proposal, for the sake of newcomers.

The router discovery protocol uses a pair of new ICMP messages:


  o Router Advertisement messages, which are periodically multicast by
    routers.
  o Router Solicitation messages, which may be multicast by hosts at
    start-up time only, to solicit immediate Router Advertisements
    instead of waiting for the periodic ones.


(These were formerly called ``Router Report'' and ``Router Query''
messages, respectively.)

Advertisements are sent to the ``all-hosts'' IP multicast address, and
solicitations are sent to the ``all-routers'' IP multicast address.
Hosts and/or routers may be configured to use IP broadcast addresses
instead, though this is discouraged.  The router discovery protocol is
not applicable to networks that do not support either IP multicast or IP
broadcast.



                                  1






The format of the Router Advertisement message is as follows:



 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |     Code      |           Checksum            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Reserved    |     Count     |         Holding Time          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       Router Address                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                      Preference Level                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       Router Address                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                      Preference Level                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                              .                              |
 |                              .                              |
 |                              .                              |



Type                identifies this as an ICMP Router Advertisement.

Checksum            standard ICMP checksum.

Code and Reserved   zero.

Count               number of (Router Address, Preference Level) pairs
                   included in the message.

Holding Time        number of seconds that hosts should consider the
                   information in this message to be valid.

Router Address      one of the sending router's IP addresses on the
                   physical network on which this message is sent.

Preference Level    preferability of the preceding router address as a
                   default router address, relative to other router
                   addresses belonging to the same IP subnet.



The usual case in which a router has more than one address on a single
physical network is when that network is supporting more than one IP
subnet.  A receiving host is expected to ignore those (Router Address,
Preference Level) pairs that do not belong to the same IP subnet as the

                                  2






host.  (This implies that a host must know its own IP address and subnet
mask before it may use the information in a Router Advertisement
message.)



                                  3






The format of the Router Solicitation message is as follows:



 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |     Code      |           Checksum            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Reserved                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Type                identifies this as an ICMP Router Solicitation.

Checksum            standard ICMP checksum.

Code and Reserved   zero.



The group then discussed a number of topics that had been raised on the
mailing list since the previous meeting.


  o Preference Level field
    Deering tried again to convince the group that the Preference Level
    field was unnecessary and undesirable, and again he failed.  It was
    agreed that the field shall be present in the Router Advertisement
    messages, if for no other reason than that the Host Requirements
    document requires a preference level to be associated with each
    default router (even though it does not require hosts to do
    anything with it).
    Deering then proposed that the Preference Level be encoded as a
    signed, 32-bit, twos-complement integer, such that a higher value
    means more preferable.  A router that is not configured with a
    specific preference level (or that does not compute its own
    preference level, based on routing information), will advertise a
    level of 0.  The minimum level (80000000 hex) is reserved to
    indicate routers that must not be used as default routers (i.e.,
    that may be used only for specific destinations, of which the hosts
    have been informed by ICMP Redirect or static configuration).
    Greg Satz had proposed that a router's preference level be derived
    from that router's metric for its ``default'' route, rather than
    from manual configuration.  After some discussion of the merits and
    weaknesses of that approach, it was agreed that it would be allowed
    but not required by the router discovery specification.  It was
    noted that a routing metric will normally have to be converted to a
    preference level, rather than being used directly, since for most
    routing metrics, smaller values mean more preferable.

                                  4






 No objections were raised to Deering's proposed encoding for the
 Preference Level field.
o multicast vs.  unicast replies to Solicitations
o dallying
 Two unresolved issues were:  should Advertisements sent in response
 to Solicitations be multicast or unicast, and should randomized
 delays be required before Solicitations and/or before responding
 Advertisements?  Some people felt that dallying before
 Solicitations was important to prevent massive collisions when a
 LANful of hosts all boot at once, for example, after power is
 switched on (in a classroom, say) or is restored after a power
 failure.  After much debate, it was agreed that hosts should dally
 for a short, random interval (between 0 and 1 seconds was
 suggested) before sending a Solicitation.  If a host receives an
 Advertisement while dallying, it should refrain from sending a
 Solicitation.
 The optimal router behavior in response to a Solicitation is not at
 all clear -- a case was made for dallying or not, and for either
 unicast or multicast responses.  Therefore, this will be left to
 the implementors' discretion for now, with a suggestion that the
 behavior be configurable.  The group would welcome any analysis,
 simulation results, or reports of field experience that might favor
 a particular behavior.
o periodic advertising rate
 Another outstanding issue was how often the periodic, unsolicited
 Advertisements should be sent.  The choice depends on whether or
 not the advertisements are being used for black-hole detection, in
 addition to simple router discovery.  For black-hole detection, the
 advertising rate must be high enough to allow router failures to be
 detected before transport connections fail (an interval of 10
 seconds is the value used for this purpose in the ISO ES-IS
 protocol).  If the advertisements are only used for router
 discovery, a much longer interval (10 minutes, say) would be
 adequate -- in this case the periodic advertisements serve only for
 recovery from the situation in which hosts and routers boot up on
 different sides of a subnet partition, which is later healed.
 In the absence of agreement on how black-hole detection should be
 done, the advertising interval must be configurable.  The initial
 version of the document will suggest a default interval of 10
 minutes.  Subsequent decisions on black-hole detection may cause a
 smaller default value to be recommended.
o black-hole detection
 Once the router discovery specification has been agreed upon, it
 has been suggested that this working group might turn its attention
 to the black-hole detection problem.  A general discussion of the
 problems and possible solutions ensued, with no agreements being
 reached.  (It was pretty much a rehash of previous discussions on
 the group mailing list; an archive of those messages is available
 for the interested reader.)



                               5






Action Items


  o Deering to generate a draft Router Discovery specification before
    the July IETF meeting.
  o Experimental implementations of the proposed protocol to be
    developed and deployed -- no promises, but Andrew Cherenson and
    John Veizades both offered to help (presumably for Unix and for the
    Macintosh OS, respectively), as soon as Deering gets the
    specification done.  Greg Satz has previously offered the source
    code for his BSD Unix implementation of cisco's Gateway Discovery
    Protocol (GDP) as one possible starting point.


Next Meeting

The Router Discovery Working Group will next meet in Vancouver, at the
July/August IETF meeting.



                                  6






ATTENDEES


   Pat Barron               [email protected]
   Fred Bohle               [email protected]
   Steven Bruniges
   David Burdelski          [email protected]
   Duane Butler             [email protected]
   John Cavanaugh           [email protected]
   Andrew Cherenson         [email protected]
   Noel Chiappa             [email protected]
   Steve Deering            [email protected]
   Dave Forster
   Richard Fox              [email protected]
   Karen Frisa              [email protected]
   Steve Hubert             [email protected]
   Van Jacobson             [email protected]
   Stev Knowles             [email protected]
   Yoni Malachi             [email protected]
   Keith McCloghrie         [email protected]
   Leo J. McLauglin III     [email protected]
   Jeff Mogul               [email protected]
   John Moy                 [email protected]
   Mike Patton              [email protected]
   Drew Perkins             [email protected]
   Stephanie Price          [email protected]
   Michael Reilly           [email protected]
   Greg Staz                [email protected]
   Tim Seaver               [email protected]
   Frank Slaughter          [email protected]
   Richard Smith            [email protected]
   Brad Strand              [email protected]
   Cal Thixton              [email protected]
   John Veizades            [email protected]
   Jonathan Wenocur         [email protected]



                                  7

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.