MALLOC working group                                Mark Handley, ACIRI
Internet Draft                             draft-ietf-malloc-aap-00.txt
June 1999 Expires: December 1999

              Multicast Address Allocation Protocol (AAP)

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   The document defines a Multicast Address Allocation Protocol (AAP)
   that forms a part of a larger multicast address allocation
   architecture currently being defined.  AAP addresses the specific
   issue of intra-domain multicast address allocation between multicast
   address allocation servers.

1. Introduction

   This document defines a Multicast Address Allocation Protocol (AAP)
   that forms a part of a larger multicast address allocation
   architecture [1].  The general framework within which AAP is designed
   to operate is best described by describing the process by which a
   multicast address is allocated:

   o As a continuous process, a higher level protocol, MASC [2] provides
     a multicast address set, from which addresses should be allocated
     to an allocation domain.

   o MASC routers periodically send advertisements of this address set



Handley                                                         [Page 1]


Internet Draft        draft-ietf-malloc-aap-01.txt         December 1999


     to Multicast Address Allocation Servers (MAAS) within the
     allocation domain using AAP address-set advertisement messages.

   o When a client requires a multicast address, it sends a request to a
     MAAS for information about the scope zones that include the server.
     The MAAS returns this information.

   o The client then chooses a scope zone, and requests an address for a
     certain period of time.

   o The MAAS chooses an address from the address set that is not
     currently in use, and multicasts an AAP address-claim message to
     all the other MAASs in the allocation domain. If no-one objects to
     this announcement, then the MAAS starts to periodically multicast
     an AAP address-in-use message to all the MAASs in the allocation
     domain, and it returns the address to the client to use.

1.1. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [3].

1.2. Definitions

2. Specification of Behavior

   Within an allocation domain, MAASs are all multicast peers - there is
   no hierarchy or configured peering.  To allocate an address, a MAAS
   should have been listening to AAP address-set messages and AAP
   address-in-use messages for a considerable period of time (known at
   STARTUP-WAIT) so that it has a good idea of currently available
   addresses.  MAASs that have not been listening for at least STARTUP-
   WAIT SHOULD NOT respond to a client's request for an address.

2.1. AAP Packet Types

   The following packet types are defined:

   Address-Set-Announce (ASA)
     This AAP message is normally sent from a MASC router to all the
     MAAS servers in an allocation domain.  It lists a number of
     address-sets, each of which has an associated lifetime.  The
     announcement contains a timestamp to detect replays or broken
     clocks, an expiry time, and the address of the last MASC router to
     send an Address-Set-Announce (ASA) message to this group.

     The address-set contained in such a message MUST be the complete



Handley                                                         [Page 2]


Internet Draft        draft-ietf-malloc-aap-01.txt         December 1999


     address-set available to MAASs at that time.  An address-set MUST
     NOT be spilt across multiple ASA messages.

     ASA messages MAY alternate between several cooperating MASC
     routers.  Each ASA message contains the address of the last router
     to send such a message to the domain.  This information is present
     to detect cases where two MASC routers are sending messages to the
     domain without hearing each others messages.  This is for fault
     diagnosis purposes, and may be used to trigger an alarm for a
     network operator to investigate the failure.  It may not be counted
     upon for any other purpose.

     ASA messages MUST be digitally signed by the router that sends
     them.  MAASs MAY be configured to ignore ASA messages from unknown
     routers.

     The ASA expiry time is the time by which all MAASs within the
     domain should reasonably have heard a new ASA message.  Typically
     approximately five ASA messages should have arrived during the
     between the timestamp time and the expiry time.  If no ASA message
     is forthcoming by this expiry time, this MAY be used to raise
     alarms that some unexpected failure has occurred.  Addresses SHOULD
     still be allocated by such a MAAS, but request protocols that
     permit it MAY report a lack of confidence in the address.  Note
     that in the absence of ASA messages from MASC routers with an
     expiry time in the future, cached ASA messages may be resent by
     MAASs.  These cached messages will have an expiry time in the past,
     but are still valid unless a new ASA message is received from a
     MASC router.

     MAASs MUST cache the most recent (as defined by timestamp) ASA
     message that was signed with an acceptable signature in its
     entirety including the digital signature.  If no new ASA message
     has been heard after the expiry time given in the ASA message, a
     MAAS may assume that the MASC routers have all lost state and need
     refreshing.  If this happens, the MAAS sets a timer for a random
     interval between in the range [ASA-INTERVAL*0.7, ASA-INTERVAL*1.3].
     If the timer expires without a newer ASA message arriving, the
     cached ASA message is sent to the AAP group, and the timer set
     again.  If the MAAS receives the same ASA message from another MAAS
     it resets its timer to a new random interval in the same range.
     However, if it receives a new ASA message with a valid signature
     and a newer timestamp, it caches the new ASA message and clears its
     timer.  This process is required because we cannot rely on MASC
     routers to have stable storage.  Normally a router that reboots can
     re-obtain its address sets from its peers but in some rare
     circumstances this may not happen.  MAASs are required to have
     stable storage, and need to store this information anyway, so they



