GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2909

Network Working Group P. Radoslavov Request for Comments: 2909 D. Estrin Category: Experimental R. Govindan

                                                               USC/ISI
                                                            M. Handley
                                                                 ACIRI
                                                              S. Kumar
                                                               USC/ISI
                                                             D. Thaler
                                                             Microsoft
                                                        September 2000
          The Multicast Address-Set Claim (MASC) Protocol

Status of this Memo

 This memo defines an Experimental Protocol for the Internet
 community.  It does not specify an Internet standard of any kind.
 Discussion and suggestions for improvement are requested.
 Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

 This document describes the Multicast Address-Set Claim (MASC)
 protocol which can be used for inter-domain multicast address set
 allocation.  MASC is used by a node (typically a router) to claim and
 allocate one or more address prefixes to that node's domain.  While a
 domain does not necessarily need to allocate an address set for hosts
 in that domain to be able to allocate group addresses, allocating an
 address set to the domain does ensure that inter-domain group-
 specific distribution trees will be locally-rooted, and that traffic
 will be sent outside the domain only when and where external
 receivers exist.

Radoslavov, et al. Experimental [Page 1] RFC 2909 The MASC Protocol September 2000

Table of Contents

 1 Introduction ..................................................  4
 1.1 Terminology .................................................  4
 1.2 Definitions .................................................  4
 2 Requirements for Inter-Domain Address Allocation ..............  5
 3 Overall Architecture ..........................................  5
 3.1 Claim-Collide vs. Query-Response Rationale ..................  6
 4 MASC Topology .................................................  6
 4.1 Managed vs Locally-Allocated Space ..........................  8
 4.2 Prefix Lifetime .............................................  8
 4.3 Active vs. Deprecated Prefixes ..............................  9
 4.4 Multi-Parent Sibling-to-Sibling and Internal Peering ........  9
 4.5 Administratively-Scoped Address Allocation ..................  9
 5 Protocol Details .............................................. 10
 5.1 Claiming Space .............................................. 10
 5.1.1 Claim Comparison Function ................................. 12
 5.2 Renewing an Existing Claim .................................. 12
 5.3 Expanding an Existing Prefix ................................ 12
 5.4 Releasing Allocated Space ................................... 13
 6 Constants ..................................................... 13
 7 Message Formats ............................................... 14
 7.1 Message Header Format ....................................... 14
 7.2 OPEN Message Format ......................................... 15
 7.3 UPDATE Message Format ....................................... 17
 7.4 KEEPALIVE Message Format .................................... 21
 7.5 NOTIFICATION Message Format ................................. 21
 8 MASC Error Handling ........................................... 24
 8.1 Message Header Error Handling ............................... 24
 8.2 OPEN Message Error Handling ................................. 25
 8.3 UPDATE Message Error Handling ............................... 26
 8.4 Hold Timer Expired Error Handling ........................... 28
 8.5 Finite State Machine Error Handling ......................... 28
 8.6 NOTIFICATION Message Error Handling ......................... 28
 8.7 Cease ....................................................... 29
 8.8 Connection Collision Detection .............................. 29
 9 MASC Version Negotiation ...................................... 30
 10 MASC Finite State Machine .................................... 30
 10.1 Open/Close MASC Connection FSM ............................. 31
 11 UPDATE Message Processing .................................... 35
 11.1 Accept/Reject an UPDATE .................................... 36
 11.2 PREFIX_IN_USE Message Processing ........................... 38
 11.2.1 PREFIX_IN_USE by PARENT .................................. 38
 11.2.2 PREFIX_IN_USE by SIBLING ................................. 38
 11.2.3 PREFIX_IN_USE by CHILD ................................... 38
 11.2.4 PREFIX_IN_USE by INTERNAL_PEER ........................... 38
 11.3 CLAIM_DENIED Message Processing ............................ 39
 11.3.1 CLAIM_DENIED by CHILD or SIBLING ......................... 39

Radoslavov, et al. Experimental [Page 2] RFC 2909 The MASC Protocol September 2000

 11.3.2 CLAIM_DENIED by INTERNAL_PEER ............................ 39
 11.3.3 CLAIM_DENIED by PARENT ................................... 39
 11.4 CLAIM_TO_EXPAND Message Processing ......................... 39
 11.4.1 CLAIM_TO_EXPAND by PARENT ................................ 39
 11.4.2 CLAIM_TO_EXPAND by SIBLING ............................... 40
 11.4.3 CLAIM_TO_EXPAND by CHILD ................................. 40
 11.4.4 CLAIM_TO_EXPAND by INTERNAL_PEER ......................... 40
 11.5 NEW_CLAIM Message Processing ............................... 41
 11.6 PREFIX_MANAGED Message Processing.  ........................ 41
 11.6.1 PREFIX_MANAGED by PARENT ................................. 41
 11.6.2 PREFIX_MANAGED by CHILD or SIBLING ....................... 41
 11.6.3 PREFIX_MANAGED by INTERNAL_PEER .......................... 41
 11.7 WITHDRAW Message Processing ................................ 42
 11.7.1 WITHDRAW by CHILD ........................................ 42
 11.7.2 WITHDRAW by SIBLING ...................................... 42
 11.7.3 WITHDRAW by INTERNAL ..................................... 42
 11.7.4 WITHDRAW by PARENT ....................................... 43
 11.8 UPDATE Message Ordering .................................... 43
 11.8.1 Parent to Child .......................................... 43
 11.8.2 Child to Parent .......................................... 44
 11.8.3 Sibling to Sibling ....................................... 44
 11.8.4 Internal to Internal ..................................... 44
 12 Operational Considerations ................................... 45
 12.1 Bootup Operations .......................................... 45
 12.2 Leaf and Non-leaf MASC Domain Operation .................... 45
 12.3 Clock Skew Workaround ...................................... 45
 12.4 Clash Resolving Mechanism .................................. 46
 12.5 Changing Network Providers ................................. 47
 12.6 Debugging .................................................. 47
 12.6.1 Prefix-to-Domain Lookup .................................. 47
 12.6.2 Domain-to-Prefix Lookup .................................. 47
 13 MASC Storage ................................................. 47
 14 Security Considerations ...................................... 48
 15 IANA Considerations .......................................... 48
 16 Acknowledgments .............................................. 48
 17 APPENDIX A: Sample Algorithms ................................ 49
 17.1 Claim Size and Prefix Selection Algorithm .................. 49
 17.1.1 Prefix Expansion ......................................... 49
 17.1.2 Reducing Allocation Latency .............................. 50
 17.1.3 Address Space Utilization ................................ 50
 17.1.4 Prefix Selection After Increase of Demand ................ 50
 17.1.5 Prefix Selection After Decrease of Demand ................ 51
 17.1.6 Lifetime Extension Algorithm ............................. 51
 18 APPENDIX B: Strawman Deployment .............................. 51
 19 Authors' Addresses ........................................... 52
 20 References ................................................... 54
 21 Full Copyright Statement ..................................... 56

Radoslavov, et al. Experimental [Page 3] RFC 2909 The MASC Protocol September 2000

1. Introduction

 This document describes MASC, a protocol for inter-domain multicast
 address set allocation.  The MASC protocol (a Layer-3 protocol in the
 multicast address allocation architecture [MALLOC]) is used by a node
 (typically a router) to claim and allocate one or more address
 prefixes to that node's domain.  Each prefix has an associated
 lifetime, and is chosen out of a larger prefix with a lifetime at
 least as long, in a manner such that prefixes are aggregatable.  At
 any time, each MASC node (a Prefix Coordinator in [MALLOC]) will
 typically advertise several prefixes with different lifetimes and
 scopes, allowing Multicast Address Allocation Servers (MAAS's) in
 that domain or child MASC domains to choose appropriate addresses for
 their clients.
 The set of prefixes ("address set") associated with a domain is
 injected into an inter-domain routing protocol (e.g., BGP4+ [MBGP]),
 where it can be used by an inter-domain multicast tree construction
 protocol (e.g., BGMP [BGMP]) to construct inter-domain group-shared
 trees.
 Note that a domain does not need to allocate an address set for the
 hosts in that domain to be able to allocate group addresses, nor does
 allocating necessarily guarantee that hosts in other domains will not
 use an address in the set (since, for example, hosts are not forced
 to contact a MAAS before using a group address).  Allocating an
 address set to a domain does, however, ensure that inter-domain
 group-specific multicast distribution trees for any group in the
 address set will be locally-rooted, and that traffic will be sent
 outside the given domain only when and where external receivers
 exist.

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 [RFC2119].
 Constants used by this protocol are shown as [NAME_OF_CONSTANT], and
 summarized in Section 6.

1.2. Definitions

 This specification uses a number of terms that may not be familiar to
 the reader. This section defines some of these and refers to other
 documents for definitions of others.

Radoslavov, et al. Experimental [Page 4] RFC 2909 The MASC Protocol September 2000

 MAAS (Multicast Address Allocation Server)
    A host providing multicast address allocation services to end
    users (e.g. via MADCAP [MADCAP]).
 MASC server
    A node running MASC.
 Peer
    Other MASC speakers a node directly communicates with.
 Multicast
    IP Multicast, as defined for IPv4 in [RFC1112] and for IPv6 in
    [RFC2460].
 Multicast Address
    An IP multicast address or group address, as defined in [RFC1112]
    and [RFC2373].  An identifier for a group of nodes.

2. Requirements for Inter-Domain Address Allocation

 The key design requirements for the inter-domain address allocation
 mechanism are:
 o  Efficient address space utilization when space is scare, which
    naturally implies that address allocations be based on the actual
    address usage patterns, and therefore that it be dynamic.
 o  Address aggregation, that implies that the address allocation
    mechanism be hierarchical.
 o  Minimize flux in the allocated address sets (e.g. the address sets
    should be reused when possible).
 o  Robustness, by using decentralized mechanisms.
 The timeliness in obtaining an address set is not a major design
 constraint as this is taken care of at a lower level [MALLOC].

3. Overall Architecture

 The Multicast Address Set Claim (MASC) protocol is used by MASC
 domains to claim and allocate address sets for use by Multicast
 Address Allocation Servers (MAASs) within each domain.  Typically one
 or more border routers of each domain that requires multicast address
 space of its own would run MASC.  Throughout this document, the term
 "MASC domain" refers to a domain that has at least one node running
 MASC; typically these domains will be Autonomous Systems (AS's).  A
 MASC node (on behalf of its domain) chooses an address set to claim,

Radoslavov, et al. Experimental [Page 5] RFC 2909 The MASC Protocol September 2000

 sends a claim to other MASC domains in the network, and waits while
 listening for any colliding claims. If there is a collision, the
 losing claimer gives up the colliding claim and claims a different
 address set.
 After a sufficiently long collision-free waiting period, the address
 set chosen by a MASC node is considered allocated to that node's
 domain.  Three things may then happen:
 a) The allocated prefix can then be injected as a "multicast route"
    into the inter-domain routing protocol  (e.g., BGP4+ [MBGP]) as
    "G-RIB" Network Layer Reachability Information (NLRI), where it
    may be used by an inter-domain multicast routing protocol (e.g.,
    BGMP [BGMP]) to construct group-shared trees.  To reduce the size
    and slow the growth of the G-RIB, MASC nodes may perform CIDR-like
    aggregation [CIDR] of the multicast NLRI information.  This
    motivates the need for an algorithm to select prefixes for domains
    in such a way as to ensure good aggregation in addition to
    achieving good address space utilization.
 b) The node's domain may assign to itself a sub-prefix which can be
    used by MAASs within the domain.
 c) Sub-prefixes may be allocated to child domains, if any.

3.1. Claim-Collide vs. Query-Response Rationale

 We choose a claim-collide mechanism instead of a query-response
 mechanism for the following reasons.  In a query-response mechanism,
 replicas of the MASC node would be needed in parent MASC domains in
 order to make their responses be robust to failures.  This brings
 about the associated problem of synchronization of the replicas and
 possibly additional fragmentation of the address space.  In addition,
 even in this mechanism, address collisions would still need to be
 handled.  We believe the proposed claim-collide mechanism is simpler
 and more robust than a query-response mechanism.

4. MASC Topology

 The domain hierarchy used by MASC is congruent to the somewhat
 hierarchical structure of the inter-domain topology, e.g., backbones
 connected to regionals, regionals connected to metropolitan
 providers, etc.  As in BGP, MASC connections are locally configured.
 A MASC domain that is a customer of other MASC domains will have one
 or more of those provider domains as its parent.  For example, a MASC
 domain that is a regional provider will choose one (or more) of its
 backbone provider domains as its parent(s).  Children are configured
 with their parent MASC domain, and parents are configured with their

