[dhcwg] Revised updates for transmisssion and retransmission

Ralph Droms <rdroms@cisco.com> Mon, 17 September 2001 13:51 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12511; Mon, 17 Sep 2001 09:51:34 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00520; Mon, 17 Sep 2001 09:46:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00489 for <dhcwg@optimus.ietf.org>; Mon, 17 Sep 2001 09:46:11 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12419 for <dhcwg@ietf.org>; Mon, 17 Sep 2001 09:46:08 -0400 (EDT)
Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-183.cisco.com [161.44.149.183]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA28520 for <dhcwg@ietf.org>; Mon, 17 Sep 2001 09:44:51 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010917094320.00b4dc08@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 17 Sep 2001 09:44:32 -0400
To: dhcwg@ietf.org
From: Ralph Droms <rdroms@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [dhcwg] Revised updates for transmisssion and retransmission
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org

Here is the text for transmission and
retransmission, based on Bernies's
feedback.  I copied come of Bernie's comments
back into this text, along with my responses
and edited text.

Several of Bernie's comments referred to
issues that will be addressed by or
otherwise depends on the text being
generated for IAs.  Additional changes
to this text will be made once the text
for IAs has been finalized.

- Ralph


7.5. Configuration Variables

    This section presents a table of client and server configuration
    variables and the default or initial values for these variables.

BV> Didn't we want to drop this retransmission parameter option
BV> since it opens up many cans of worms as per the San Diego IETF?
RD> Dropped sentence: "The client-specific variables MAY be configured
RD> on the server and MAY be delivered to the client through the "DHCP
RD> Retransmission Parameter Option" in a Reply message.


       Parameter      Default Description
    -------------------------------------
    MIN_SOL_DELAY           1 MIN (secs) to delay 1st mesg
    MAX_SOL_DELAY           5 MAX (secs) to delay 1st mesg
    ADV_TIMEOUT           500 SOL Retrans timer (msecs)
    ADV_MAX_RT             30 MAX timer value (secs)
    SOL_MAX_ATTEMPTS        0 MAX attempts (0 = infinite)
    REP_TIMEOUT           250 Retrans timer (msecs) for Reply
    REP_MAX_RT              0 MAX Retrans time (0 = infinite)
    REQ_MAX_ATTEMPTS       10 MAX Request/Confirm/Renew/Rebind attempts
    REL_MSG_ATTEMPTS        5 MAX Release/Decline attempts
    SRVR_PREF_WAIT          2 Advertise Collect timer (secs)



13. Reliability of Client Initiated Message Exchanges

    DHCP clients are responsible for reliable delivery of messages in the
    client-initiated message exchanges described in sections 14 and 15.
    If a DHCP client fails to receive an expected response from a server,
    the client must retransmit its message.  This section describes the
    retransmission strategy to be used by clients in client-initiated
    message exchanges.

    The client begins the message exchange by transmitting a message to
    the server.  The message exchange terminates when either the client
    successfully receives the appropriate response or responses from a
    server or servers, or when the message exchange is considered to have
    failed according to the retransmission mechanism described below.

    The client retransmission behavior is controlled and describe by five
    variables:

       RT     Retransmission timeout

       IRT    Initial retransmission time

       MRC    Maximum retransmission count

       MRT    Maximum retransmission time

       MRD    Maximum retransmission duration

       RAND   Randomization factor

    With each message transmission or retransmission, the client sets RT
    according to the rules given below.  If RT expires before the message
    exchange terminates, the client recomputes RT and retransmits the
    message.

    Each of the computations of a new RT include a randomization factor
    (RAND), which is a random number chosen with a uniform distribution
    between -0.1 and +0.1.  The randomization factor is included to
    minimize synchronization of messages transmitted by DHCP clients.
    The algorithm for choosing a random number does not need to be
    cryptographically sound.  The algorithm SHOULD produce a different
    sequence of numbers from each invocation of the DHCP client.

    RT for the first message transmission is based on IRT:

       RT = IRT + RAND*IRT


    RT for each subsequent message transmission is based on the previous
    value of RT:

       RT = RTprev + RAND*RTprev

    MRT specifies an upper bound on the value of RT. If MRT has a value
    of 0, there is no upper limit on the value of RT. Otherwise:

     if (RT > MRT)
        RT = MRT + RAND*MRT


    MRC specifies an upper bound on the number of times a client may
    retransmit a message.  If MRC has a value of 0, the client MUST
    continue to retransmit the original message until a response is
    received.  Otherwise, the message exchange fails if the client
    attempts to transmit the original message more than MRC times.

    MRD specifies an upper bound on the length of time a client may
    retransmit a message.  If MRD has a value of 0, the client MUST
    continue to retransmit the original message until a response is
    received.  Otherwise, the message exchange fails if the client
    attempts to transmit the original message more than MRD seconds.

