tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 2909

Historic
Pages: 56
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: MALLOC

The Multicast Address-Set Claim (MASC) Protocol

Part 1 of 3, p. 1 to 24
None       Next RFC Part

 


Top       ToC       Page 1 
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.

Top       Page 2 
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

Top      ToC       Page 3 
   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

Top      ToC       Page 4 
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.

Top      ToC       Page 5 
   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,

Top      ToC       Page 6 
   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

Top      ToC       Page 7 
   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.

Top      ToC       Page 8 
   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.

Top      ToC       Page 9 
   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.

Top      ToC       Page 10 
                                 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:

Top      ToC       Page 11 
   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).

Top      ToC       Page 12 
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.

Top      ToC       Page 13 
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).

Top      ToC       Page 14 
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.

Top      ToC       Page 15 
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)

Top      ToC       Page 16 
   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

Top      ToC       Page 17 
      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.

Top      ToC       Page 18 
   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.

Top      ToC       Page 19 
    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.

Top      ToC       Page 20 
   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.

Top      ToC       Page 21 
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:

Top      ToC       Page 22 
         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)

Top      ToC       Page 23 
               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.

Top      ToC       Page 24 
      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).



(page 24 continued on part 2)

Next RFC Part