Radoslavov, et al. Experimental [Page 6] RFC 2909 The MASC Protocol September 2000

 children domains.  At the top, a  number of Top-Level Domains are
 connected in a (sparse) mesh and share the global multicast address
 space.  To improve the robustness, a pair of children of the same
 parent domain MAY be configured as siblings with regard to that
 parent.
 Figure 1 illustrates a sample topology.  Double-line links denote
 intra-domain TCP peering sessions, and single-line links denote
 inter-domain TCP connections. T1 and T2 are Top-Level Domains (e.g.,
 backbone providers), containing MASC speakers T1a and T2a,
 respectively.  P3 and P4 are regional domains, containing (P3a, P3b),
 and (P4a, P4b) respectively.  P3 has a single customer (or "child"),
 C5, containing (C5a, C5b, C5c).  P4 has three children, C5, C6, C7,
 containing (C5a, C5b, C5c), (C6a, C6b), and (C7a) respectively.
                       T1a-----------T2a
                        |             |
                        |             |
                        |             |
                P3a====P3b           P4a====P4b
                 |      |           / |    / | \
                 |      |   _______/  |   /  |  \
                 |      |  /          |  /   |   \______
                 |      | /           | /    |          \
                C5a====C5b           C6a====C6b----------C7a
                  \\  //
                   \\//
                   C5c
                Figure 1: Example MASC Topology
 All MASC communications use TCP. Each MASC node is connected to and
 communicates directly with other MASC nodes.  The local node acts in
 exactly one of the following four roles with respect to each remote
 note:
 INTERNAL_PEER
    The local and remote nodes are both in the same MASC domain.  For
    example, P4b is an INTERNAL_PEER of P4a.
 CHILD
    A customer relationship exists whereby the local node may obtain
    address space from the remote node.  For example, C6a is a CHILD
    in its session with P4a.

Radoslavov, et al. Experimental [Page 7] RFC 2909 The MASC Protocol September 2000

 PARENT
    A provider relationship exists whereby the remote node may obtain
    address space from the local node.  For example, T2a is a PARENT
    in its session with P4a.  Whether space is actually requested is
    up to the implementation and local policy configuration.
 SIBLING
    No customer-provider relationship exists.  For example, T2a is a
    SIBLING in its session with T1a (Top-Level Domain SIBLING
    peering).  Also, C6b is a SIBLING in its session with C7a with
    regard to their common parent P4.
 A node's message will be propagated to its parent, all siblings with
 the same parent, and its children.  Since a domain need not have a
 direct peering session with every sibling, a MASC domain must
 propagate messages from a child domain to other children, can
 propagate messages from a parent domain to other siblings, and, if a
 Top-Level Domain, it must propagate messages from a sibling to other
 siblings, otherwise may propagate messages from a sibling domain to
 its parent and other siblings.

4.1. Managed vs Locally-Allocated Space

 Each domain has a "Managed" Address Set, and a "Locally-Allocated"
 Address Set.  The "managed" space includes all address space which a
 domain has successfully claimed via MASC.  The "locally-allocated"
 space, on the other hand, includes all address space which MAASs
 inside the domain may use.  Thus, the locally-allocated space is a
 subset of the managed space, and refers to the portion which a domain
 allocates for its own use.
 For leaf domains (ones with no children), these two sets are
 identical, since all claimed space is allocated for local use.  A
 parent domain, on the other hand, "manages" all address space which
 it has claimed via MASC, while sub-prefixes can be allocated to
 itself and to its children.

4.2. Prefix Lifetime

 Each prefix has an associated lifetime.  If a domain wants to use a
 prefix longer than its lifetime, that domain must "renew" the prefix
 BEFORE its lifetime expires (see Section 5.2).  If the lifetime
 cannot be extended, then the domain should either retry later to
 extend, or should choose and claim another prefix.

Radoslavov, et al. Experimental [Page 8] RFC 2909 The MASC Protocol September 2000

 After a prefix's lifetime expires, MASC nodes in the domain that own
 that prefix must stop using that prefix.  The corresponding entry
 from the G-RIB database must be removed, and all information
 associated with the expired prefix may be deleted from the MASC
 node's local memory.

4.3. Active vs. Deprecated Prefixes

 Each prefix advertised by a parent to its children can be either
 "active" or "deprecated".  A "deprecated" prefix is a prefix that the
 parent wishes to discontinue to use after its lifetime expires.  The
 "active" prefixes only are candidates for size expansion or lifetime
 extension.  Usually, this information will be used by a child as a
 hint to know which of the parent's prefixes might have their lifetime
 extended.

4.4. Multi-Parent Sibling-to-Sibling and Internal Peering

 Two sibling nodes that have more than one common parent will create
 and use between them a number of transport-level connections, one per
 each common parent.  The information associated with a parent will be
 sent over the connection that corresponds to the same parent.
 Internal peers do not need to open multiple connections between them;
 a single connection is used for all information.

4.5. Administratively-Scoped Address Allocation

 MASC can also be used for sub-allocating prefixes of addresses within
 an administrative scope zone [SCOPE], but only if the scope is
 "divisible" (as described in [MALLOC] and [MZAP]).  A MASC node can
 learn what scopes it resides within by listening to MZAP [MZAP]
 messages.
 A "Zone TLD" is a domain which has no parent domain within the scope
 zone.  Zone TLDs act as TLDs for the prefix associated with the
 scope.  Figure 2 gives an example, where a scope boundary around
 domains P3 and C5 has been added to Figure 1.  Domain P3 is a Zone
 TLD, since its only parent (T1) is outside the boundary.  Hence, P3
 can claim space directly out of the prefix associated with the scope
 itself.  Domain C5, on the other hand, has a parent within the scope
 (namely, P3), and hence is not a Zone TLD.

Radoslavov, et al. Experimental [Page 9] RFC 2909 The MASC Protocol September 2000

                               T1a-----------T2a
                                |             |
                    ............|.......      |
                    .           |      .      |
                    .   P3a====P3b     .     P4a
                    .    |      |      .    /
                    .    |      |   _______/
                    .    |      |  /   .
                    .    |      | /    .
                    .   C5a====C5b     .
                    .     \\  //       .
                    .      \\//        .
                    .      C5c         .
                    .                  .
                    . Admin Scope Zone .
                    ....................
               Figure 2: Scope Zone Example
 It is assumed that the role of a node (as discussed in Section 4)
 with respect to a given peering session is the same for every scope
 in which both ends are contained.  A peering session that crosses a
 scope boundary (such as the session between C5b and P4a in Figure 2)
 is ignored when propagating messages that pertain to the given scope.
 That is, such messages are not sent across such sessions.

5. Protocol Details

5.1. Claiming Space

 When a MASC node, on behalf of a MASC domain, needs more address
 space, it decides locally the size and the value of the address
 prefix(es) it will claim from one of its parents.  For example, the
 decision might be based on the knowledge this node has about its
 parent's address set, its siblings' claims and allocations, its own
 address set, the claim messages from its siblings, and/or the demand
 pattern of its children and the local domain.  A sample algorithm is
 given in Appendix A.
 A MASC node which is not in a top-level domain can initiate a claim
 toward a parent MASC domain if and only if it currently has an
 established connection with at least one node in that parent domain.
 After the prefix address and size are decided, the claim proceeds as
 follows:

Radoslavov, et al. Experimental [Page 10] RFC 2909 The MASC Protocol September 2000

 a) The claim is scheduled to be sent after a random delay in the
    interval (0, [INITIATE_CLAIM_DELAY]).  If a claim originated by a
    node from the same MASC domain is received, and that claim
    eliminates the need for the local claim, the local claim is
    canceled and no further action is taken.
 b) The claim is sent to one of the parents (if the domain is not a
    top-level domain), all known siblings with the same parent, and
    all internal peers.  A Claim-Timer is then started at
    [WAITING_PERIOD], and the MASC node starts listening for colliding
    claims.
 c) If a colliding claim is received while the Claim-Timer is running,
    that claim is compared with the locally initiated claim using the
    function described in Section 5.1.1.  If the local claim is the
    loser, a new prefix must be chosen to claim, and the loser claim's
    Claim-Timer must be canceled.  The loser claim can be either
    explicitly withdrawn, or can be left to expire without taking
    further actions.  If the winning claim was originated by a node
    from the same MASC domain, no new claim will be initiated.  If the
    local claim is the winner, no actions need to be taken.
 d) If the Claim-Timer expires, the claimed prefix becomes associated
    with the claimer's domain, i.e. it is considered allocated to that
    domain and the following actions can be performed:
    o  Advertise the prefix to its parent, and to all siblings with
       the same parent, by sending a PREFIX_IN_USE claim to them.
    o  Inject the prefix into the G-RIB of the inter-domain routing
       protocol.
    o  Send a PREFIX_MANAGED message to all children and internal
       peers, informing them that they may issue claims within the
       managed space.  A sub-prefix may then be claimed for local
       usage (see Section 12.2).
 Each MASC node receives all claims from its siblings and children.  A
 received claim must be evaluated against all claims saved in the
 local cache using the function described in Section 5.1.1.  The
 output of the function will define the further processing of that
 claim (see Section 11).

Radoslavov, et al. Experimental [Page 11] RFC 2909 The MASC Protocol September 2000

5.1.1. Claim Comparison Function

 Each claim message includes:
 o  a "type", being one of: PREFIX_IN_USE, CLAIM_DENIED,
    CLAIM_TO_EXPAND, or NEW_CLAIM  (PREFIX_MANAGED and WITHDRAW are
    not considered as claims that have to be compared)
 o  timestamp when the claim was initiated
 o  the claimed prefix and lifetime
 o  MASC Identifier of the node that originated the claim
 When two claims are compared, first the type is compared based on the
 following precedence:
 PREFIX_IN_USE > CLAIM_DENIED > CLAIM_TO_EXPAND > NEW_CLAIM
 If the type is the same, then the timestamps are used to compare the
 claims.  In practice, two claims will have the same type if the type
 is either NEW_CLAIM (ordinary collision) or PREFIX_IN_USE (signal for
 a clash).  When the timestamps are compared, the claim with the
 smallest, i.e. earliest timestamp wins.  If the timestamps are the
 same, then the claim with the smallest Origin Node Identifier wins.

5.2. Renewing an Existing Claim

 The procedure for extending the lifetime of prefixes already in use
 is the same as claiming new space (see Section 5.1), except that the
 claim type must be CLAIM_TO_EXPAND, while the Address and the Mask of
 the claim (see Section 7.3) must be the same as the already allocated
 prefix.  If the Claim-Timer expires and there is no collision, the
 desired lifetime is assumed.

5.3. Expanding an Existing Prefix

 The procedure for extending the lifetime of prefixes already in use
 is the same as claiming new space (see Section 5.1), except that the
 claim type must be CLAIM_TO_EXPAND, while the Address and the Mask of
 the claim (see Section 7.3) must be set to the desired values.  If
 the Claim-Timer expires and there is no collision, the desired larger
 prefix is associated with the local domain.

Radoslavov, et al. Experimental [Page 12] RFC 2909 The MASC Protocol September 2000

5.4. Releasing Allocated Space

 If the lifetime of a prefix allocated to the local domain expires and
 the domain does not need to reuse it, all resources associated with
 this prefix are deleted and no further actions are taken.  If the
 lifetime of the prefix has not expired, and if no subranges of that
 prefix have being allocated for local usage or by some of the
 children domains, the space may be released by sending a withdraw
 message to the parent domain, all known siblings with the same
 parent, and all internal peers.

6. Constants

 MASC uses the following constants:
 [PORT_NUMBER]
    2587.  The TCP port number used to listen for incoming MASC
    connections, as assigned by IANA.
 [WAITING_PERIOD]
    The amount of time (in seconds) that must pass between a NEW_CLAIM
    (or CLAIM_TO_EXPAND), and a PREFIX_IN_USE for the same prefix.
    This must be long enough to reasonably span any single inter-
    domain network partition.  Default: 172800 seconds (i.e. 48
    hours).
 [INITIATE_CLAIM_DELAY]
    The amount of time (in seconds) a MASC node must wait before
    initiating a new claim or a claim for space expansion. This must
    be a random value in the interval (0, [INITIATE_CLAIM_DELAY]).
    Default value for [INITIATE_CLAIM_DELAY]: 600 seconds (i.e. 10
    minutes).
 [TLD_ID]
    The Parent Domain Identifier used by a Top-Level Domain (which has
    no parent). Must be 0.
 [HOLDTIME]
    The amount of time (in seconds) that must pass without any
    messages received from a remote node before considering the
    connection is down.  Default: 240 seconds (i.e. 4 minutes).

Radoslavov, et al. Experimental [Page 13] RFC 2909 The MASC Protocol September 2000

7. Message Formats

 This section describes message formats used by MASC.
 Messages are sent over a reliable transport protocol connection.  A
 message is processed only after it is entirely received.  The maximum
 message size is 4096 octets.  All implementations are required to
 support this maximum message size.