BV> Just to be clear, might be good to say that EITHER or BOTH of
BV> MRC or MRD can stop retransmissions? In most cases it appears
BV> that only one is active, but it is always possible that both
BV> could be.
RD> Added following paragraph.

    If both MRC and MRD are non-zero, the message exchange fails whenever
    either of the conditions specified in the previous paragraph are met.


14. DHCP Server Solicitation

    This section describes how a client locates servers.  The behavior
    of client and server implementations is discussed, along with the
    messages they use.


[...]

14.3. Client Behavior

    A client uses the Solicit message to discover DHCP servers configured
    to serve addresses on the link to which the client is attached.

BV> While probably not something that is needed in this section, we
BV> really don't have much text to describe the "transaction-ID". All
BV> we generally say is to "generate a transaction ID". However, we
BV> should make it clear to clients that they should attempt to
BV> generate "unique" transaction ids. Unique here is best if it is
BV> over a long period of time, but it must be longer than any cache
BV> times in servers. Probably the best rule of thumb is for clients
BV> to use to generate this number by incrementing it. Then the only
BV> issue is what to set it to when (re)booting - especially if there
BV> is no means to remember the last used number.
RD> Added section 14.3.1

14.3.1. Use of Transaction-ID field

    The "transaction-ID" field holds a value used by clients and servers
    to synchronize server responses to client messages.  A client SHOULD
    choose a different transaction-ID for each new message it sends.  A
    client MUST leave the transaction-ID unchanged in retransmissions of
    messages.


14.3.2. Creation of Solicit messages

    The client sets the "msg-type" field to SOLICIT. The client generates
    a transaction ID and inserts this value in the "transaction-ID"
    field.

    The client includes a DUID option to identify itself to the server.
    The client MUST include options for any IAs to which it wants the
    server to assign addresses.  The client may include addresses in the
    IAs as a hint to the server about addresses for which the client
    may have a preference.  The client MAY include an Option Request
    Option in the Solicit message.  The client MUST NOT include any other
    options except those specifically allowed as defined by specific
    options.


14.3.3. Transmission of Solicit Messages

    The client sends the Solicit message to the All_DHCP_Agents multicast
    address.  The client MUST use an address assigned to the interface
    for which the client is interested in obtaining configuration
    information as the source address in the IP header of the datagram
    carrying the Rebind message, with the destination port set to 547.
    The source port selection can be arbitrary, although it SHOULD be
    possible using a client configuration facility to set a specific
    source port value.

    The client's first Solicit message on the interface MUST be delayed
    by a random amount of time between MIN_SOL_DELAY and MAX_SOL_DELAY.
    This random delay desynchronizes clients which start at the same time
    (e.g., after a power outage).

    The client transmits the message according to section 13, using the
    following parameters:

       IRT   ADV_TIMEOUT

       MRC   0

       MRT   ADV_MAX_RT

       MRD   0


    The mechanism in section 13 is modified as follows for use in the
    transmission of Solicit messages.  The message exchange is not
    terminated by the receipt of an Advertise before ADV_TIMEOUT has