Handley                                                         [Page 3]


Internet Draft        draft-ietf-malloc-aap-01.txt         December 1999


     provide a backup mechanism whereby the router state can be restored
     to the point where it left off.

   Server-Signature (SSIG)
     This AAP message gives the public key of a new server and the
     expiry time for this key.  Such a server can be a new MAAS or a new
     MASC router.  This key MUST be digitally signed by one or more
     additional servers.  It may be multicast from any node in the
     allocation domain to all the MAASs in the domain, and is used to
     bootstrap the trust of both MASC routers and MAASs.

     A typical bootstrap mechanism might be for all MAAS's and MASC
     routers in a domain to be configured with the public key of one or
     more primary AAP nodes (either MAAS's or MASC routers).  The
     primary AAP node is trusted by all the other AAP nodes in the
     domain.  By default, other AAP nodes might not be trusted (this is
     an administrative decision).  However, by configuring the primary
     AAP node with the address and public key of the new AAP node, we
     can bootstrap the trust of the other legitimate AAP nodes without
     needing to manually configure all the AAP nodes in the domain with
     knowledge of each other.  To do this the primary AAP node(s) sends
     digitally signed SSIG packets periodically listing all the AAP
     nodes in the domain, their public keys, and their key expiry times.
     Receivers of these SSIG packets can now trust other AAP messages
     from the listed nodes until the key expiry time.

   Address-Claim (ACLM)
     This AAP message is multicast from a MAAS attempting to allocate an
     address to all other MAASs in the domain.  The message contains a
     list of the addresses being requested, the beginning and end times
     for the allocation, and a request sequence number.

     The MAAS sending this message has already listened to other
     announcements, and is reasonably certain that the addresses listed
     are not in use.  It sends this message to check that it has not
     missed a recent announcement by another MAAS.  It expects that no
     reply will be forthcoming, but waits ANNOUNCE-WAIT seconds to
     ensure this is the case.

     Two possible messages might be received that would indicate a
     problem with the announcement.

     o ASA might be sent by a MASC router to indicate that the address
       allocation was not valid for the address-set currently available.
       This is extremely unlikely to occur with a compliant MAAS, and
       MASC routers are not required to listen to AAP ACLM messages.

     o Address-In-Use (AIU) might be sent be another MAAS to indicate



Handley                                                         [Page 4]


Internet Draft        draft-ietf-malloc-aap-01.txt         December 1999


       that the address was already in use.  This can be sent if the
       same address is already allocated for the same time interval.

     In either case, the MAAS SHOULD change its allocation and send
     another ACLM message with the same request sequence number.  The
     only exception to this is if the MAAS suspects a denial of service
     attack is in progress (see section 5.1).

     This message MAY be digitally signed by the MAAS sending it.

   Address-Intent-To-Use (AITU)
     This AAP message is similar to an ACLM message except it lacks the
     start and end times for each address.  It indicates that the MAAS
     sending it intends to choose the indicated address(es) next.  It
     allows an address to be pre-claimed but in a manner that is non-
     exclusive - it may be overridden by an Address-In-Use message or an
     ACLM message.  A MAAS MUST NOT send AITU for an address for which
     someone else is already sending AITU.

     A server hearing AITU from another server MAY send ACLM to claim
     that address and MUST send AIU to defend that address if it had
     already allocated it.  It SHOULD also send AIU after an appropriate
     time delay if no-one else does and if the AITU messages was already
     allocated by someone else.  The rules for this are identical to
     those for triggered AIU messages caused by ACLM.

     The reason for AITU is to allow MAASs to sometimes allocate an
     address with no delay, whereas using ACLM requires waiting for at
     least ANNOUNCE-WAIT seconds.  The model is as follows:

     o A MAAS sends AITU for an address.  It MUST have sent it at least
       twice, with the second copy sent at least ANNOUNCE-WAIT seconds
       ago and not more than 1.3*BASE-REPEAT-INTERVAL ago.  During that
       time it MUST NOT have heard an ACLM or AIU message for that
       address.  Under such circumstances the address may be handed
       immediately to a new client and an AIU message immediately sent.

     o If a MAAS is sending AITU for an address and it hears AITU, AIU
       or ACLM from another server for the same address, it must stop
       sending AITU and cannot now hand the address to a client.  The
       address becomes just like any other address that the MAAS has
       just heard an AIU or ACLM message (as appropriate) for.

     o It is also possible that an ASA message will arrive indicating
       that the address being claimed is not valid.  If this occurs, the
       MAAS should cease sending AITU for this address.  This is
       unlikely to occur in a correctly configured network, but may
       occur if the physical topology of the network is reconfigured.



Handley                                                         [Page 5]


Internet Draft        draft-ietf-malloc-aap-01.txt         December 1999


     The reason for having two message types, AITU and ACLM, is to
     prevent unnecessary address space exhaustion.  If the space is near
     to exhaustion, sending ACLM to reserve an address for which the
     server does not yet have an immediate use would exhaust the space
     unnecessarily.  Sending AITU allows some of the servers (those
     sending AITU) to perform immediate allocation, whereas the others
     would need to perform ACLM to get the same addresses.

     This message MAY be digitally signed by the MAAS sending it.

   Address-In-Use (AIU)
     This AAP message is multicast periodically from a MAAS to all other
     MAASs in the domain to indicate that addresses are in use.  The
     message contains a list of addresses, each with an associated start
     and stop time.

     This message may also be sent by any MAAS that notices a ACLM
     message that would cause a clash.  See section XXX for details of
     the timing of such response messages.

     This message MAY be digitally signed by the MAAS sending it.

     The reason for having an AIU message distinct from ACLM is to
     prevent failed claims being cached by other servers.  MAASs MUST
     cache addresses from AIU messages sent by other servers as in-use
     until the end of the address lifetime or until the MAAS is
     restarted.  However, addresses from ACLM messages only need caching
     as in-use until they hear a subsequent ACLM for a different address
     with the same sequence number, an AIU message for the same address
     (in which case the cache is extended for the address lifetime), or
     time out the address after BASE-REPEAT-INTERVAL seconds.

   Address-Space-Report (ASRP)
     The AAP message is periodically multicast from a MAAS to all the
     MASC routers for the domain indicating the current address space
     usage.  It contains a set of address ranges, the numbers of
     addresses being used from each range, and the last expiry dates for
     each of those numbers of addresses.  This reflects the address sets
     being provided by MASC.  Typically an ASRP message will contain one
     number of addresses being used for each address set provided by
     MASC with the expiry date being that of the last address to expire
     in the address set.  However, if the MAAS node sending ASRP
     determines it necessary, it may split each MASC range into multiple
     smaller ranges and report those separately.  Thus if usage of a
     prefix has declined and the MAASs have only been allocating from
     the lower half of a prefix (for example), then reporting the two
     halves of the prefix separately would ensure that MASC only renews
     the half of the prefix in use.  If ASRP reported the whole range,



Handley                                                         [Page 6]


Internet Draft        draft-ietf-malloc-aap-01.txt         December 1999


     then MASC might still only renew half the prefix, but would not be
     able to intelligently choose which half to renew.

     These messages SHOULD be digitally signed.  If any MAAS in the
     domain is trusted by the MASC routers, that server should send the
     ASRP messages.  If not, any MAAS may take over this role.  This is
     achieved by using shorter randomised timeouts for the trusted
     servers as explained in section XXX.  How the MAAS calculates the
     address space required is explained in section XXX.

3. Specification of MAAS Behaviour

   When a MAAS starts up, it MUST listen to AAP messages for at least
   START-WAIT time before it can respond to an address allocation
   request, and SHOULD have received at least one ASA message.  If it
   does not receive an ASA message within this time, it MAY respond to
   an allocation request only if it has cached a previous ASA message
   which includes at least one range that has not reached its end time.

   There are two ways to claim an address - on demand, or in advance.
   The in-advance mechanism is an optimization of the on-demand
   mechanism, and falls back to the on-demand mechanism when there is a
   conflict.

   In the on-demand mechanism, when a MAAS receives a request for the
   allocation of an address, that request will contain a start and end-
   time.  The MAAS SHOULD choose the address-set from those that were
   advertised to it that satisfies the greatest proportion of the time
   in the request.  Alternatively if more than one address-set satisfies
   all the time in the request, the address set with the shortest
   remaining lifetime should be chosen.  From that address-set it SHOULD
   then choose at random an address that is not already being advertised
   by any MAAS .  It should then send this address in an ACLM message
   with the start-time from the request and the minimum of the address-
   set end-time and the request end-time.  It SHOULD then set a timer
   for ANNOUNCE-WAIT seconds in the future.

   If the MAAS receives an ACLM message or an AIU message from another
   MAAS listing the same address before the timer expires, then it
   should cancel the timer, choose another address in the same manner,
   send another ACLM message with the same sequence number listing the
   new address, and set a new timer for ANNOUNCE-WAIT seconds in the
   future.  Such a MAAS MAY also resend the ACLM after RESEND-WAIT
   seconds, and again after a further RESEND-WAIT*2 seconds, doubling
   each time until the timer expires.

   If the timer expires, the MAAS can conclude that there is a good
   probability that the address is unique, and it can then send an AIU



Handley                                                         [Page 7]


Internet Draft        draft-ietf-malloc-aap-01.txt         December 1999


   message listing this address, add the address to its list of
   allocated addresses, and return the address along with the (possibly
   modified) end-time to the client.

   A MAAS MUST send AIU messages periodically for all the addresses that
   it currently has allocated.  Each of these addresses SHOULD be
   included in an AIU message every BASE-REPEAT-INTERVAL seconds +/- 30%
   of this value to avoid synchronisation effects.  A MAAS that has just
   allocated an address SHOULD resend that address again after RESEND-
   WAIT seconds, and again after a further RESEND-WAIT*2 seconds,
   doubling each time until the interval reaches BASE-REPEAT-INTERVAL
   seconds.

   In some circumstances a MAAS may receive large numbers of requests
   for addresses, each for very short period of time.  Sending triggered
   announcements for each of these requests increases the delay before
   granting addresses and may create a significant amount of AAP
   traffic.  If it desires, such a server MAY pro-actively allocate a
   pool of addresses using the process described above, and may then may
   grant these requests immediately out of this pool.  As the server
   MUST have already sent AIU messages for these pooled addresses, there
   should be no clash.  Such servers should maintain the minimum pool to
   allow them to perform their task well.  Applications requiring
   multicast addresses MUST NOT assume that a MAAS will always grant
   them addresses with no delay, and SHOULD assume that the server will
   take at least ANNOUNCE-WAIT seconds to allocate them an address.
   Depending on the request protocol being used by the client, a server
   MAY communicate ANNOUNCE-WAIT to clients when they request a list of
   current scope zones before requesting a multicast address, or it MAY
   send an interim reply to the client indicating how long it expects
   allocation to take.

   An alternative mechanism to the on-demand ACLM mechanism is to
   express an intent to use an address using AITU messages.  These are
   more useful for servers that allocate few addresses but wish to do so
   with minimal delay.  To do this a MAAS chooses an unused address and
   sends an AITU message announcing its intention that this is the next
   address it will use.  The message does not reserve the address, but
   does prevent anyone else sending an AITU message for the same
   address.  After sending its first AITU message for an address, a
   period of ANNOUNCE-WAIT must elapse before the address is usable.
   Any ACLM, AITU or AIU messages received that list this same address
   cause the MAAS to cancel its timer and choose a new address.  The
   AITU message should be resent with the same time intervals as an AIU
   message - i.e. the interval between messages doubles each time until
   it reaches BASE-REPEAT-INTERVAL.  After the initial ANNOUNCE-WAIT
   interval has expired, if no other server has sent AITU, ACML or AIU
   for the address, it becomes eligible for allocation to a client.  A



Handley                                                         [Page 8]


Internet Draft        draft-ietf-malloc-aap-01.txt         December 1999


   request for an address can be satisfied immediately with this
   address, and the server then sends an AIU message for the address,
   resending the AIU again after RESEND-WAIT seconds, and again after a
   further RESEND-WAIT*2 seconds, doubling each time until the interval
   reaches BASE-REPEAT-INTERVAL seconds.

   If a MAAS has heard AITU messages for all the available addresses in
   a domain it cannot choose an address and send AITU.  However, if it
   receives a request for an address from a client, it should choose one
   of the unallocated addresses at random ignoring the fact that someone
   else was sending AITU, and send an ACLM claim message in the normal
   way.

   If some of the unallocated addresses in a domain are reported in AITU
   messages and some are not, a MAAS that wishes to claim an address
   using ACLM SHOULD choose at random one of the addresses not reported
   in AITU messages.

3.1. Triggered Responses

   When a MAAS A receives an ACLM or an AITU message from MAAS B
   containing an address that clashes with an address in use in its
   cache, it should set a timer based on the algorithm below.  If server
   A sees an AIU message from a server other than B containing this
   address before the timer expires, it should restart the timer with
   double its original value.  If server A sees an ACLM or an AITU from
   server B with the same sequence number as before, it should cancel
   its timer.

   If server A's timer expires, it should send an AIU message containing
   the address in question, and should restart the timer with twice its
   previous value, unless that value was 0, in which case it sets it to
   INITIAL-TIMER.  If the timer interval becomes greater than BASE-
   REPEAT-INTERVAL the timer should be cancelled - in this case the
   remote MAAS probably suffered some form of failure after sending the
   ACLM or AITU and we revert to the normal announcement mechanism.

   The initial value for the timer is determined as follows:

   o If server A is the server that was originating the announcement for
     the address in question, the initial value of the timer is 0.

   o If server A is not the server that was originating the announcement
     for this address, the server calculates the timer, t, as follows:

     X is chosen from the uniform random interval [0:1]

                  (D2/R)



Handley                                                         [Page 9]


Internet Draft        draft-ietf-malloc-aap-01.txt         December 1999


     t=D1+R*log2(2      *X+1)

     D1 defaults to R.
     D2 defaults to DEFAULT-D2 seconds.

     R is an estimate of maximum round trip time for the domain, and
     defaults to DEFAULT-RTT.  This value MAY be reduced to reduce
     delays for some domains.  If the value is increased, it MUST be
     increased in all MAASs in the domain.

     This equation results is an exponential random distribution between
     D1 and D2 seconds.  The default value of D2 is useful for up to
     several thousand MAASs in a domain to ensure that close to one
     server responds.

   If a MAAS has sent an ACLM message and has an ANNOUNCE-WAIT timer
   running, and it receives another ACLM message for the same address
   from another MAAS, it SHOULD immediately choose another multicast
   address and send a new ACLM message with the same sequence number.
   It MUST NOT send an AIU message in this state in response to an ACLM
   message.  It does not matter which server chooses a new address in
   these circumstances, so it is not necessary to inform the other site.

3.2. Scope of AAP Messages

   AAP messages are sent to a well known multicast address
   (239.??.??.??)  and port (????).  This multicast address MUST be
   administratively scoped so as not to leave the allocation domain.
   The TTL on packets SHOULD be set to 255.

   Note: AAP is not intended to perform multicast address allocation for
   TTL-scoped sessions.  Non-global sessions SHOULD be constrained using
   administrative scoping only.

3.3 AAP Timers

   Most AAP timers are defined in terms of DEFAULT-RTT.  This is
   intended to be an approximation of the largest propagation delay
   across the domain and back.  The default value for DEFAULT-RTT is
   intended to be reasonable for most allocation domains, but if the
   domain is very small with little queuing delay, or very large, then
   this value can be changed.  Clearly increasing DEFAULT-RTT decreases
   performance and increases the wait for addresses.  If the real RTT
   across the domain is significantly greater than the configured
   default value of DEFAULT-RTT, unnecessary additional traffic may be
   generated.  If the real RTT across the domain is significantly less
   that the configured default value of DEFAULT-RTT, AAP will perform as
   intended, but could be tuned to reduce the allocation delay.



Handley                                                        [Page 10]


Internet Draft        draft-ietf-malloc-aap-01.txt         December 1999


   The following AAP timers are defined:

   START-WAIT

     START-WAIT = Max(5 * SET-REPEAT-INTERVAL, 5 * BASE-REPEAT-INTERVAL)
     seconds.

   SET-REPEAT-INTERVAL

     SET-REPEAT-INTERVAL defaults to 30 seconds.

   ANNOUNCE-WAIT

     ANNOUNCE-WAIT defaults to 40 * DEFAULT-RTT.

   RESEND-WAIT

     RESEND-WAIT defaults to 10 * DEFAULT-RTT.

   INITIAL-TIMER

     INITIAL-TIMER defaults to 2 * DEFAULT-RTT.

   DEFAULT-RTT

     DEFAULT-RTT defaults to 100ms.

   DEFAULT-D2

     DEFAULT-D2 defaults to 30 * DEFAULT-RTT.

   ASA-INTERVAL

     ASA-INTERVAL defaults to 30 seconds.

   BASE-REPEAT-INTERVAL

     BASE-REPEAT-INTERVAL = Max(30, SIZE*NO-OF-ADDRESSES/BASE-RATE)
     seconds.

     where:

     NO-OF-ADDRESSES is the number of addresses currently allocated
     within the domain.

     SIZE is the size in bytes of a single (address,start-time,stop-
     time) triple from an AIU message.




Handley                                                        [Page 11]


Internet Draft        draft-ietf-malloc-aap-01.txt         December 1999


   BASE-RATE

     BASE-RATE is the approximate background rate for announcement
     traffic within a domain with a significant number of addresses
     allocated.  For IPv4, the rate only reaches this level with around
     3000 addresses allocated within a domain.

     It defaults to 1250 bytes/second.

4. Packet Formats

   AAP messages are binary format, as the additional flexibility of
   having a textual format is not required in this case.

   All AAP packets start with the following common header:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  V=0  |STYPE|P|      SLEN     | PTYPE | ATYPE |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             RSEQ              |              MSEQ             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   version (V): 4 bits

     This field identifies the version of AAP.  The version defined by
     this specification is 0.

   Signature Type (STYPE): 4 bits

     This field identifies the type of digital signature used to sign
     the message.  The values are defined as follows:

     0. No signature present.  SLEN MUST also be zero.

     1. PGP signature used.  The format is described in TBD.

   Signature Length (SLEN): 8 bits

     This field indicates the length of the digital signature in the
     packet as a multiple of 32 bit words.  If the signature is not a
     multiple of 32 bits long, the last byte of the signature indicates
     the number of padding bytes that have been added to the end of the
     signature.  These padding bytes are then included in the signature
     length, and the signature padding bit (P) is set.

   Packet Type (PTYPE): 4 bits



Handley                                                        [Page 12]


Internet Draft        draft-ietf-malloc-aap-01.txt         December 1999


     This field indicates the type of AAP packet this is.  It is one of
     the following values:

     0. Address-Set-Announce (ASA)

     1. Server-Signature (SSIG)

     2. Address-Claim (ACLM)

     3. Address-Intent-to-Use (AITU)

     4. Address-In-Use (AIU)

     5. Address-Space-Report (ASRP)

   Address Type (ATYPE): 4 bits

     This field indicates the address type used in the packet.  Multiple
     address types (for example IPv4 and IPv6) can be used within the
     same domain at the same time.  However, only a single address type
     may be used within one AAP packet.

     The following values are defined:

     0. IP version 4.

     1. IP version 6.

   Request Sequence (RSEQ): 24 bits

     This field is a sequence number.  The first packet an AAP node
     (MAAS or MASC router) sends should have sequence number 0, and the
     sequence number should be incremented for every subsequent distinct
     message or request.  Retransmissions of claims are made with the
     same RSEQ as the original but increasing MSEQ.  When an AITU or
     ACLM message results in a detected clash, a new address is chosen
     and an new message is sent with the same RSEQ as the original.  In
     such cases the message sequence number MSEQ is incremented instead.
     AIU messages always get new RSEQ if the addresses in use change,
     otherwise MSEQ is incremented instead.  ASA messages always get a
     new RSEQ because they alternate sender between multiple MASC
     routers.

     At peak usage rates of one request per second, it is possible for
     the RSEQ space to wrap about every 6 months.  It is unlikely that
     any message sequence will last this long, but it conceivable that
     an AITU message sequence might do so.  Implementors should be aware
     of this possibility and avoid reusing the RSEQ value that is in



Handley                                                        [Page 13]


Internet Draft        draft-ietf-malloc-aap-01.txt         December 1999


     use.

   Message Sequence (MSEQ): 8 bits

     This field is a packet sequence number that is used to identify
     different messages of the same request.  For example, if a server
     sends a new ACLM message with RSEQ=27, MSEQ=0, and receives an AIU
     message from another server for that same address, it then chooses
     a new address and sends a new ACLM message with RSEQ=27, MSEQ=1.
     This may be resent after RESEND-WAIT seconds with RSEQ=27, MSEQ=2.
     After ANNOUNCE-WAIT seconds, the server can send an AIU message for
     the address with RSEQ=28,MSEQ=0.

     MSEQ may wrap when AITU is sent for longer than about 2 hours (with
     default timer values) without an address being requested.  This
     should not cause a problem, but if MSEQ and RSEQ are being used to
     monitor loss, this should be taken into account.

     MSEQ may also wrap if a long serious of address collisions occurs
     when sending ACLM.  Under normal circumstances, this is extremely
     unlikely and probably signals a denial-of-service attack.
     Implementors should be aware of this possibility.

   Immediately following the common header is a digital signature of the
   payload of the packet.  This can be of variable length.

   Following the digital signature are the packet contents, the format
   of which depend on both the ATYPE and PTYPE fields.

4.1. AAP Time Fields

   AAP packets contain a number of places where absolute times must be
   represented.  Unless otherwise stated, these time values are
   represented as unsigned 32 bit integers in network byte order giving
   the number of seconds since 00:00 UTC, 1st January 1970.  This
   arbitrary baseline is convenient on many current operating systems,
   and can be converted to an NTP timestamp by adding decimal
   2208988800.  Thus AAP time fields will not wrap until the year 2106.

4.2. IPv4 Packet Formats (ATYPE=0)

4.2.1 Address-Set-Announce (ASA)

   An address set announce packet for IPv4 contains an address set
   refresh time, followed by one or more address sets:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1



Handley                                                        [Page 14]


Internet Draft        draft-ietf-malloc-aap-01.txt         December 1999


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Current Time                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Refresh Time                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   IPv4 Multicast Address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Mask                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Expiry time                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   IPv4 Multicast Address                      |
   |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|

   The current time is an AAP time field (see section 4.1) and gives the
   current time at the router sending this message.

   The address set refresh time is an AAP time field giving the time by
   which another ASA message should have been received.

   Within each address set, the multicast address indicates an IPv4 base
   address.  The mask indicates which bits from the base address are
   wildcarded, i.e, can be set be the address allocator.  For example,
   if the base address is: 0xE0020000 (224.2.0.0) and the mask is
   0x000100FF then addresses 224.2.0.0-224.2.0.255 and 224.3.0.0-
   224.3.0.255 are available.  Note that the mask does not have to be
   contiguous.  All MAASs MUST be able to cope with discontiguous masks,
   although in some cases only contiguous masks may be supplied by MASC.

   The address set expiry time is an AAP time field giving the time at
   which the address set will expire.  Addresses should only be granted
   from this address set up until this time.

   The address set expiry time is an AAP time field giving the time at
   which the address set will expire.  Addresses should only be granted
   from this address set up until this time.

4.2.2. SERVER-SIGNATURE

   TBD

4.2.3. Address-Claim (ACLM)

   An ACLM packet for IPv4 contains the current time at the MAAS and one
   or more addresses:




Handley                                                        [Page 15]


Internet Draft        draft-ietf-malloc-aap-01.txt         December 1999


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Current Time                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   IPv4 Multicast Address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Start time                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          End time                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   IPv4 Multicast Address                      |
   |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|

   The multicast address lists the specific address being requested.
   Start-time and end-time are AAP time fields giving the range of time
   for which the address is required.

   Multicast addresses within the packet MUST be in increasing numerical
   order.

4.2.4. Address-Intent-to-Use (AITU)

   An AITU packet for IPv4 contains the current time at the MAAS and one
   or more addresses:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Current Time                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   IPv4 Multicast Address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   IPv4 Multicast Address                      |
   |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|

   The multicast address lists the specific address being requested.
   Multicast addresses within the packet MUST be in increasing numerical
   order.

4.2.5. Address-In-Use (AIU)

   An AIU packet for IPv4 contains the current time at the MAAS, a
   refresh timeout, and one or more addresses as for ACLM.




Handley                                                        [Page 16]


Internet Draft        draft-ietf-malloc-aap-01.txt         December 1999


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Current Time                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Refresh Time                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   IPv4 Multicast Address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Start time                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          End time                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   IPv4 Multicast Address                      |
   |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|

   The current-time is an AAP time field used to discover MAASs that
   have incorrectly set clocks, or to identify the age of proxy
   announcements when a MAAS has died.

   Multicast addresses within the packet MUST be in increasing numerical
   order.  Where a MAAS has more addresses than will fit in one packet,
   they may be split over several packets.  There SHOULD be no overlap
   in numerical ranges of addresses between these packets.  An exception
   to this is if a MAAS is announcing its own addresses and those of
   another server, when it SHOULD announce its own addresses in
   different packets from those it is proxy announcing.  Ordering the
   addresses in this way increases the efficiency of processing packets
   received at a MAAS.

   The refresh-time is an AAP time field used to indicate that another
   message from the same server should have been received by this time.
   This time SHOULD be far enough in the future that at least five
   messages from this server would have been expected to have been
   heard.  If no messages are heard in this interval, other MAASs MAY
   conclude that this MAAS has died or been partitioned.  In such
   circumstances they MAY make a proxy announcement (see section XXX).

4.2.6. Address-Space-Report (ASRP)

   An ASRQ packet for IPv4 contains one or more pairs of number of
   addresses and lifetimes:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Handley                                                        [Page 17]


Internet Draft        draft-ietf-malloc-aap-01.txt         December 1999


   |                      number of addresses                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          end-time                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Generally speaking, if the MAAS is happy with its current address
   set, it should simply report the address set back to the MASC servers
   with this message.

   However, if the address space is insufficient, the MAAS should either
   add one or more additional pairs of number of addresses and lifetime,
   or increase the number of addresses from one of the existing pairs.

   If the address set is larger than required, this is not usually dealt
   with until addresses need to be allocated from a set with a longer
   lifetime than those in the existing set.  At this time, the MAAS will
   replace one or more of the pairs from the existing set with a smaller
   but longer duration pair.

4.3. IPv6 Packet Formats (ATYPE=1)

   TBD

5. Security

5.1. Denial of Service Attacks

   TBD

6. References

   [1]  Handley, M., D. Thaler, D. Estrin, "The Internet Multicast
        Address Allocation Architecture", Internet Draft,
        draft-ietf-malloc-arch-01.txt, April 1999.

   [2]  Estrin, D., R. Govindan, M, Handley, S. Kumar, P. Radoslavov,
        D. Thaler, "The Multicast Address Set Claim (MASC) Protocol",
        Internet Draft, draft-ietf-malloc-masc-01.txt, August 1998.

   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119, March 1997.

7. Author's Address

      Mark Handley
      AT&T Center for Internet Research at ISCI (ACIRI)
      1947 Center St., Suite 600
      Berkeley, CA 94704-119



Handley                                                        [Page 18]


Internet Draft        draft-ietf-malloc-aap-01.txt         December 1999


      USA
      Email: mjh@aciri.org

















































Handley                                                        [Page 19]