7.1. Message Header Format

 Each message has a fixed-size (4-octets) header.  There may or may
 not be a data portion following the header, depending on the message
 type.  The layout of these fields is shown below:
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          Length               |      Type     |   Reserved    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Length:
    This 2-octet unsigned integer indicates the total length of the
    message, including the header, in octets.  Thus, e.g., it allows
    one to locate in the transport-level stream the start of the next
    message.  The value of the Length field must always be at least 4
    and no greater than 4096, and may be further constrained,
    depending on the message type.  No "padding" of extra data after
    the message is allowed, so the Length field must have the smallest
    value required given the rest of the message.
 Type:
    This 1-octet unsigned integer indicates the type code of the
    message.  The following type codes are defined:
          1 - OPEN
          2 - UPDATE
          3 - NOTIFICATION
          4 - KEEPALIVE
 Reserved:
    This 1-octet field is reserved.  MUST be set to zero by the sender,
    and MUST be ignored by the receiver.

Radoslavov, et al. Experimental [Page 14] RFC 2909 The MASC Protocol September 2000

7.2. OPEN Message Format

 After a transport protocol connection is established, the first
 message sent by each side is an OPEN message.  If the OPEN message is
 acceptable, a KEEPALIVE message confirming the OPEN is sent back.
 Once the OPEN is confirmed, UPDATE, KEEPALIVE, and NOTIFICATION
 messages may be exchanged.
 The minimum length of the OPEN message is 20 octets (including
 message header).  In addition to the fixed-size MASC header, the OPEN
 message contains the following fields:
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Version    |R| AddrFam |Rol|           Hold Time           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Sender Domain Identifier    (variable length)         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Sender MASC Node Identifier (variable length)         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Parent's Domain Identifier  (variable length)         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                     (Optional Parameters)                     |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Version:
    This 1-octet unsigned integer indicates the protocol version
    number of the message.  The current MASC version number is 1.
 R bit:
    This 1-bit field is reserved.  MUST be set to zero by the sender,
    and MUST be ignored by the receiver.
 AddrFam:
    This 5-bit field is the IANA-assigned address family number of the
    encoded prefix [IANA].  These include (among others):
    Number    Description
    ------    -----------
       1      IP (IP version 4)
       2      IPv6 (IP version 6)

Radoslavov, et al. Experimental [Page 15] RFC 2909 The MASC Protocol September 2000

 My Role (Rol):
    This 2-bit field indicates the proposed relationship of the
    sending system to the receiving system:
       00 = INTERNAL_PEER (sent from one internal peer to another)
       01 = CHILD (sent from a child to its parent)
       10 = SIBLING (sent from one sibling to another)
       11 = PARENT (sent from a parent to its child)
 Hold Time:
    This 2-octet unsigned integer indicates the number of seconds that
    the sender proposes for the value of the Hold Timer.  Upon receipt
    of an OPEN message, a MASC speaker MUST calculate the value of the
    Hold Timer by using the smaller of its configured Hold Time for
    that peer and the Hold Time received in the OPEN message.  The
    Hold Time MUST be either zero or at least three seconds.  An
    implementation may reject connections on the basis of the Hold
    Time.  The calculated value indicates the maximum number of
    seconds that may elapse between the receipt of successive
    KEEPALIVE and/or UPDATE messages by the sender.  RECOMMENDED value
    is [HOLDTIME] seconds.
 Sender Domain Identifier:
    A globally unique identifier.  Its length is determined based on
    the Address Family, and should be treated as an unsigned integer
    (e.g. a 4-octet integer for IPv4, or a 16-octet integer for IPv6),
    but must be at least 4 octets long.  It should be set to the
    Autonomous System number of the sender, but the network unicast
    prefix address is also acceptable.
 Sender MASC Node Identifier:
    This field's length and format are same as the Sender Domain
    Identifier field, and indicates the MASC Node Identifier of the
    sender.  A given MASC speaker sets the value of its MASC Node
    Identifier to a globally-unique value assigned to that MASC
    speaker (e.g., an IPv4 or IPv6 address).  The value of the MASC
    Node Identifier is determined on startup and is the same for every
    MASC session opened.
 Parent's Domain Identifier:
    This field's length and format are same as the Sender Domain
    Identifier field, and is set to the Domain Identifier of the
    sender's parent (e.g. the parent's Autonomous System number, or
    network prefix address), or is set to [TLD_ID] if the sender is a
    TLD.  Used only when Rol is INTERNAL_PEER or SIBLING, otherwise is
    ignored.  This field is used to determine the common parents
    between siblings, to associate each sibling-to-sibling connection
    with a particular parent, and to discover TLD-related

Radoslavov, et al. Experimental [Page 16] RFC 2909 The MASC Protocol September 2000

    configuration problems among internal peers.  If a non-TLD node
    does not know yet the Domain ID of any of its parents, it can use
    its own Domain ID in the OPEN messages to its internal peers.
 Optional Parameters:
    This field may contain a list of optional parameters, where each
    parameter is encoded as a <Parameter Length, Parameter Type,
    Parameter Value> triplet.  The combined length of all optional
    parameters can be derived from the Length field in the message
    header.
     0                   1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
    |  Parm. Length |  Parm. Type   |  Parameter Value (variable)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
    Parameter Length is a one octet field that contains the length of
    the Parameter Value field in octets.  Parameter Type is a one
    octet field that unambiguously identifies individual parameters.
    Parameter Value is a variable length field that is interpreted
    according to the value of the Parameter Type field.  Unrecognized
    optional parameters MUST be silently ignored.
    This document does not define any optional parameters.

7.3. UPDATE Message Format

 UPDATE messages are used to transfer Claim/Collision/PrefixManaged
 information between MASC speakers.  The UPDATE message always
 includes the fixed-size MASC header, and one or more attributes as
 described below.  The minimum length of the UPDATE message is 40
 octets (including the message header).
 Each attribute is of the form:
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |              Length           |     Type      |   Reserved    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Data ...                                                   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 All attributes are 4-octets aligned.