BV> ADV_MSG_TIMEOUT doesn't exist. I think you renamed it to
BV> ADV_TIMEOUT? ADV_MSG_TIMEOUT is used many times.
RD> Fixed all references to ADV_MSG_TIMEOUT
    elapsed.  Rather, the client collects Advertise messages until
    ADV_TIMEOUT has elapsed.  The first RT MUST be selected to be
    strictly greater than ADV_TIMEOUT by choosing RAND to be strictly
    greater than 0.

BV> Did you mean MRD, not MRT? MRT limits the time of a single
BV> retransmission. Also, the "If the DHCP client is otherwise configured"
BV> made me re-read the paragraph several times. Perhaps there is a better
BV> way to state this? "If the DHCP client is configured with a non-zero
BV> MRC or MRD, ...".
BV> Oh, might you want to say "SOL_MAX_ATTEMPTS" instead of MRC?

RD> Edited text in following paragraph to

    A DHCP client SHOULD choose MRC and MRD to be 0.  If the DHCP client
    is configured with either MRC or MRD set to a value other than
    0, it MUST stop trying to configure the interface if the message
    exchange fails.  After the DHCP client stops trying to configure the
    interface, it MAY choose to restart the reconfiguration process after
    some external event, such as user input, system restart, or when the
    client is attached to a new link.


14.3.4. Receipt of Advertise messages

BV> Also, this Retransmit logic is a bit weird beause of SRVR_PREF_WAIT.
BV> Does it make sense to state something like "A client only retransmits
BV> a Solicit if it fails to receive any Advertises before the retransmission
BV> timer expires. If a client receives one or more Advertise messages, it
BV> then must wait SRVR_PREF_WAIT seconds from the time of the transmit
BV> for any additional Advertise messages before proceeding."
RD> Edited following paragraph

    A client only retransmits a Solicit message if it does not receive
    an Advertise within SRVR_PREF_WAIT seconds after sending a Solicit
    message.  A client MUST collect Advertise messages for SRVR_PREF_WAIT
    seconds, unless it receives an Advertise message with a preference
    value of 255.  The preference value is carried in the Preference
    option (section  19.5).  Any Solicit that does not include a
    Preference option is considered to have a preference value of 0.  If
    the client receives an Advertise message with a preference value of
    255, then the client MAY act immediately on that Advertise message
    without waiting for any more additional Advertise messages.

    Upon receipt of one or more validated Advertise messages, the client
    selects one or more Advertise messages based upon the following
    criteria.

     -  Those Advertise messages with the highest server preference value
        are preferred over all other Advertise messages.

     -  Within a group of Advertise messages with the same server
        preference value, a client MAY select those servers whose
        Advertise messages advertise information of interest to the
        client.  For example, the client may choose a server that
        returned an advertisement with configuration options of interest
        to the client.

    Once a client has selected Advertise message(s), the client will
    typically store information about each server, such as server
    preference value, addresses advertised, when the advertisement was
    received, and so on.  Depending on the requirements of the client's
    invoking user, the client MAY initiate a configuration exchange with
    the server(s) immediately, or MAY defer this exchange until later.

    If the client needs to select an alternate server in the case that a
    chosen server does not respond, the client chooses the server with
    the next highest preference value.

    The client MAY choose a less-preferred server if that server has a
    better set of advertised parameters, such as the available addresses
    advertised in IAs.


[...]

15. DHCP Client-Initiated Configuration Exchange

[...]

15.3. Client Behavior

[...]

