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.

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.

   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.

      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.

   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

   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).

   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.

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.

      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

      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.

   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.

      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

   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

      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

   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.

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.

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.

   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);

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

   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.

   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.