Radoslavov, et al. Experimental [Page 17] RFC 2909 The MASC Protocol September 2000

 Length:
    The Length is the length of the entire attribute, including the
    length, type, and data fields.  If other attributes are nested
    within the data field, the length includes the size of all such
    nested attributes.
 Type:
    This 1-octet unsigned integer indicates the type code of the
    attribute.  The following type codes are defined:
       0 = PREFIX_IN_USE (prefix is being used by the origin)
       1 = CLAIM_DENIED (the claim is refused (probably by the
           origin's parent domain))
       2 = CLAIM_TO_EXPAND (origin is trying to expand the size of
           an existing prefix)
       3 = NEW_CLAIM (origin is trying to claim a new prefix)
       4 = PREFIX_MANAGED (parent is informing child of space
           available)
       5 = WITHDRAW (origin is withdrawing a previous claim)
    Types 128-255 are reserved for "optional" attributes.  If a
    required attribute is unrecognized, a NOTIFICATION with UPDATE
    Error Code and Unrecognized Required Attribute subcode will be
    sent.  Unrecognized optional attributes are simply ignored.
 Reserved:
    This 1-octet field is reserved.  MUST be set to zero by the
    sender, and MUST be ignored by the receiver.
 Types 0-3 are collectively called "CLAIMs".  The message format below
 describes the encoding of a CLAIM, PREFIX_MANAGED and WITHDRAW.

Radoslavov, et al. Experimental [Page 18] RFC 2909 The MASC Protocol September 2000

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Reserved1   |D| AddrFam |Rol|           Reserved2           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Claim Timestamp                            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Claim Lifetime                             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Claim Holdtime                             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Origin Domain Identifier (variable length) |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Origin Node Identifier   (variable length) |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Address (variable length)                  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Mask    (variable length)                  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                     (Optional Parameters)                     |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Reserved1:
    This 1-octet field is reserved.  MUST be set to zero by the
    sender, and MUST be ignored by the receiver.
 D-bit:
    DEPRECATED_PREFIX bit. If set, indicates that the advertised
    address prefix is Deprecated, otherwise the prefix is Active (see
    Section 4.3).
 AddrFam:
    This 5-bit field is the IANA-assigned address family number of the
    encoded prefix [IANA].
 Rol:
    This 2-bit field indicates the relationship/role of the Origin of
    the message to the node sending that message:
       00 = INTERNAL (originated by the sender's domain)
       01 = CHILD (originated by a child of the sender's domain)
       10 = SIBLING (originated by a sibling of the sender's domain)
       11 = PARENT (originated by a parent of the sender's domain)
 Reserved2:
    This 2-octet field is reserved.  MUST be set to zero by the
    sender, and MUST be ignored by the receiver.

Radoslavov, et al. Experimental [Page 19] RFC 2909 The MASC Protocol September 2000

 Claim Timestamp:
    The timestamp of the claim when it was originated. The timestamp
    is expressed in number of seconds since midnight (0 hour), January
    1, 1970, Greenwich.
 Claim Lifetime:
    The time in seconds between the Claim Timestamp, and the time at
    which the prefix will become free.
 Claim Holdtime:
    The time in seconds between the Claim Timestamp, and the time at
    which the claim should be deleted from the local cache. For
    PREFIX_IN_USE and PREFIX_MANAGED claims it should be equal to
    Claim Lifetime; for CLAIM_TO_EXPAND, NEW_CLAIM, and CLAIM_DENIED
    it should be equal to [WAITING_PERIOD].
 Origin Domain Identifier:
    The domain identifier of the claim originator.  Its length and
    format definition are same as the Sender Domain Identifier (see
    Section 7.2).
 Origin Node Identifier:
    The MASC Node ID of the claim originator.  Its length and format
    definition are same as the Sender MASC Node Identifier (see
    Section 7.2).
 Address:
    The address associated with the given prefix to be encoded.  The
    length is determined based on the Address Family (e.g. 4 octets
    for IPv4, 16 for IPv6)
 Mask:
    The mask associated with the given prefix.  The length is the same
    as the Address field and is determined based on the Address
    Family. The field contains the full bitmask.
 Optional Parameters:
    This field may contain a list of optional parameters, where each
    parameter is encoded using same format as the optional parameters
    of an OPEN message (see Section 7.2).  Unrecognized optional
    parameters MUST be silently ignored.  This document does not
    define any optional parameters.

Radoslavov, et al. Experimental [Page 20] RFC 2909 The MASC Protocol September 2000

7.4. KEEPALIVE Message Format

 MASC does not use any transport protocol-based keep-alive mechanism
 to determine if peers are reachable.  Instead, KEEPALIVE messages are
 exchanged between peers often enough as not to cause the Hold Timer
 to expire.  A reasonable maximum time between the last KEEPALIVE or
 UPDATE message sent, and the time at which a KEEPALIVE message is
 sent, would be one third of the Hold Time interval.  KEEPALIVE
 messages MUST NOT be sent more frequently than one per second.  An
 implementation MAY adjust the rate at which it sends KEEPALIVE
 messages as a function of the Hold Time interval.
 If the negotiated Hold Time interval is zero, then periodic KEEPALIVE
 messages MUST NOT be sent.
 A KEEPALIVE message consists of only a message header, and has a
 length of 4 octets.

7.5. NOTIFICATION Message Format

 A NOTIFICATION message is sent when an error condition is detected.
 Depending on the error condition, the MASC connection might or must
 be closed immediately after sending the message.  If the sender of
 the NOTIFICATION decides that the connection is to be closed, it will
 indicate this by zeroing the O-bit in the NOTIFICATION message (see
 below).
 In addition to the fixed-size MASC header, the NOTIFICATION message
 contains the following fields:
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |O| Error code  | Error subcode |           Data                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 O-bit:
    Open-bit.  If zero, it indicates that the sender will close the
    connection.  If '1', it indicates that the sender has chosen to
    keep the connection open.
 Error Code:
    This 7-bit unsigned integer indicates the type of NOTIFICATION.
    The following Error Codes have been defined:

Radoslavov, et al. Experimental [Page 21] RFC 2909 The MASC Protocol September 2000

       Error Code       Symbolic Name               Reference
         1         Message Header Error             Section 8.1
         2         OPEN Message Error               Section 8.2
         3         UPDATE Message Error             Section 8.3
         4         Hold Timer Expired               Section 8.4
         5         Finite State Machine Error       Section 8.5
         6         NOTIFICATION Message Error       Section 8.6
         7         Cease                            Section 8.7
 Error subcode:
    This 1-octet unsigned integer provides more specific information
    about the nature of the reported error.  Each Error Code may have
    one or more Error Subcodes associated with it.  If no appropriate
    Error Subcode is defined, then a zero (Unspecific) value is used
    for the Error Subcode field, and the O-bit must be zero (i.e. the
    connection will be closed).  The notation used in the error
    description below is: MC = Must Close connection = O-bit is zero;
    CC = Can Close connection = O-bit might be zero.
             Message Header Error subcodes:
                      0 - Unspecific                        (MC)
                      1 - Bad Message Length                (MC)
                      2 - Bad Message Type                  (CC)
             OPEN Message Error subcodes:
                      0 - Unspecific                        (MC)
                      1 - Unsupported Version Number        (MC)
                      2 - Bad Peer Domain ID                (MC)
                      3 - Bad Peer MASC Node ID             (MC)
                      6 - Unacceptable Hold Time            (MC)
                      7 - Invalid Parent Configuration      (MC)
                      8 - Inconsistent Role                 (MC)
                      9 - Bad Parent Domain ID              (MC)
                     10 - No Common Parent                  (MC)
                     13 - Unrecognized Address Family       (MC)

Radoslavov, et al. Experimental [Page 22] RFC 2909 The MASC Protocol September 2000

             UPDATE Message Error subcodes:
                      0 - Unspecific                        (MC)
                      1 - Malformed Attribute List          (MC)
                      2 - Unrecognized Required Attribute   (CC)
                      5 - Attribute Length Error            (MC)
                     10 - Invalid Address field             (CC)
                     11 - Invalid Mask field                (CC)
                     12 - Non-Contiguous Mask               (CC)
                     13 - Unrecognized Address Family       (MC)
                     14 - Claim Type Error                  (CC)
                     15 - Origin Domain ID Error            (CC)
                     16 - Origin Node ID Error              (CC)
                     17 - Claim Lifetime Too Short          (CC)
                     18 - Claim Lifetime Too Long           (CC)
                     19 - Claim Timestamp Too Old           (CC)
                     20 - Claim Timestamp Too New           (CC)
                     21 - Claim Prefix Size Too Small       (CC)
                     22 - Claim Prefix Size Too Large       (CC)
                     23 - Illegal Origin Role Error         (CC)
                     24 - No Appropriate Parent Prefix      (CC)
                     25 - No Appropriate Child Prefix       (CC)
                     26 - No Appropriate Internal Prefix    (CC)
                     27 - No Appropriate Sibling Prefix     (CC)
                     28 - Claim Holdtime Too Short          (CC)
                     29 - Claim Holdtime Too Long           (CC)
       Hold Timer Expired subcodes (the O-bit is always zero):
                      0 - Unspecific                        (MC)
             Finite State Machine Error subcodes:
                      0 - Unspecific                        (MC)
                      1 - Open/Close MASC Connection FSM Error (MC)
                      2 - Unexpected Message Type FSM Error (MC)
             Cease subcodes (the O-bit is always zero):
                      0 - Unspecific                        (MC)
             NOTIFICATION subcodes (the O-bit is always zero):
                      0 - Unspecific                        (MC)
 Data:
    This variable-length field is used to diagnose the reason for the
    NOTIFICATION.  The contents of the Data field depend upon the
    Error Code and Error Subcode.  See Section 8 for more details.

Radoslavov, et al. Experimental [Page 23] RFC 2909 The MASC Protocol September 2000

    Note that the length of the Data field can be determined from the
    message Length field by the formula:
       Message Length = 6 + Data Length
    The minimum length of the NOTIFICATION message is 6 octets
    (including message header).

8. MASC Error Handling

 This section describes actions to be taken when errors are detected
 while processing MASC messages.  MASC Error Handling is similar to
 that of BGP [BGP].
 When any of the conditions described here are detected, a
 NOTIFICATION message with the indicated Error Code, Error Subcode,
 and Data fields is sent.  In addition, the MASC connection might be
 closed.  If no Error Subcode is specified, then a zero (Unspecific)
 must be used.
 The phrase "the MASC connection is closed" means that the transport
 protocol connection has been closed and that all resources for that
 MASC connection have been deallocated.
 Unless specified explicitly, the Data field of the NOTIFICATION
 message is empty.

8.1. Message Header Error Handling

 All errors detected while processing the Message Header are indicated
 by sending the NOTIFICATION message with Error Code Message Header
 Error.  The Error Subcode elaborates on the specific nature of the
 error.  The Data field contains the erroneous Message (including the
 message header).
 If the Length field of the message header is less than 4 or greater
 than 4096, or if the length of an OPEN message is less  than the
 minimum length of the OPEN message, or if the length of an UPDATE
 message is less than the minimum length of the UPDATE message, or if
 the length of a KEEPALIVE message is not equal to 4, then the Error
 Subcode is set to Bad Message Length.
 If the Type field of the message header is not recognized, then the
 Error Subcode is set to Bad Message Type.

Radoslavov, et al. Experimental [Page 24] RFC 2909 The MASC Protocol September 2000

8.2. OPEN Message Error Handling

 All errors detected while processing the OPEN message are indicated
 by sending the NOTIFICATION message with Error Code OPEN Message
 Error.  The Error Subcode elaborates on the specific nature of the
 error.  The Data field contains the erroneous OPEN Message (excluding
 the Message Header), unless stated otherwise.
 If the version number contained in the Version field of the received
 OPEN message is not supported, then the Error Subcode is set to
 Unsupported Version Number.  The Data field is a 1-octet unsigned
 integer, which indicates the largest locally supported version number
 less than the version the remote MASC node bid (as indicated in the
 received OPEN message).
 If the Sender Domain Identifier field of the OPEN message is
 unacceptable, then the Error Subcode is set to Bad Peer Domain ID.
 The determination of acceptable Domain IDs is outside the scope of
 this protocol.
 If the Sender MASC Node Identifier field of the OPEN message is
 unacceptable, then the Error Subcode is set to Bad Peer MASC Node ID.
 The determination of acceptable Node IDs is outside the scope of this
 protocol.
 If the Hold Time field of the OPEN message is unacceptable, then the
 Error Subcode MUST be set to Unacceptable Hold Time.  An
 implementation MUST reject Hold Time values of one or two seconds.
 An implementation MAY reject any proposed Hold Time.  An
 implementation which accepts a Hold Time MUST use the negotiated
 value for the Hold Time.
 If the remote system's proposed Role is INTERNAL_PEER, and either
 (but not both) the local system or the remote system's Parent Domain
 ID is [TLD_ID], then the Error Subcode is set to Invalid Parent
 Configuration.  The Data field must be filled with all the local
 system's Parent Domain IDs.
 If the remote system's proposed Role conflicts with its expected role
 (based on the local system's configured Role), then the Error Subcode
 is set to Inconsistent Role.  The Data field is 1-octet long, and
 contains the local system's configured Role.
 If the remote system's Parent Domain ID is unacceptable, then the
 Error Subcode is set to Bad Parent Domain ID, and the Data field is
 filled with the erroneous Parent Domain ID.  The determination of
 acceptable Parent Domain ID is outside the scope of this protocol.

Radoslavov, et al. Experimental [Page 25] RFC 2909 The MASC Protocol September 2000

 If the remote system is supposed to be a sibling, but it does not
 have a common parent with the local system (based on the Parent
 Domain ID information in the OPEN message), the Error Subcode is set
 to No Common Parent, and the Data field is filled with all Parent
 Domain IDs of the local MASC domain.
 If the Address Family is unrecognized, then the Error Subcode is set
 to Unrecognized Address Family.

8.3. UPDATE Message Error Handling

 All errors detected while processing the UPDATE message are indicated
 by sending the NOTIFICATION message with Error Code UPDATE Message
 Error.  The error subcode elaborates on the specific nature of the
 error.  The Data field contains the erroneous UPDATE Message
 (including the attribute header, but excluding the Message Header),
 unless stated otherwise.
 If any recognized attribute has an Attribute Length that conflicts
 with the expected length (based on the attribute type code), then the
 Error Subcode is set to Attribute Length Error.
 If any of the mandatory well-known attributes are not recognized,
 then the Error Subcode is set to Unrecognized Required Attribute.
 If the Address field includes an invalid address (except 0), then the
 Error Subcode is set to Invalid Address.
 If the Mask field includes an invalid mask (for example, starting
 with 0), then the Error Subcode is set to Invalid Mask.
 If the Mask field includes a non-contiguous bitmask, and that MASC
 server does not support, or is not configured to use non-contiguous
 masks, then the Error Subcode is set to Non-Contiguous Mask.
 If the Address Family is unrecognized, then the Error Subcode is set
 to Unrecognized Address Family.
 If the Origin Role/Claim Type combination is not one of the
 following, then the Error Subcode is set to Claim Type Error.

Radoslavov, et al. Experimental [Page 26] RFC 2909 The MASC Protocol September 2000

    Origin  Claim
    Role    Type
    ICS     PREFIX_IN_USE   (0)
    I  P    CLAIM_DENIED    (1)
    ICS     CLAIM_TO_EXPAND (2)
    ICS     NEW_CLAIM       (3)
    I  P    PREFIX_MANAGED  (4)
    ICSP    WITHDRAW        (5)
 If there is a reason to believe that the Origin Domain ID is invalid,
 then the Error Subcode is set to Origin Domain ID Error.  The same
 applies for Origin Node ID (the corresponding error is Origin Node ID
 Error).
 If a node (usually a parent receiving a claim from a child) decides
 that the Claim Lifetime is too short (for example, less than 172800,
 i.e. 48 hours), it MAY send an UPDATE Message Error with subcode
 Claim Lifetime Too Short.
 If a node (usually a parent receiving a claim from a child) decides
 that the Claim Lifetime is too long (for example, more than
 15,768,000, i.e. half year), then it MAY send an UPDATE Message Error
 with subcode Claim Lifetime Too Long.  Note that usually a parent
 MASC node should send first CLAIM_DENIED collision messages with
 Claim Lifetime field filled with the longest acceptable lifetime.  If
 the child refuses to claim with shorter lifetime, then Claim Lifetime
 Too Long should be sent.
 If a node (usually a parent receiving a claim from a child) decides
 that the Claim Timestamp is too small, i.e. too old (for example, if
 a node is self-confident that its clock is quite accurate), then it
 MUST send an UPDATE Message Error with subcode Claim Timestamp Too
 Old.  Claim Timestamp Too New is defined similarly.
 If a node (usually a parent receiving a claim from a child) decides
 that the prefix size implied by the Mask field is too small (for
 example, smaller than 16 addresses), then it MAY send an UPDATE
 Message Error with subcode Claim Prefix Size Too Small.
 If a node (usually a parent receiving a claim from a child) decides
 that the prefix size implied by the Mask field is too large, then it
 MAY send an UPDATE Message Error with subcode Claim Prefix Size Too
 Large.  Note that usually a parent MASC node should send first
 CLAIM_DENIED collision messages for some subrange of the child's
 large claimed address range.  If the child refuses to shrink the
 claim size, then Claim Prefix Size Too Large should be sent.

Radoslavov, et al. Experimental [Page 27] RFC 2909 The MASC Protocol September 2000

 If the received UPDATE message's computed Updated Origin Role is
 illegal (see Table 1 in Section 11.1), then the Error Subcode is set
 to Illegal Origin Role Error.
 If the received UPDATE message needs to be associated with a parent's
 prefix, but the association is not successful, then the Error Subcode
 is set to No Appropriate Parent Prefix.  The No Appropriate Child
 Prefix, No Appropriate Internal Prefix, and No Appropriate Sibling
 Prefix Error Subcodes are defined similarly.
 If a node decides that the Claim Holdtime is too short (for example,
 just few seconds), it MAY send an UPDATE Message Error with subcode
 Claim Holdtime Too Short.
 If a node decides that the Claim Holdtime is too long (for example,
 more than 15,768,000, i.e. half year), then it SHOULD send an UPDATE
 Message Error with subcode Claim Holdtime Too Long.
 If any other error is encountered when processing attributes, then
 the Error Subcode is set to Malformed Attribute List, and the erratic
 attribute is included in the data field.

8.4. Hold Timer Expired Error Handling

 If a system does not receive successive KEEPALIVE and/or UPDATE
 and/or NOTIFICATION messages within the period specified in the Hold
 Time field of the OPEN message, then the NOTIFICATION message with
 Hold Timer Expired Error Code must be sent and the MASC connection
 closed.

8.5. Finite State Machine Error Handling

 Any error detected by the MASC Finite State Machine (e.g., receipt of
 an unexpected event) is indicated by sending the NOTIFICATION message
 with Error Code Finite State Machine Error.  The Error Subcode
 elaborates on the specific nature of the error.

8.6. NOTIFICATION Message Error Handling

 If a node sends a NOTIFICATION message, and there is an error in that
 message, and the O-bit of that message is not zero, a NOTIFICATION
 with O-bit zeroed, Error Code of NOTIFICATION Error, and subcode
 Unspecific must be sent.  In addition, the Data field must include
 the erratic NOTIFICATION message.  However, if the erratic
 NOTIFICATION message had the O-bit zeroed, then any error, such as an
 unrecognized Error Code or Error Subcode, should be noticed, logged

Radoslavov, et al. Experimental [Page 28] RFC 2909 The MASC Protocol September 2000

 locally, and brought to the attention of the administrator of the
 remote node.  The means to do this, however, lies outside the scope
 of this document.

8.7. Cease

 In absence of any fatal errors (that are indicated in this section),
 a MASC node may choose at any given time to close its MASC connection
 by sending the NOTIFICATION message with Error Code Cease.  However,
 the Cease NOTIFICATION message must not be used when a fatal error
 indicated by this section does exist.

8.8. Connection Collision Detection

 If a pair of MASC speakers try simultaneously to establish a TCP
 connection to each other, then two parallel connections between this
 pair of speakers might well be formed.  We refer to this situation as
 connection collision.  Clearly, one of these connections must be
 closed.  Note that if the nodes were siblings, and each of those
 connections was associated with a different parent, then we do not
 consider this situation as collision (see Section 4.4).
 Based on the value of the MASC Node Identifier a convention is
 established for detecting which MASC connection is to be preserved
 when a connection collision does occur.  The convention is to compare
 the MASC Node Identifiers of the remote nodes involved in the
 collision and to retain only the connection initiated by the MASC
 speaker with the higher-valued MASC Node Identifier.
 Upon receipt of an OPEN message, the local system must examine all of
 its connections that are in the OpenConfirm state.  A MASC speaker
 may also examine connections in an OpenSent state if it knows the
 MASC Node Identifier of the remote node by means outside of the
 protocol.  If among these connections there is a connection to a
 remote MASC speaker whose MASC Node Identifier equals the one in the
 OPEN message, and, in case of a sibling-to-sibling connection, the
 Parent Domain ID of that connection equals the one in the OPEN
 message, then the local system performs the following connection
 collision resolution procedure:
 1. The MASC Node Identifier of the local system is compared to the
    MASC Node Identifier of the remote system (as specified in the
    OPEN message).  Comparing MASC Node Identifiers is done by
    treating them as unsigned integers (e.g. 4-octets long for IPv4
    and 16-octets long for IPv6).

Radoslavov, et al. Experimental [Page 29] RFC 2909 The MASC Protocol September 2000

 2. If the value of the local MASC Node Identifier is less than the
    remote one, the local system closes MASC connection that already
    exists (the one that is already in the OpenConfirm state), and
    accepts the MASC connection initiated by the remote system.
 3. Otherwise, the local system closes the newly created MASC
    connection (the one associated with the newly received OPEN
    message), and continues to use the existing one (the one that is
    already in the OpenConfirm state).
 A connection collision with an existing MASC connection that is in
 the Established state causes unconditional closing of the newly
 created connection.  Note that a connection collision cannot be
 detected with connections that are in Idle, or Connect, or Active
 states (see Section 10).
 Closing the MASC connection (that results from the collision
 resolution procedure) is accomplished by sending the NOTIFICATION
 message with the Error Code Cease.

9. MASC Version Negotiation

 MASC speakers may negotiate the version of the protocol by making
 multiple attempts to open a MASC connection, starting with the
 highest version number each supports.  If an open attempt fails with
 an Error Code OPEN Message Error, and an Error Subcode Unsupported
 Version Number, then the MASC speaker has available the version
 number it tried, the version number the remote node tried, the
 version number passed by the remote node in the NOTIFICATION message,
 and the version numbers that it supports.  If the two MASC speakers
 do support one or more common versions, then this will allow them to
 rapidly determine the highest common version. In order to support
 MASC version negotiation, future versions of MASC must retain the
 format of the OPEN and NOTIFICATION messages.

10. MASC Finite State Machine

 This section specifies MASC operation in terms of a Finite State
 Machine (FSM).  The FSM and the operations are peer peering session.
 Following is a brief summary and overview of MASC operations by state
 as determined by this FSM.
 Initially the peering session is in the Idle state.

Radoslavov, et al. Experimental [Page 30] RFC 2909 The MASC Protocol September 2000

10.1. Open/Close MASC Connection FSM

 Idle state:
    In this state MASC refuses all incoming MASC connections from the
    peer.  No resources are allocated to the remote node.  In response
    to the Start event (initiated by either system or operator) the
    local system initializes all MASC resources, starts the
    ConnectRetry timer, initiates a transport connection to the remote
    node, while listening for a connection that may be initiated by
    the remote MASC node, and changes its state to Connect.  The exact
    value of the ConnectRetry timer is a local matter, but should be
    sufficiently large to allow TCP initialization.
    If a MASC speaker detects an error, it shuts down the connection
    and changes its state to Idle. Getting out of the Idle state
    requires generation of the Start event.  If such an event is
    generated automatically, then persistent MASC errors may result in
    persistent flapping of the speaker.  To avoid such a condition it
    is recommended that Start events should not be generated
    immediately for a node that was previously transitioned to Idle
    due to an error. For a node that was previously transitioned to
    Idle due to an error, the time between consecutive generation of
    Start events, if such events are generated automatically, shall
    exponentially increase. The value of the initial timer shall be 60
    seconds. The time shall be doubled for each consecutive retry, but
    shall not be longer than 24 hours.
    Any other event received in the Idle state is ignored.
 Connect state:
    In this state MASC is waiting for the transport protocol
    connection to be completed.
    If the transport protocol connection succeeds, the local system
    clears the ConnectRetry timer, completes initialization, sends an
    OPEN message to the remote node, and changes its state to
    OpenSent. If the transport protocol connect fails (e.g.,
    retransmission timeout), the local system restarts the
    ConnectRetry timer, continues to listen for a connection that may
    be initiated by the remote MASC node, and changes its state to
    Active state.

Radoslavov, et al. Experimental [Page 31] RFC 2909 The MASC Protocol September 2000

    In response to the ConnectRetry timer expired event, the local
    system restarts the ConnectRetry timer, initiates a transport
    connection to the other MASC node, continues to listen for a
    connection that may be initiated by the remote MASC node, and
    stays in the Connect state.
    The Start event is ignored in the Connect state.
    In response to any other event (initiated by either system or
    operator), the local system releases all MASC resources associated
    with this connection and changes its state to Idle.
 Active state:
    In this state MASC is trying to acquire a remote node by listening
    for a transport protocol connection initiated by the remote node.
    If the transport protocol connection succeeds, the local system
    clears the ConnectRetry timer, completes initialization, sends an
    OPEN message to the remote node, sets its Hold Timer to a large
    value, and changes its state to OpenSent.  A Hold Timer value of
    [HOLDTIME] seconds is suggested.
    In response to the ConnectRetry timer expired event, the local
    system restarts the ConnectRetry timer, initiates a transport
    connection to other MASC node, continues to listen for a
    connection that may be initiated by the remote MASC node, and
    changes its state to Connect.
    If the local system detects that a remote node is trying to
    establish a MASC connection to it, and the IP address of the
    remote node is not an expected one, the local system restarts the
    ConnectRetry timer, rejects the attempted connection, continues to
    listen for a connection that may be initiated by the remote MASC
    node, and stays in the Active state.
    The Start event is ignored in the Active state.
    In response to any other event (initiated by either system or
    operator), the local system releases all MASC resources associated
    with this connection and changes its state to Idle.
 OpenSent state:
    In this state MASC waits for an OPEN message from the remote node.
    When an OPEN message is received, all fields are checked for
    correctness.  If the MASC message header checking or OPEN message
    checking detects an error (see Section 8.2), or a connection

Radoslavov, et al. Experimental [Page 32] RFC 2909 The MASC Protocol September 2000

    collision (see Section 8.8) the local system sends a NOTIFICATION
    message and, if the connection is to be closed, it changes its
    state to Idle.
    If the locally configured role is SIBLING and there is no parent
    domain with Domain ID equal to the Parent Domain ID in the OPEN
    message, the local system sends a NOTIFICATION Open Message  Error
    with Error Subcode set to No Common Parent, the connection must be
    closed, and the state of the local system must be changed to Idle.
    If there are no errors in the OPEN message, MASC sends a KEEPALIVE
    message and sets a KeepAlive timer.  The Hold Timer, which was
    originally set to a large value (see above), is replaced with the
    negotiated Hold Time value (see Section 7.2).  If the negotiated
    Hold Time value is zero, then the Hold Time timer and KeepAlive
    timers are not started.  If the value of the MASC Domain ID field
    is the same as the local MASC Domain ID, and if the Role field of
    the OPEN message is set to INTERNAL_PEER, then the connection is
    an "internal" connection; otherwise, it is "external".  Finally,
    the state is changed to OpenConfirm.
    If a disconnect notification is received from the underlying
    transport protocol, the local system closes the MASC connection,
    restarts the ConnectRetry timer, while continue listening for
    connection that may be initiated by the remote MASC node, and goes
    into the Active state.
    If the Hold Timer expires, the local system sends a NOTIFICATION
    message with error code Hold Timer Expired and changes its state
    to Idle.
    In response to the Stop event (initiated by either system or
    operator) the local system sends a NOTIFICATION message with Error
    Code Cease and changes its state to Idle.
    The Start event is ignored in the OpenSent state.
    In response to any other event the local system sends a
    NOTIFICATION message with Error Code Finite State Machine Error
    and Error Subcode Open/Close MASC Connection FSM Error, and
    changes its state to Idle.
    Whenever MASC changes its state from OpenSent to Idle, it closes
    the MASC (and transport-level) connection and releases all
    resources associated with that connection.

Radoslavov, et al. Experimental [Page 33] RFC 2909 The MASC Protocol September 2000

 OpenConfirm state:
    In this state MASC waits for a KEEPALIVE or NOTIFICATION message.
    If the local system receives a KEEPALIVE message, it changes its
    state to Established.
    If the Hold Timer expires before a KEEPALIVE message is received,
    the local system sends a NOTIFICATION message with error code Hold
    Timer Expired and changes its state to Idle.
    If the local system receives a NOTIFICATION message with the O-bit
    zeroed, it changes its state to Idle.
    If the KeepAlive timer expires, the local system sends a KEEPALIVE
    message and restarts its KeepAlive timer.
    If a disconnect notification is received from the underlying
    transport protocol, the local system changes its state to Idle.
    In response to the Stop event (initiated by either system or
    operator) the local system sends a NOTIFICATION message with Error
    Code Cease and changes its state to Idle.
    The Start event is ignored in the OpenConfirm state.
    In response to any other event the local system sends a
    NOTIFICATION message with Error Code Finite State Machine Error
    and Error Subcode Unspecific, and changes its state to Idle.
    Whenever MASC changes its state from OpenConfirm to Idle, it
    closes the MASC (and transport-level) connection and releases all
    resources associated with that connection.
 Established state:
    In the Established state MASC can exchange UPDATE, NOTIFICATION,
    and KEEPALIVE messages with the remote node.
    If the local system receives an UPDATE, or KEEPALIVE message, or
    NOTIFICATION message with O-bit set, it restarts its Hold Timer,
    if the negotiated Hold Time value is non-zero.
    If the local system receives a NOTIFICATION message, with the O-
    bit zeroed, it changes its state to Idle.

Radoslavov, et al. Experimental [Page 34] RFC 2909 The MASC Protocol September 2000

    If the local system receives an UPDATE message and the UPDATE
    message error handling procedure (see Section 8.3) detects an
    error, the local system sends a NOTIFICATION message and, if the
    O-bit was zeroed, changes its state to Idle.
    If a disconnect notification is received from the underlying
    transport protocol, the local system changes its state to Idle.
    If the Hold Timer expires, the local system sends a NOTIFICATION
    message with Error Code Hold Timer Expired and changes its state
    to Idle.
    If the KeepAlive timer expires, the local system sends a KEEPALIVE
    message and restarts its KeepAlive timer.
    Each time the local system sends a KEEPALIVE or UPDATE message, it
    restarts its KeepAlive timer, unless the negotiated Hold Time
    value is zero.
    In response to the Stop event (initiated by either system or
    operator), the local system sends a NOTIFICATION message with
    Error Code Cease and changes its state to Idle.
    The Start event is ignored in the Established state.
    After entering the Established state, if the local system has
    UPDATE messages that are to be sent to the remote node, they must
    be sent immediately (see Section 11.8).
    In response to any other event, the local system sends a
    NOTIFICATION message with Error Code Finite State Machine Error
    with the O-bit zeroed and Error Subcode Unspecific, and changes
    its state to Idle.
    Whenever MASC changes its state from Established to Idle, it
    closes the MASC (and transport-level) connection, releases all
    resources associated with that connection, and deletes all state
    derived from that connection.

11. UPDATE Message Processing

 The UPDATE message are accepted only when the system is in the
 Established state.
 In the text below, a MASC domain is considered a child of itself with
 regard to the claims that are related to the address space with local
 usage purpose (i.e. to be used by the MAASs within that domain).  For

Radoslavov, et al. Experimental [Page 35] RFC 2909 The MASC Protocol September 2000

 example, a NEW_CLAIM initiated by a MASC node to obtain more space
 for local usage from a prefix managed by that domain will have field
 Role = CHILD.
 If an UPDATE is to be propagated further, it should not be sent back
 to the node that UPDATE was received from, unless there is an
 indication that the connection to that node was down and then
 restored.
 If the local system receives an UPDATE message, and there is no
 indication for error, it checks whether to accept or reject the
 message, and if it is not rejected, the UPDATE is processed based on
 its type.
 If an UPDATE message must be associated with a parent domain, then
 there must be a PREFIX_MANAGED by some parent domain for a prefix
 that covers the prefix of the particular UPDATE.

11.1. Accept/Reject an UPDATE

 The Origin Role field is first compared against the local system's
 configured Role, according to Table 1, to determine the relationship
 of the origin to the local system, where Locally-Configured Role is
 the local configuration with regard to the peer-forwarder of the
 message.  A result of "---" means that receiving such an UPDATE is
 illegal and should generate a NOTIFICATION.  Any other result is the
 value to use as the "Updated" Origin Role when propagating the UPDATE
 to others.  This is analogous to updating a metric upon receiving a
 route, based on the metric of the link.
                     Locally-Configured Role
 Origin
 Role     || INTERNAL_PEER | CHILD   | SIBLING | PARENT
 =========++===============+=========+=========+=========
 INTERNAL || INTERNAL_PEER | PARENT  | SIBLING | CHILD
 CHILD    || CHILD         | SIBLING | ---     | ---
 SIBLING  || SIBLING       | ---     | SIBLING | CHILD
 PARENT   || PARENT        | ---     | PARENT  | ---
              Table 1: Updated Origin Role Computation
 After the Origin Role is updated, the following additional processing
 needs to be applied:
 o  If the output from the Updated Origin Role Computation is SIBLING,
    but the Origin Domain ID is the same as the local MASC domain, the
    Updated Origin Role is changed to INTERNAL.  This is necessary in
    case a MASC node receives from a parent or sibling its own UPDATEs

Radoslavov, et al. Experimental [Page 36] RFC 2909 The MASC Protocol September 2000

    after reboot, or if because of internal partitioning, the
    INTERNAL_PEERs are exchanging UPDATEs via other MASC domains
    (either parent or sibling(s)).
 o  If both Locally-Configured Role, and Origin Role are equal to
    PARENT, and the Origin Domain ID is the same as the local MASC
    domain, the Updated Origin Role is changed to INTERNAL.  This is
    necessary to allow a parent to receive its own UPDATEs through its
    own children, although the parent might drop those UPDATEs if it
    has a reason not to believe its children.
 o  If both Locally-Configured Role, and Origin Role are equal to
    PARENT, and the Origin Domain ID is the same as the remote MASC
    domain, and the UPDATE type is CLAIM_DENIED, the Updated Origin
    Role is changed to INTERNAL.  This is necessary to allow a parent
    to receive the CLAIM_DENIED it has originated through the child
    whose claim was denied.  If the Origin Domain ID is not same as
    the remote MASC domain, but is same as some of the other MASC
    children domains, the Updated Origin Role still should be changed
    to INTERNAL, although the parent might drop this UPDATE if it has
    a reason not to believe a third party child.
 If the Updated Origin Role is INTERNAL, but the Origin Domain ID
 differs from the local Domain ID, a NOTIFICATION of <UPDATE Message
 Error, Illegal Origin Role> must be sent back, and the claim is
 rejected.
 If Claim Timestamp and Claim Holdtime indicate that the claim has
 expired (e.g. Timestamp + Claim Holdtime <= CurrentTime), the UPDATE
 is silently dropped and no further actions are taken.
 Each new arrival UPDATE is compared with all claims in the local
 cache.  The following fields are compared, and if all of them are the
 same, the message is silently rejected and no further actions are
 taken:
 o  Role, D-bit, Type
 o  AddrFam
 o  Claim Timestamp
 o  Claim Lifetime
 o  Claim Holdtime
 o  Origin Domain Identifier

Radoslavov, et al. Experimental [Page 37] RFC 2909 The MASC Protocol September 2000

 o  Origin Node Identifier
 o  Address
 o  Mask
 Further processing of an UPDATE is based on its type and the Updated
 Origin Role.

11.2. PREFIX_IN_USE Message Processing

11.2.1. PREFIX_IN_USE by PARENT

 The claim is rejected, and a NOTIFICATION of <UPDATE Message Error,
 Illegal Origin Role> should be sent back.

11.2.2. PREFIX_IN_USE by SIBLING

 If the claim cannot be associated with any parent's PREFIX_MANAGED,
 the claim is dropped, a NOTIFICATION of <UPDATE Message Error, No
 Appropriate Parent Prefix> must be sent back and no further actions
 should be taken.
 If the claim collides with some of the local domain's pending claims,
 the local claims must not be considered further, and the Claim-Timer
 of each of them must be canceled. If the received PREFIX_IN_USE claim
 clashes with and wins over some of the local domain's allocated
 prefixes, resolve the clash according to Section 12.4. Finally, the
 claim must be propagated further to all INTERNAL_PEERs, all MASC
 nodes from the corresponding parent MASC domain and all known
 siblings with the same parent domain.

11.2.3. PREFIX_IN_USE by CHILD

 If the claim's prefix is not a subrange of any of the local domain's
 PREFIX_MANAGED, the claim is dropped, a NOTIFICATION of <UPDATE
 Message Error, No Appropriate Parent Prefix> must be sent back and no
 further actions should be taken.  Otherwise, the claim must be
 propagated further to all INTERNAL_PEERs and all MASC children
 domains.

11.2.4. PREFIX_IN_USE by INTERNAL_PEER

 If the MASC node decides that the local domain does not need that
 prefix any more, it may be withdrawn, otherwise, the claim is
 processed as PREFIX_MANAGED.

Radoslavov, et al. Experimental [Page 38] RFC 2909 The MASC Protocol September 2000

11.3. CLAIM_DENIED Message Processing

11.3.1. CLAIM_DENIED by CHILD or SIBLING

 The message is rejected, and a NOTIFICATION of <UPDATE Message Error,
 Illegal Origin Role> should be sent back.

11.3.2. CLAIM_DENIED by INTERNAL_PEER

 Propagate to all INTERNAL_PEERs and all MASC children nodes.

11.3.3. CLAIM_DENIED by PARENT

 If the Origin Domain ID is not same as the local domain ID, and the
 UPDATE cannot be associated with any parent domain, the message is
 dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate
 Parent Prefix> must be sent back and no further actions should be
 taken.
 If the Origin Domain ID is not same as the local domain ID, and the
 UPDATE can be associated with a parent domain, the message is
 propagated to all nodes from that parent domain, all INTERNAL_PEERs,
 and all known SIBLINGs with regard to that parent.
 If the Origin Domain ID is same as the local domain ID, and there is
 no corresponding pending claim originated by the local MASC domain
 (i.e. a NEW_CLAIM or CLAIM_TO_EXPAND with same AddrFam, Origin Domain
 ID, Claim Timestamp, Address and Mask), a NOTIFICATION of <UPDATE
 Message Error, No Appropriate Internal Prefix> must be sent back and
 no further actions should be taken. Otherwise, the matching NEW_CLAIM
 or CLAIM_TO_EXPAND's Claim-Timer must be canceled and the claim must
 not be considered further. Finally, the received CLAIM_DENIED must be
 propagated to all INTERNAL_PEERs, all MASC nodes from the
 corresponding parent MASC domain, and all known SIBLINGs with regard
 to that parent.

11.4. CLAIM_TO_EXPAND Message Processing

11.4.1. CLAIM_TO_EXPAND by PARENT

 The claim is rejected, and a NOTIFICATION of <UPDATE Message Error,
 Illegal Origin Role> should be sent back.

Radoslavov, et al. Experimental [Page 39] RFC 2909 The MASC Protocol September 2000

11.4.2. CLAIM_TO_EXPAND by SIBLING

 If the claim cannot be associated with any parent's PREFIX_MANAGED,
 the claim is dropped, a NOTIFICATION of <UPDATE Message Error, No
 Appropriate Parent Prefix> must be sent back and no further actions
 should be taken.
 If there is no overlapping PREFIX_IN_USE by the same MASC domain, the
 claim is dropped, a NOTIFICATION of <UPDATE Message Error, No
 Appropriate Sibling Prefix> must be sent back and no further actions
 should be taken.
 If the claim collides with and wins over some of the local domain's
 pending claims, the loser claims must not be considered further, and
 the Claim-Timer of the each of them must be canceled.  Also, the
 received claim must be propagated further to all INTERNAL_PEERs, all
 MASC nodes from the corresponding parent MASC domain and all known
 siblings with the same parent domain.

11.4.3. CLAIM_TO_EXPAND by CHILD

 If the claim cannot be associated with any of the local domain's
 PREFIX_MANAGED, the claim is dropped, a NOTIFICATION of <UPDATE
 Message Error, No Appropriate Parent Prefix> must be sent back and no
 further actions should be taken.
 If there is no overlapping PREFIX_IN_USE by the same MASC domain, the
 claim is dropped, a NOTIFICATION of <UPDATE Message Error, No
 Appropriate Child Prefix> must be sent back and no further actions
 should be taken.
 Otherwise, the claim has to be propagated to all INTERNAL_PEERs.  If
 the lifetime of the claim is longer than the lifetime of the
 corresponding prefix managed by the local domain, or if there is an
 administratively configured reason to prevent the child from
 succeeding allocating the claimed prefix, a CLAIM_DENIED must be sent
 to all MASC children nodes that have same Domain ID as Origin Domain
 ID in the received message.  The CLAIM_DENIED must be the same as the
 received claim, except Rol=INTERNAL, and Claim Lifetime should be set
 to the maximum allowed lifetime.  Otherwise, propagate the claim to
 all children as well.

11.4.4. CLAIM_TO_EXPAND by INTERNAL_PEER

 If the claim cannot be associated with any parent's PREFIX_MANAGED,
 the claim is dropped, a NOTIFICATION of <UPDATE Message Error, No
 Appropriate Parent Prefix> must be sent back and no further action
 should be taken.

Radoslavov, et al. Experimental [Page 40] RFC 2909 The MASC Protocol September 2000

 If there is no overlapping PREFIX_IN_USE by the local MASC domain,
 the claim is dropped, a NOTIFICATION of <UPDATE Message Error, No
 Appropriate Internal Prefix> must be sent back and no further actions
 should be taken.
 If the MASC node decides that the local domain does not need that
 pending claim any more, it MAY be withdrawn. Otherwise, the claim
 must be propagated to all INTERNAL_PEERs and all MASC nodes from the
 corresponding parent MASC domain.

11.5. NEW_CLAIM Message Processing

 If the claim's Address field is 0 (i.e. a hint by a child to a parent
 to obtain more space), the claim should be propagated only among the
 nodes that belong to the child Origin Domain and the parent domain.
 Otherwise, process like CLAIM_TO_EXPAND, except that no check for
 overlapping PREFIX_IN_USE needs to be performed.

11.6. PREFIX_MANAGED Message Processing.

11.6.1. PREFIX_MANAGED by PARENT

 If the Origin Domain ID matches one of the parents' domain ID's, the
 prefix is recorded, and can be used by the address allocation
 algorithm for allocating subranges.  Also, the message is propagated
 to all MASC nodes of the corresponding parent domain, all
 INTERNAL_PEERs, and SIBLINGs with same parent.

11.6.2. PREFIX_MANAGED by CHILD or SIBLING

 The message is rejected, and a NOTIFICATION of <UPDATE Message Error,
 Illegal Origin Role> should be sent back.

11.6.3. PREFIX_MANAGED by INTERNAL_PEER

 The prefix is recorded as allocated to the local domain, propagated
 to all INTERNAL_PEERs, and can be used for (all items apply):
 a) address ranges/prefixes advertisements to all MASC children and
    local domain's MAASs;
 b) injection into G-RIB;
 c) further expansion by the address allocation algorithm (see
    Appendix A);

Radoslavov, et al. Experimental [Page 41] RFC 2909 The MASC Protocol September 2000

11.7. WITHDRAW Message Processing

11.7.1. WITHDRAW by CHILD

 If the WITHDRAW cannot be associated with any of the child domain's
 PREFIX_IN_USE (i.e. no child's PREFIX_IN_USE covers WITHDRAW's
 range), or if the WITHDRAW does not match any of the child domain's
 NEW_CLAIM or CLAIM_TO_EXPAND (i.e. there is no child's claim with
 same Address, Mask and Timestamp), the message is dropped, a
 NOTIFICATION of <UPDATE Message Error, No Appropriate Child Prefix>
 must be sent back and no further actions should be taken. Otherwise,
 propagate to all INTERNAL_PEERs and children.

11.7.2. WITHDRAW by SIBLING

 If the WITHDRAW cannot be associated with any of the siblings'
 PREFIX_IN_USE (i.e. no sibling's PREFIX_IN_USE covers WITHDRAW's
 range), or if the WITHDRAW does not match any of the sibling domain's
 NEW_CLAIM or CLAIM_TO_EXPAND (i.e. there is no sibling's claim with
 same Address, Mask and Timestamp), the message is dropped, a
 NOTIFICATION of <UPDATE Message Error, No Appropriate Sibling Prefix>
 must be sent back and no further actions should be taken. Otherwise,
 propagate to all INTERNAL_PEERs, all MASC nodes from the same parent
 MASC domain and all known siblings with the same parent domain.

11.7.3. WITHDRAW by INTERNAL

 If the WITHDRAW cannot be associated with any of the local domain's
 PREFIX_IN_USE or PREFIX_MANAGED (i.e. no local domain's prefix covers
 WITHDRAW's range), or if the WITHDRAW does not match any of the local
 domain's NEW_CLAIM or CLAIM_TO_EXPAND (i.e. there is no local
 domain's claim with same Address, Mask and Timestamp) the message is
 dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate
 Internal Prefix> must be sent back and no further actions should be
 taken.
 Otherwise, propagate to all INTERNAL_PEERs, all MASC nodes of the
 corresponding parent domain of that prefix, all known siblings with
 that parent domain, and all children.  If the WITHDRAW can be
 associated with some of local domain's PREFIX_IN_USE or
 PREFIX_MANAGED, stop advertising the WITHDRAW range to the MAASs and
 withdraw that range from the G-RIB database.  In the special case
 when there is an indication that the WITHDRAW has been originated by
 the local domain because of a clash, and the range specified in
 WITHDRAW is a subrange of the local PREFIX_MANAGED, and the Claim
 Holdtime of WITHDRAW is shorter than the Claim Holdtime of

Radoslavov, et al. Experimental [Page 42] RFC 2909 The MASC Protocol September 2000

 PREFIX_MANAGED, the WITHDRAW's range should not be withdrawn from the
 G-RIB.  If the WITHDRAW matches a local domain's NEW_CLAIM or
 CLAIM_TO_EXPAND, cancel the matching claim's Claim-Timer.

11.7.4. WITHDRAW by PARENT

 If the WITHDRAW cannot be associated with any parent domain, a
 NOTIFICATION of <UPDATE Message Error, No Appropriate Parent Prefix>
 must be sent back and no further actions should be taken.
 Otherwise, propagate to all INTERNAL_PEERs and all known siblings
 with the same parent domain. Also, originate a WITHDRAW message for
 each intersection of a locally owned PREFIX_MANAGED/PREFIX_IN_USE and
 the received WITHDRAW.  The locally originated WITHDRAW message's
 Claim Holdtime should be at least equal to the Claim Holdtime in the
 WITHDRAW message received from the parent; the Origin Node ID should
 be the same as the particular PREFIX_MANAGED/PREFIX_IN_USE.

11.8. UPDATE Message Ordering

 To simplify consistency and sanity check implementations, if there is
 more than one UPDATE message that needs to be send to a peer (for
 example, after a connection (re)establishment), some of the UPDATEs
 must be sent before others.
 The rules that always apply are:
 o  PREFIX_IN_USE must always be sent BEFORE CLAIM_TO_EXPAND,
    NEW_CLAIM, and WITHDRAW by the same MASC domain
 o  WITHDRAW must always be sent AFTER PREFIX_IN_USE, CLAIM_TO_EXPAND,
    NEW_CLAIM, and PREFIX_MANAGED by the same MASC domain
 Any further ordering is defined below by the roles of the sender and
 the receiver.

11.8.1. Parent to Child

 Messages are sent in the following order:
 1) Parent's PREFIX_MANAGED and WITHDRAWs.
 2) All children's PREFIX_IN_USE, CLAIM_TO_EXPAND, and NEW_CLAIMs.
    CLAIMs from third party children that are hints for more space
    (i.e. address = 0) should not be propagated; if propagated, the
    child should drop them.

Radoslavov, et al. Experimental [Page 43] RFC 2909 The MASC Protocol September 2000

 3) Parent initiated CLAIM_DENIED and children initiated WITHDRAWs.
    CLAIM_DENIED regarding third party children's claims/hints with
    address = 0 should not be propagated; if propagated, the child
    should drop them.

11.8.2. Child to Parent

 Messages are sent in the following order:
 1) Parent's PREFIX_MANAGED and WITHDRAWs.
 2) All PREFIX_IN_USE, CLAIM_TO_EXPAND, and NEW_CLAIMSs from that
    parent's space, initiated by that child and all its siblings.
 3) Parent's initiated CLAIM_DENIED, and all WITHDRAWSs that can be
    associated with that parent's space and are initiated by the local
    domain or all known siblings with that parent.