15.3.1. Creation and transmission of Request messages

    If the client is using stateful address configuration and needs
    either an initial set of addresses or additional addresses, it
    MUST send a Request message to obtain new addresses and other
    configuration information.  The client includes one or more IAs in
    the Request message, to which the server assigns new addresses.  The
    server then returns IA(s) to the client in a Reply message.

    The client generates a transaction ID and inserts this value in the
    "transaction-ID" field.

    The client places the address of the destination server in the
    "server-address" field.

    The client adds a DUID option to identify itself to the server.  The
    client adds any other appropriate options, including one or more IA
    options (if the client is requesting that the server assign it some
    network addresses).  The list of addresses in each included IA MUST
    be empty.  If the client is not requesting that the server assign it
    any addresses, the client omits the IA option.

    If the client has a source address that can be used by the server
    as a return address and the client has received a Client Unicast
    option (section 19.12) from the server, the client SHOULD unicast
    the Request message to the server.  Otherwise, the client sends the
    Request message to the All_DHCP_Agents multicast address.  The client
    MUST use an address assigned to the interface for which the client
    is interested in obtaining configuration information as the source
    address in the IP header of the datagram carrying the Rebind message,
    with the destination port set to 547.  The source port selection
    can be arbitrary, although it SHOULD be possible using a client
    configuration facility to set a specific source port value.

    The client transmits the message according to section 13, using the
    following parameters:

       IRT   REP_TIMEOUT

       MRC   REQ_MAX_ATTEMPTS

       MRT   REP_MAX_RT

       MRD   0

    If the message exchange fails, the client MAY choose one of the
    following actions:

     -  Select another server from a list of servers known to the client;
        e.  g., servers that responded with an Advertise message

     -  Initiate the server discovery described in section 14

     -  Terminate the configuration process and report failure


15.3.2. Creation and transmission of Confirm messages

    Whenever a client may have moved to a new link, its IPv6 addresses
    and other configuration information may no longer be valid.  Examples
    of times when a client may have moved to a new link include:

      o The client reboots

      o The client is physically disconnected from a wired connection

      o The client returns from sleep mode

      o The client using a wireless technology changes cells

    In any situation when a client may have moved to a new link, the
    client MUST initiate a Confirm/Reply message exchange.  The client
    includes any IAs, along with the addresses associated with those IAs,
    in its Confirm message.  Any responding servers will indicate the
    acceptability of the addresses with the status in the IA it returns
    to the client.

    The client sets the "msg-type" field to CONFIRM. The client generates
    a transaction ID and inserts this value in the "transaction-ID"
    field.

    The client sets the "server-address" field to 0.

    The client adds a DUID option to identify itself to the server.  The
    client adds any appropriate options, including one or more IA options
    (if the client is requesting that the server confirm the validity of
    some network addresses).  If the client does include any IA options,
    it MUST include the list of addresses the client currently has
    associated with that IA.

    The client MUST use an address assigned to the interface for which
    the client is interested in obtaining configuration information as
    the source address in the IP header of the datagram carrying the
    Rebind message, with the destination port set to 547.  The source
    port selection can be arbitrary, although it SHOULD be possible using
    a client configuration facility to set a specific source port value.

    The client transmits the message according to section 13, using the
    following parameters:

       IRT   REP_TIMEOUT

       MRC   REQ_MSG_ATTEMPTS

       MRT   REP_MAX_RT

       MRD   0

    If the message exchange fails, the client MUST restart the
    configuration process by locating a DHCP server as described
    in section 14.  The client SHOULD report the failure of the
    configuration process to the application layer.


