One document matched: draft-handley-aap-00.txt
Internet Engineering Task Force MALLOC WG
Internet Draft M. Handley
draft-handley-aap-00.txt ISI
December 15, 1997
Expires: June 1998
Multicast Address Alloctation Protocol (AAP)
STATUS OF THIS MEMO
This document is an Internet-Draft. 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''.
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this document is unlimited.
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 with which AAP is designed to
operate is best describes by describing the process by which a
multicast address is allocated:
M. Handley [Page 1]
Internet Draft AAP December 15, 1997
1. As a continuous process, a higher level protocol, MASC [2],
provides a multicast address set to an allocation domain
that multicast addresses should be allocated out of.
2. MASC routers periodically send advertisements of this
address set to Multcast Address Allocation Servers (MAAS)
within the allocation domain using AAP address-set
advertisement messages.
3. When a client requires a multicast address, it sends a
request to a MAAS server for information about the scope
zones that include the server. The MAAS server returns this
information.
4. The client then chooses a scope zone, and requests an
address for a certain period of time.
5. The MAAS server chooses an address from the address set
that is not currently in use, and multicasts an AAP
prospective-announcement message to all the other MAAS
servers in the allocation domain. If no-one objects to this
announcement, then the MAAS server starts to periodically
multicast an AAP address-in-use message to all the MAAS
servers in the allocation domain, and it returns the
address to the client to use.
1.1 Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [10]
and indicate requirement levels for compliant SIP implementations.
1.2 Definitions
2 Specification of Behaviour
Within an allocation domain, MAAS servers are all multicast peers -
there is no hierarchy or configured peering. To allocate an address,
a MAAS server 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. MAAS servers 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
M. Handley [Page 2]
Internet Draft AAP December 15, 1997
The following packet types are defined:
ADDRESS-SET-ANNOUNCE
This AAP message is 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, a refresh time, and the
address of the last MASC router to send an ADDRESS-SET-ANNOUNCE
message to this group.
The address-set contained in such a message MUST be the complete
address-set available to MAAS servers at that time. An address-set
MUST NOT be spilt across multiple ADDRESS-SET-ANNOUNCE messages.
The expiry time is the time by which all MAAS servers within the
domain should reasonably have heard a new ADDRESS-SET-ANNOUNCE
message. If no ADDRESS-SET-ANNOUNCE message is forthcoming by this
expiry time, this MAY be used to raise alarms that some unexpected
failure has occured. Addresses SHOULD still be allocated by such a
MAAS server, but request protocols that permit it MAY report a lack
of confidence in the address.
ADDRESS-SET-ANNOUNCE messages MAY alternate between several
cooperating MASC routers. Each ADDRESS-SET-ANNOUNCE 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. It may not be counted upon for any other purpose.
ADDRESS-SET-ANNOUNCE messages MUST be digitally signed by the router
that sends them. MAAS servers MAY be configured to ignore ADDRESS-
SET-ANNOUNCE messages from unknown routers.
SERVER-SIGNATURE
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 server 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 MAAS servers in the domain, and is used
to bootstrap the trust of both MASC routers and MAAS servers.
PROVISIONAL-ADDRESS-ALLOCATION
This AAP message is multicast from a MAAS server attempting to
allocate an address to all other MAAS servers in the domain. The
message contains a list of the addresses being requested, the
M. Handley [Page 3]
Internet Draft AAP December 15, 1997
beginning and end times for the allocation, and a request sequence
number.
The MAAS server 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 server. 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.
-ADDRESS-SET-ANNOUNCE 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 server, and MASC routers are not required to
listen to AAP PROVISIONAL-ADDRESS-ALLOCATION messages.
-ADDRESS-IN-USE might be sent be another MAAS server to indicate
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 server SHOULD change its allocation and
send another PROVISIONAL-ADDRESS-ALLOCATION message with the
same request sequence number. The only exception to this is if
the MAAS server suspects a denial of service attack is in
progress (see section 5.1).
This message MAY be digitally signed by the MAAS server sending it.
ADDRESS-IN-USE
This AAP message is multicast periodically from a MAAS server to all
other MAAS servers 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 server that notices a
PROVISIONAL-ADDRESS-ALLOCATION 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 server sending it.
ADDRESS-DELETION
This AAP message is multicast once by the same MAAS server that
listed the address contained in the message in an ADDRESS-IN-USE
message. It is OPTIONAL. If it is sent, it MUST be digitally signed.
M. Handley [Page 4]
Internet Draft AAP December 15, 1997
It MUST NOT be sent unless the corresponding ADDRESS-IN-USE message
was also digitally signed.
ADDRESS-SPACE-REQUIRED
The AAP message is periodically multicast from a MAAS server to all
the MASC routers for the domain indicating the current address space
requirements. It contains a set of numbers of addresses and the
expiry dates for each of those numbers of addresses.
These messages SHOULD be digitally signed. If any MAAS server in the
domain is trusted by the MASC routers, that server should send the
ADDRESS-SPACE-REQUIRED messages. If not, any MAAS server 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
server calculates the address space required is explained in section
XXX.
3 Specification of MAAS Server Behaviour
When a MAAS server 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 ADDRESS-SET-ANNOUNCE
message. If it does not receive an ADDRESS-SET-ANNOUNCE message
within this time, it MAY respond to an allocation request only if it
has cached a previous ADDRESS-SET-ANNOUNCE message which includes at
least one range that has not reached its end time.
When a MAAS server receives a request for the allocation of an
address, that request will contain a start and end-time. The MAAS
server SHOULD choose the address-set from those that were advertised
to it that satisfies the greatest proportion of the time in the
request. From that address-set it SHOULD then choose at random an
address that is not already being advertised by any MAAS server. It
should then send this address in a PROVISIONAL-ADDRESS-ALLOCATION
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 server receives a PROVISIONAL-ADDRESS-ALLOCATION message
or an ADDRESS-IN-USE message from another MAAS server listing the
same addres before the timer expires, then it should cancel the
timer, choose another address in the same manner, send another
PROVISIONAL-ADDRESS-ALLOCATION message listing the new address, and
set a new timer for ANNOUNCE-WAIT seconds in the future. Such a MAAS
server MAY also resend the PROVISIONAL-ADDRESS-ALLOCATION after
RESEND-WAIT seconds, and again after a further RESEND-WAIT*2 seconds,
doubling each time until the timer expires.
M. Handley [Page 5]
Internet Draft AAP December 15, 1997
If the timer expires, the MAAS server can conclude that there is a
good probability that the address is unique, and it can then send an
ADDRESS-IN-USE 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 server MUST send ADDRESS-IN-USE messages periodically for all
the addresses that it currently has allocated. Each of these
addresses SHOULD be included in an ADDRESS-IN-USE message every
BASE-REPEAT-INTERVAL seconds +/- 30% of this value to avoid
synchronisation effects. A MAAS server that has allocated an address
MAY resend that address again after RESEND-WAIT seconds, and again
after a further RESEND-WAIT*2 seconds, doubling each time until the
interval reached BASE-REPEAT-INTERVAL seconds.
In some circumstances a MAAS server 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 ADDRESS-IN-USE 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 server 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
interrim reply to the client indicating how long it expects
allocation to take.
3.1 Triggered Responses
When a MAAS server A receives a PROVISIONAL-ADDRESS-ALLOCATION
message from MAAS server B containing an address that clashes with an
address in its cache, it should set a timer based on the algorithm
below. If server A sees an ADDRESS-IN-USE 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 a
PROVISIONAL-ADDRESS-ALLOCATION 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 ADDRESS-IN-USE message
containing the address in question, and should restart the timer with
M. Handley [Page 6]
Internet Draft AAP December 15, 1997
twice its previous value, unless that value was 0, in which case it
sets it to INITIAL-TIMER.
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)
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 MAAS servers in the domain.
This equation results is an exponential random distribution
between D1 and D2 seconds. The value of D2 is useful for up to
several thousand MAAS servers in a domain to ensure that close
to one server responds.
If a MAAS server has sent a PROVISIONAL-ADDRESS-ALLOCATION message
and has an ANNOUNCE-WAIT timer running, and it receives another
PROVISIONAL-ADDRESS-ALLOCATION message from another MAAS server, it
SHOULD immediately choose another multicast address and send a new
PROVISIONAL-ADDRESS-ALLOCATION message with the same sequence number.
It MUST NOT send an ADDRESS-IN-USE message in this state in response
to a PROVISIONAL-ADDRESS-ALLOCATION message. It does not matter which
server chooses a new address in these circumstanes, 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
M. Handley [Page 7]
Internet Draft AAP December 15, 1997
administrative scoping only.
3.3 AAP Timers
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 3 seconds.
RESEND-WAIT
RESEND-WAIT defaults to 1 second.
INITIAL-TIMER
INITITAL-TIMER defaults to DEFAULT-RTT.
DEFAULT-RTT
DEFAULT-RTT defaults to 100ms.
DEFAULT-D2
DEFAULT-D2 defaults to 3.0s.
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 ADDRESS-IN-USE message.
M. Handley [Page 8]
Internet Draft AAP December 15, 1997
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 | SEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
version (V): 4 bits
This field identified 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
M. Handley [Page 9]
Internet Draft AAP December 15, 1997
This field indicates the type of AAP packet this is. It is one of the
following values:
0. ADDRESS-SET-ANNOUNCE
1. SERVER-SIGNATURE
2. PROVISIONAL-ADDRESS-ALLOCATION
3. ADDRESS-IN-USE
4. ADDRESS-DELETION
5. ADDRESS-SPACE-REQUIRED
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.
Sequence (SEQ): 8 bits
This field is a sequence number. The first packet an AAP host sends
should have sequence number 0, and the sequence number should be
incremented for every subsequent packet, modulo 256.
The sequence number is not needed to uniquely identify packets, but
can be used to get an idea of packet loss rates within an allocation
domain. This information may be useful in deciding some parameters
for address allocation.
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
M. Handley [Page 10]
Internet Draft AAP December 15, 1997
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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 ADDRESS-SET-ANNOUNCE 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 allocater. 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 MAAS servers MUST be able to cope with discontiguous
masks, although in some cases only contiguous masks may be supplied
by MASC.
M. Handley [Page 11]
Internet Draft AAP December 15, 1997
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 PROVISIONAL-ADDRESS-ALLOCATION
A PROVISIONAL-ADDRESS-ALLOCATION packet for IPv4 contains the current
time at the MAAS server 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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-IN-USE
An ADDRESS-IN-USE packet for IPv4 contains the current time at the
MAAS server, a refresh timeout, and one or more addresses as for
PROVISIONAL-ADDRESS-ALLOCATION.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M. Handley [Page 12]
Internet Draft AAP December 15, 1997
| Current Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+
M. Handley [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-23 10:32:19 |