11.8.3. Sibling to Sibling

 Messages are sent in the following order:
 1) All common parent's PREFIX_MANAGED and WITHDRAWs.
 2) PREFIX_IN_USE, CLAIM_TO_EXPAND, and NEW_CLAIMs, initiated by
    siblings.
 3) CLAIM_DENIEDs initiated by common parent, and WITHDRAWs initiated
    by local domain and all known siblings with that parent.

11.8.4. Internal to Internal

 Messages are sent in the following order:
 1) All parents' PREFIX_MANAGED and WITHDRAWs.
 2) Local domain's and all siblings' PREFIX_IN_USE, CLAIM_TO_EXPAND,
    and NEW_CLAIMs.  CLAIMs from siblings that are hints for more
    space (i.e. address = 0) should not be propagated; if propagated,
    the recipient should drop them.
 3) CLAIM_DENIEDs initiated by all parents, and WITHDRAWs initiated by
    local domain and all known siblings.
 4) All children's PREFIX_IN_USE, CLAIM_TO_EXPAND, and NEW_CLAIMs.
 5) All local domain initiated CLAIM_DENIED regarding children claims
    and all children initiated WITHDRAWs.

Radoslavov, et al. Experimental [Page 44] RFC 2909 The MASC Protocol September 2000

12. Operational Considerations