15.3.3. Creation and transmission of Renew messages

    IPv6 addresses assigned to a client through an IA use the same
    preferred and valid lifetimes as IPv6 addresses obtained through
    stateless autoconfiguration.  The server assigns preferred and valid
    lifetimes to the IPv6 addresses it assigns to an IA. To extend those
    lifetimes, the client sends a Renew message to the server containing
    an "IA option" for the IA and its associated addresses.  The server
    determines new lifetimes for the addresses in the IA according to the
    server's administrative configuration.  The server may also add new
    addresses to the IA. The server may remove addresses from the IA by
    setting the preferred and valid lifetimes of those addresses to zero.

    The server controls the time at which the client contacts the server
    to extend the lifetimes on assigned addresses through the T1 and
    T2 parameters assigned to an IA. If the server does not assign an
    explicit value to T1 or T2 for an IA, T1 defaults to 0.5 times the
    shortest preferred lifetime of any address assigned to the IA and
    T2 defaults to 0.875 times the shortest preferred lifetime of any
    address assigned to the IA.

    At time T1 for an IA, the client initiates a Request/Reply message
    exchange to extend the lifetimes on any addresses in the IA. The
    client includes an IA option with all addresses currently assigned to
    the IA in its Request message.

    The client sets the "msg-type" field to RENEW. The client generates a
    transaction ID and inserts this value in the "transaction-ID" field.

    The client places the address of the destination server in the
    "server-address" field.

    The client adds a DUID option to identify itself to the server.  The
    client adds any appropriate options, including one or more IA options
    (if the client is requesting that the server extend the lease on some
    IAs; note that the client may check the status of other configuration
    parameters without asking for lease extensions).  If the client does
    include any IA options, it MUST include the list of addresses the
    client currently has associated with that IA.

    If the client has a source address that can be used by the server
    as a return address and the client has received a Client Unicast
    option (section 19.12) from the server, the client SHOULD unicast
    the Renew message to the server.  Otherwise, the client sends the
    Renew message to the All_DHCP_Agents multicast address.  The client
    MUST use an address assigned to the interface for which the client
    is interested in obtaining configuration information as the source
    address in the IP header of the datagram carrying the Rebind message,
    with the destination port set to 547.  The source port selection
    can be arbitrary, although it SHOULD be possible using a client
    configuration facility to set a specific source port value.

    The client transmits the message according to section 13, using the
    following parameters:

       IRT   REP_TIMEOUT

       MRC   0

       MRT   REP_MAX_RT

       MRD   0

    The mechanism in section 13 is modified as follows for use in the
    transmission of Renew messages.  The message exchange is terminated
    when time T2 is reached (see section 15.3.4), at which time the
    client begins a Rebind message exchange.


15.3.4. Creation and transmission of Rebind messages

    At time T2 for an IA (which will only be reached if the server to
    which the Renew message was sent at time T1 has not responded),
    the client initiates a Rebind/Reply message exchange.  The client
    includes an IA option with all addresses currently assigned to the
    IA in its Rebind message.  The client sends this message to the
    All_DHCP_Agents multicast address.

    The client sets the "msg-type" field to REBIND. The client generates
    a transaction ID inserts this value in the "transaction-ID" field.

    The client sets the "server-address" field to 0.

    The client adds a DUID option to identify itself to the server.
    The client adds any appropriate options, including one or more IA
    options.  If the client does include any IA options (if the client is
    requesting that the server extend the lease on some IAs; note that
    the client may check the status of other configuration parameters
    without asking for lease extensions), it MUST include the list of
    addresses the client currently has associated with that IA.

    The client MUST use an address assigned to the interface for which
    the client is interested in obtaining configuration information as
    the source address in the IP header of the datagram carrying the
    Rebind message, with the destination port set to 547.  The source
    port selection can be arbitrary, although it SHOULD be possible using
    a client configuration facility to set a specific source port value.

    The client transmits the message according to section 13, using the
    following parameters:

       IRT   REP_TIMEOUT

       MRC   0

       MRT   REP_MAX_RT

       MRD   0

    The mechanism in section 13 is modified as follows for use in the
    transmission of Renew messages.  The message exchange is terminated
    when the lease for the IA expires (see section 11), at which time the
    client has several alternative actions to choose from:

     -  When the lease on the IA expires, the client may choose to use a
        Solicit message to locate a new DHCP server and send a Request
        for the expired IA to the new server

     -  Some addresses in the IA may have lifetimes that extend beyond
        the lease of the IA, so the client may choose to continue to use
        those addresses; once all of the addresses have expired, the
        client may choose to locate a new DHCP server

     -  The client may have other addresses in other IAs, so the client
        may choose to discard the expired IA and use the addresses in the
        other IAs


15.3.5. Receipt of Reply message in response to a Request, Confirm,
    Renew or Rebind message

[...]