12.1. Bootup Operations

 To learn about its parent domains' IDs and prefixes, a MASC node
 SHOULD try to establish connections to its PARENT nodes before
 initiating a connection to a SIBLING node.  To avoid learning about
 its own PREFIX_MANAGED from its children or siblings, a MASC node
 SHOULD try to establish connections to its PARENT nodes and
 INTERNAL_PEER nodes before initiating a connection to a CHILD or
 SIBLING node.

12.2. Leaf and Non-leaf MASC Domain Operation

 A non-leaf MASC domain (i.e. a domain that has children domains)
 should advertise its PREFIX_MANAGED addresses to its children, and
 should claim from that space the sub-ranges that would be advertised
 to the internal MAASs (the claim wait time SHOULD be equal to
 [WAITING_PERIOD]).  A MASC node that belongs to a non-leaf MASC
 domain should perform dual functions by being a child of itself with
 regard to the claiming and management of the sub-ranges for local
 usage.  A leaf MASC domain should advertise all PREFIX_MANAGED
 addresses to its MAASs without explicitly claiming them for internal
 usage.  A MASC node can assume that it belongs to a leaf domain if it
 simply does not have any UPDATEs by children domains.  If an UPDATE
 by a child is received, the domain MUST switch from "leaf" to "non-
 leaf" mode, and if it needs more addresses for internal usage, it
 MUST claim them from that domain's PREFIX_MANAGED.  After the last
 UPDATE originated by a child expires, the domain can switch back to
 "leaf" mode.

12.3. Clock Skew Workaround

 Each UPDATE has "Claim Timestamp" field that is set to the absolute
 time of the MASC node that originated that UPDATE. The timestamp is
 used for two purposes: to resolve collisions, and to define how long
 an UPDATE should be kept in the local cache of other MASC nodes. A
 skew in the clock could result in unfair collision decision such that
 the claims originated by nodes that have their clock behind the real
 time will always win; however, because collisions are presumably
 rare, this will not be an issue.  Skew in the clock however might
 result in expiring an UPDATE earlier than it really should be
 expired, and a node might assume too early that the expired
 UPDATE/prefix is free for allocation. To compensate for the clock
 skew, an UPDATE message should be kept longer than the amount of time
 specified in the Claim Holdtime. For example, keeping UPDATEs for an
 additional 24 hours will compensate for clock skew for up to 24
 hours.

Radoslavov, et al. Experimental [Page 45] RFC 2909 The MASC Protocol September 2000

12.4. Clash Resolving Mechanism

 If a MASC node receives a PREFIX_IN_USE claim originated by a sibling
 and the claim overlaps with some of the local prefixes, the clash
 must be resolved.  Two MASC domains should not manage overlapping
 address ranges, unless the domains have an ancestor-descendant (e.g.
 parent-child) relationship in the MASC hierarchy.  Also, two MASC
 domains should not have locally-allocated overlapping address ranges.
 The clashed address ranges should not be advertised to the MAASs and
 allocated to multicast applications/sessions.  If a clashed address
 has being allocated to an application, the application should be
 informed to stop using that address and switch to a new one.
 The G-RIB database must be consistent, such that it does not have
 ambiguous entries.  "Ambiguous G-RIB entries" are those entries that
 might cause the multicast routing protocol to loop or lose
 connectivity.  In MASC the WITHDRAW message is used to solve this
 problem.  When a clashing PREFIX_IN_USE is received, it is compared
 (using the function describe in Section 5.1.1) against all prefixes
 allocated to the local domain.  If the local PREFIX_IN_USE is the
 winner, no further actions are taken.  If the local PREFIX_IN_USE is
 the loser, the clashing address range must be withdrawn by initiating
 a WITHDRAW message. The message must have Role = INTERNAL, Origin
 Node ID and Origin Domain ID must be the same as the corresponding
 local PREFIX_IN_USE message, while Claim Timestamp, Claim Lifetime,
 Claim Holdtime, Address and Mask must be the same as the received
 winning PREFIX_IN_USE.  The initiated WITHDRAW message must be
 processed as described in Section 11.7.
 If a cached WITHDRAW times out and the local MASC domain owns an
 overlapping PREFIX_MANAGED or PREFIX_IN_USE, the overlapping prefix
 ranges can be injected back into the G-RIB database.  Similarly, the
 address ranges that were not advertised to the local domain's MAASs
 due to the WITHDRAW, can now be advertised again.
 In addition to the automatic resolving of clashes, a MASC
 implementation should support manual resolving of clashes.  For
 example, after a clash is detected, the network administrator should
 be informed that a clash has occurred.  The specific manual
 mechanisms are outside the scope of this protocol.
 A MASC node must be configured to operate using either manual or
 automatic clash resolution mechanisms.

Radoslavov, et al. Experimental [Page 46] RFC 2909 The MASC Protocol September 2000

12.5. Changing Network Providers

 If a MASC domain changes a network provider, such that the old
 provider cannot be used to provide connectivity, any traffic for
 sessions that are in progress and use that MASC domain as the root of
 multicast distribution trees will not be able to reach that domain.
 If the new network provider is willing to carry the traffic for the
 old sessions rooted at the customer domain, then it must propagate
 the customer's old prefixes through the G-RIB.  However, at least one
 MASC node in the customer domain must maintain a TCP connection to
 one of the old network provider's MASC nodes.  Thus, it can continue
 to "defend" the customer's prefixes, and should continue until the
 old prefixes' lifetimes expire.
 If the new network provider is not willing to propagate the old
 prefixes, then the customer should remove its prefixes from the G-
 RIB.  If BGMP is in use, the old network provider's domain will
 automatically become the Root Domain for the customer's old groups
 due to the lack of a more specific group route.  MASC nodes in the
 customer domain MAY still connect with the old provider's MASC nodes
 to defend their allocation.

12.6. Debugging

12.6.1. Prefix-to-Domain Lookup

 Use mtrace [MTRACE] to find the BGMP/MASC root domain for a group
 address chosen from that prefix.

12.6.2. Domain-to-Prefix Lookup

 We can find the address space allocated to a particular MASC domain
 by directly querying one of the MASC servers within that domain, by
 observing the state in parents, siblings, or children MASC domains,
 or by observing the G-RIB information originated by that domain.
 From those three methods, the first method can provide the most
 detailed information. Finding the address of one of the MASC nodes
 within a particular domain is outside the scope of MASC.