15.3.6. Creation and transmission of Release messages

    The client sets the "msg-type" field to RELEASE. The client generates
    a transaction ID and places this value in the "transaction-ID" field.

    The client places the IP address of the server that allocated the
    address(es) in the "server-address" field.

    The client adds a DUID option to identify itself to the server.  The
    client includes options containing the IAs it is releasing in the
    "options" field.  The addresses to be released MUST be included in
    the IAs.  The appropriate "status" field in the options MUST be set
    to indicate the reason for the release.

    The client MUST NOT use any of the addresses in the IAs in the
    message as the source address in the Release message or in any
    subsequently transmitted message.

    If the client has a source address that can be used by the server
    as a return address and the client has received a Client Unicast
    option (section 19.12) from the server, the client SHOULD unicast
    the Release message to the server.  Otherwise, the client sends the
    Release message to the All_DHCP_Agents multicast address.  The client
    MUST use an address for the interface to which the IAs in the Release
    message are assigned as the source address for the Release message,
    with the destination port set to 547.  The source port selection
    can be arbitrary, although it SHOULD be possible using a client
    configuration facility to set a specific source port value.

    A client MAY choose to wait for a Reply message from the server in
    response to the Release message.  If the client does wait for a
    Reply, the client MAY choose to retransmit the Release message.

    The client transmits the message according to section 13, using the
    following parameters:

       IRT   REP_TIMEOUT

       MRC   REL_MSG_ATTEMPTS

       MRT   REP_MAX_RT

       MRD   0

    The client MUST abandon the attempt to release addresses if the
    Release message exchange fails.

    The client MUST stop using all of the addresses in the IA(s) being
    released as soon as the client begins the Release message exchange
    process.  If an IA is released but the Reply from a DHCP server
    is lost, the client will retransmit the Release message, and the
    server may respond with a Reply indicating a status of "Nobinding".
    Therefore, the client does not treat a Reply message with a status
    of "Nobinding" in a Release message exchange as if it indicates an
    error.

    Note that if the client fails to release the IA, the addresses
    assigned to the IA will be reclaimed by the server when the lease
    associated with it expires.


15.3.7. Receipt of Reply message in response to a Release message

    Upon receipt of a valid Reply message, the client can consider the
    Release event successful, and SHOULD return the successful status to
    the application layer, if an application initiated the release.


15.3.8. Creation and transmission of Decline messages

    The client sets the "msg-type" field to DECLINE. The client generates
    a transaction ID and places this value in the "transaction-ID" field.

    The client places the IP address of the server that allocated the
    address(es) in the "server-address" field.

    The client adds a DUID option to identify itself to the server.  The
    client includes options containing the IAs it is declining in the
    "options" field.  The addresses to be released MUST be included in
    the IAs.  The appropriate "status" field in the options MUST be set
    to indicate the reason for declining the address.

    The client MUST NOT use any of the addresses in the IAs in the
    message as the source address in the Decline message or in any
    subsequently transmitted message.

    If the client has a source address that can be used by the server
    as a return address and the client has received a Client Unicast
    option (section 19.12) from the server, the client SHOULD unicast
    the Decline message to the server.  Otherwise, the client sends the
    Decline message to the All_DHCP_Agents multicast address.  The client
    MUST use an address for the interface to which the IAs in the Release
    message are assigned as the source address for the Decline message,
    with the destination port set to 547.  The source port selection
    can be arbitrary, although it SHOULD be possible using a client
    configuration facility to set a specific source port value.

    The client transmits the message according to section 13, using the
    following parameters:

       IRT   REP_TIMEOUT

       MRC   REL_ATTEMPTS

       MRT   REP_MAX_RT

       MRD   0

    The client MUST abandon the attempt to decline addresses if the
    Decline message exchange fails.


15.3.9. Receipt of Reply message in response to a Decline message

    Upon receipt of a valid Reply message, the client can consider the
    Decline event successful.

[...]



_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
http://www1.ietf.org/mailman/listinfo/dhcwg