13. MASC Storage

 In general, MASC will be run by a border routers, which, in general
 do not have stable storage.  In this case, MASC must use the Layer 2
 protocol/mechanism (e.g., ([AAP]) as described in [MALLOC] to store
 the important information (the prefixes allocated by the local
 domain) in the domain's MAASs who should have stable storage.  If the

Radoslavov, et al. Experimental [Page 47] RFC 2909 The MASC Protocol September 2000

 MASC speaker has local storage, it should use it instead of the Layer
 2 protocol/mechanism.  Claims that are in progress do not have to be
 saved by using the Layer 2 protocol/mechanism.

14. Security Considerations

 IPsec [IPSEC] can be used to address security concerns between two
 MASC peering nodes.  However, because of the store-and-forward nature
 of the UPDATE messages, it is possible that if a non-trustworthy MASC
 node can connect to some point of the MASC topology, then this node
 can undetectably inject malicious UPDATEs that may disturb the normal
 operation of other MASC nodes.  To address this problem, each MASC
 node should allow peering only with trustworthy nodes.
 After a reboot, a MASC node/domain can restore its state from its
 neighbors (internal peers, parents, siblings, children). Typically,
 the state received from a parent or internal peer will be
 trustworthy, but a node may choose to drop its own UPDATEs that were
 received through a sibling or a child.
 A misbehaving node may attempt a Denial of Service attack by sending
 a large number of colliding messages that would prevent any of its
 siblings from allocating more addresses.  A single mis-behaving node
 can easily be identified by all of its siblings, and all of its
 UPDATEs can be ignored.  A Denial of Service attack that uses
 multiple origin addresses can be prevented if a third-party UPDATE
 (e.g. by a non-directly connected sibling) is accepted only if it is
 sent via the common parent domain, and the MASC nodes in the parent
 domain accept children UPDATEs only if they come via an internal
 peer, or come directly from a child node that is same as the Origin
 Node ID.

15. IANA Considerations

 This document defines several number spaces (MASC message types, MASC
 OPEN message optional parameters types, MASC UPDATE message attribute
 types, MASC UPDATE message optional parameters types, and MASC
 NOTIFICATION message error codes and subcodes).  For all of these
 number spaces, certain values are defined in this specification.  New
 values may only be defined by IETF Consensus, as described in [IANA-
 CONSIDERATIONS].  Basically, this means that they are defined by RFCs
 approved by the IESG.

16. Acknowledgments

 The authors would like to thank the participants of the IETF for
 their assistance with this protocol.

Radoslavov, et al. Experimental [Page 48] RFC 2909 The MASC Protocol September 2000

17. APPENDIX A: Sample Algorithms

 DISCLAIMER: This section describes some preliminary suggestions by
 various people for algorithms which could be used with MASC.

17.1. Claim Size and Prefix Selection Algorithm

 This section covers the algorithms used by a MASC node (on behalf of
 a MASC domain) to satisfy the demand for multicast addresses.  The
 allocated addresses should be aggregatable, the address utilization
 should be reasonably high, and the allocation latency to the MAASs
 should be shorter than [WAITING_PERIOD] whenever possible.

17.1.1. Prefix Expansion

 For ease of implementation and troubleshooting, MASC should use
 contiguous masks to specify the address ranges, i.e. prefixes.
 (Research indicates that sufficiently good results can be achieved
 using contiguous masks only.)  The chosen prefixes should be as
 expandable as possible.  The method used to choose the children sub-
 prefixes from the parent's prefix is the so called Reverse Bit
 Ordering (idea by Dave Thaler; inspired by Kampai [KAMPAI]).  For
 example, if the parent's prefix width is four bits, the addresses of
 the sub-prefixes are chosen in the following order:
 Parent:       xxxx
 Child A:      0000
 Child B:      1000
 Child C:      0100
 Child D:      1100
 If some of the children need to expand their sub-prefix, they try to
 double the corresponding sub-prefix starting from the right:
 Child A:      000x
 Child A:      00xx
 Child D:      110x
 Child D:      11xx
 and so on.
 However, because the address ordering is very strict, to reduce the
 probability for collision, when a new sub-prefix has to be chosen,
 the choice should be random among all candidates with the same
 potential for expandability.  For example, if the free sub-prefixes
 are 01xx, 10xx, 110x, then the new prefix to claim should be chosen
 with probability of 50% for 01xx and 50% for 10xx for example.

Radoslavov, et al. Experimental [Page 49] RFC 2909 The MASC Protocol September 2000

17.1.2. Reducing Allocation Latency

 To reduce the allocation latency, a MASC node uses pre-allocation.
 It constantly monitors the demand for addresses from its children (or
 MAASs), and predicts what would be the address usage after
 [WAITING_PERIOD].  Only if the available addresses will be used up
 within [WAITING_PERIOD], a MASC node claims more addresses in
 advance.

17.1.3. Address Space Utilization

 Because every prefix size is a power of two, if a node tries to
 allocate just a single prefix, the utilization at that node (i.e. at
 that node's domain) can be as low as 50%.  To improve the
 utilization, a MASC node can have more than one prefix allocated at a
 time (typically, each of them with different size).  By using a pre-
 allocation and allocating several prefixes of different size (see
 below), a MASC node should try to keep its address utilization in the
 range 70-90%.

17.1.4. Prefix Selection After Increase of Demand

 To additionally reduce the allocation latency by reducing the
 probability for collision, and to improve the aggregability of the
 allocated addresses, a MASC node carefully chooses the prefixes to
 claim. The first prefix is chosen at random among all reasonably
 expandable candidates.  If a node chooses to allocate another,
 smaller prefix, then, instead of doubling the size of the first one
 which might reduce significantly the address utilization, a second
 "neighbor" prefix is chosen.  For example, if prefix 224.0/16 was
 already allocated, and the MASC domain needs 256 more addresses, the
 second prefix to claim will be 224.1.0/24. If the domain needs more
 addresses, the second prefix will eventually grow to 224.1/16, and
 then both prefixes can be automatically aggregated into 224.0/15.
 Only if 224.0.1/24 could not be allocated, a MASC node will choose
 another prefix (eventually random among the unused prefixes).
 If the number of allocated prefixes increases above some threshold,
 and none of them can be extended when more addresses are needed,
 then, to reduce the amount of state, a MASC node should claim a new
 larger prefix and should stop re-claiming the older non-expandable
 prefixes.  Research results show that up to three prefixes per MASC
 domain is a reasonable threshold, such that the address utilization
 can be in the range 70-90%, and at the same time the prefix flux will
 be reasonably low.

Radoslavov, et al. Experimental [Page 50] RFC 2909 The MASC Protocol September 2000

17.1.5. Prefix Selection After Decrease of Demand

 If the demand for addresses decreases, such that its address space is
 under-utilized, a MASC node implicitly returns the unused prefixes
 after their lifetimes expire, or re-claims some smaller sub-prefixes.
 For example, if prefix 224.0/15 is 50% used by the MAASs and/or
 children MASC domains, and the overall utilization is such that
 approximately 2^16 (64K) addresses should be returned, a MASC node
 should stop reclaiming 224.0/15 and should start reclaiming either
 224.0/16 or 224.1/16 (whichever sub-prefix utilization is higher).

17.1.6. Lifetime Extension Algorithm

 If the demand for addresses did not decrease, then a MASC node re-
 claims the prefixes it has allocated before their lifetime expires.
 Each prefix (or sub-prefix if the demand has decreased) should be
 re-claimed every 48 hours.

18. APPENDIX B: Strawman Deployment

 At the moment of writing, 225.0.0.0-225.255.255.255 is temporarily
 allocated to MALLOC.  Presumably this block of addresses will be used
 for experimental deployment and testing.
 If MASC were widely deployed on the Internet, we might expect numbers
 similar to the following:
 o  Initially will have approximately 128 Top-Level Domains
 o  Assume initially approximately 8192 level-2 MASC domains; on
    average, a TLD will have approximately 64 children domains.
 o  MASC managed global addresses:
    The following (large) ranges are not allocated yet (2^N represents
    the size of the contiguous mask prefixes):
     225.0.0.0 - 231.255.255.255 = 2^26 + 2^25 + 2^24
     234.0.0.0 - 238.255.255.255 = 2^25 + 2^25 + 2^24
     ---------------------------
     Total:   12*2^24 addresses
    Initially, the range 228.0.0.0 - 231.255.255.255 (4*2^24 = 2^26 =
    64M) could be used by MASC as the global addresses pool. The rest
    (8*2^24) should be reserved.  Part of it could be added later to
    MASC, or can be used to enlarge the pool of administratively
    scoped addresses (currently 239.X.X.X), or the pool for static
    allocation (233.X.X.X).

Radoslavov, et al. Experimental [Page 51] RFC 2909 The MASC Protocol September 2000

 o  If the multicast addresses are evenly distributed, each TLD would
    have a maximum of 2^19 (512K) addresses, while each level-2 MASC
    domain would have 8192 addresses.
 o  Initial claim size: 256 addresses/MASC domain
 o  Could use soft and hard thresholds to specify the maximum amount
    of claimed+allocated addresses per domain.  For example, trigger a
    warning message if claimed+allocated addresses by a domain is >=
    1.0*average_assumed_per_domain (a strawman default soft
    threshold):
  • if a TLD claim+allocation >= 512K
  • if a second level MASC domain claim+allocation >= 8K
    The hard threshold (for example, 2.0*average_assumed_per_domain)
    can be enforced by sending an explicit DENIED message.
    The TLDs thresholds (with regard to the claims by the second level
    MASC domains) is a private matter and is a part of the particular
    TLD policy: the thresholds could be per customer, and the warnings
    to the administrators could be a signal that it is time to change
    the policy.
 o  Initial claim lifetime is of the order of 30 days.  Prefix
    lifetime is periodically (every 48 hours) reclaimed/extended,
    unless the prefix is under-utilized (see APPENDIX A).  Because the
    allocation is demand-driven, the allocated prefix lifetime will be
    automatically extended if the MAASs need longer prefix lifetime
    (e.g. 3-6 months).
 o  A level-2 MASC domain could have children (i.e. level-3) MASC
    domains.
 o  If a level-2 or level-3 MASC domain uses less than 128 addresses,
    a Layer 2 protocol/mechanism (e.g. AAP) should be run among that
    domain and its parent MASC domain.

19. Authors' Addresses

 Pavlin Radoslavov
 Computer Science Department
 University of Southern California/ISI
 Los Angeles, CA 90089
 USA
 EMail: pavlin@catarina.usc.edu

Radoslavov, et al. Experimental [Page 52] RFC 2909 The MASC Protocol September 2000

 Deborah Estrin
 Computer Science Department
 University of Southern California/ISI
 Los Angeles, CA 90089
 USA
 EMail: estrin@isi.edu
 Ramesh Govindan
 University of Southern California/ISI
 4676 Admiralty Way
 Marina Del Rey, CA 90292
 USA
 EMail: govindan@isi.edu
 Mark Handley
 AT&T Center for Internet Research at ISCI (ACIRI)
 1947 Center St., Suite 600
 Berkeley, CA 94704
 USA
 EMail: mjh@aciri.org
 Satish Kumar
 Computer Science Department
 University of Southern California/ISI
 Los Angeles, CA 90089
 USA
 EMail: kkumar@usc.edu
 David Thaler
 Microsoft
 One Microsoft Way
 Redmond, WA 98052
 USA
 EMail: dthaler@microsoft.com

Radoslavov, et al. Experimental [Page 53] RFC 2909 The MASC Protocol September 2000

20. References

 [AAP]                 Handley, M. and S. Hanna, "Multicast Address
                       Allocation Protocol (AAP)", Work in Progress.
 [API]                 Finlayson, R., "An Abstract API for Multicast
                       Address Allocation", RFC 2771, February 2000.
 [BGMP]                Thaler, D., Estrin, D. and D. Meyer, "Border
                       Gateway Multicast Protocol (BGMP): Protocol
                       Specification", Work in Progress.
 [BGP]                 Rekhter, Y. and T. Li, "A Border Gateway
                       Protocol 4 (BGP-4)", RFC 1771, March 1995.
 [CIDR]                Rekhter, Y. and C. Topolcic, "Exchanging
                       Routing Information Across Provider Boundaries
                       in the CIDR Environment", RFC 1520, September
                       1993.
 [IANA]                Reynolds, J. and J. Postel, "Assigned Numbers",
                       STD 2, RFC 1700, October 1994.
 [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for
                       Writing an IANA Considerations Section in
                       RFCs", BCP 26, RFC 2434, October 1998.
 [IPSEC]               Kent, S. and R. Atkinson, "Security
                       Architecture for the Internet Protocol", RFC
                       2401, November 1998.
 [KAMPAI]              Tsuchiya, P., "Efficient and Flexible
                       Hierarchical Address Assignment", INET92, June
                       1992, pp. 441--450.
 [MADCAP]              Hanna, S., Patel, B. and M. Shah, "Multicast
                       Address Dynamic Client Allocation Protocol
                       (MADCAP)", RFC 2730, December 1999.
 [MALLOC]              Thaler, D., Handley, M. and D. Estrin, "The
                       Internet Multicast Address Allocation
                       Architecture", RFC 2908, September 2000.
 [MBGP]                Bates, T., Chandra, R., Katz, D. and Y.
                       Rekhter, "Multiprotocol Extensions for BGP-4",
                       RFC 2283, September 1997.

Radoslavov, et al. Experimental [Page 54] RFC 2909 The MASC Protocol September 2000

 [MTRACE]              Fenner, W., and S. Casner, "A `traceroute'
                       facility for IP Multicast", Work in Progress.
 [MZAP]                Handley, M, Thaler, D. and R. Kermode
                       "Multicast-Scope Zone Announcement Protocol
                       (MZAP)", RFC 2776, February 2000.
 [RFC1112]             Deering, S., "Host Extensions for IP
                       Multicasting", STD 5, RFC 1112, August 1989.
 [RFC2119]             Bradner, S., "Key words for use in RFCs to
                       Indicate Requirement Levels", BCP 14, RFC 2119,
                       March 1997.
 [RFC2373]             Hinden, R. and S. Deering, "IP Version 6
                       Addressing Architecture", RFC 2373, July 1998.
 [RFC2460]             Deering, S. and R. Hinden, "Internet Protocol,
                       Version 6 (IPv6) Specification", RFC 2460,
                       December 1998.
 [SCOPE]               Meyer, D., "Administratively Scoped IP
                       Multicast", RFC 2365, July 1998.

Radoslavov, et al. Experimental [Page 55] RFC 2909 The MASC Protocol September 2000

21. Full Copyright Statement

 Copyright (C) The Internet Society (2000).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Radoslavov, et al. Experimental [Page 56]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2909.txt · Last modified: 2000/09/13 20:53 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki