rfc2909.txt

中、英文RFC文档大全打包下载完全版 .

                       23 - Illegal Origin Role Error         (CC)
                       24 - No Appropriate Parent Prefix      (CC)
                       25 - No Appropriate Child Prefix       (CC)
                       26 - No Appropriate Internal Prefix    (CC)
                       27 - No Appropriate Sibling Prefix     (CC)
                       28 - Claim Holdtime Too Short          (CC)
                       29 - Claim Holdtime Too Long           (CC)

         Hold Timer Expired subcodes (the O-bit is always zero):

                        0 - Unspecific                        (MC)

               Finite State Machine Error subcodes:

                        0 - Unspecific                        (MC)
                        1 - Open/Close MASC Connection FSM Error (MC)
                        2 - Unexpected Message Type FSM Error (MC)

               Cease subcodes (the O-bit is always zero):

                        0 - Unspecific                        (MC)

               NOTIFICATION subcodes (the O-bit is always zero):

                        0 - Unspecific                        (MC)

   Data:
      This variable-length field is used to diagnose the reason for the
      NOTIFICATION.  The contents of the Data field depend upon the
      Error Code and Error Subcode.  See Section 8 for more details.



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


      Note that the length of the Data field can be determined from the
      message Length field by the formula:

         Message Length = 6 + Data Length

      The minimum length of the NOTIFICATION message is 6 octets
      (including message header).

8.  MASC Error Handling

   This section describes actions to be taken when errors are detected
   while processing MASC messages.  MASC Error Handling is similar to
   that of BGP [BGP].

   When any of the conditions described here are detected, a
   NOTIFICATION message with the indicated Error Code, Error Subcode,
   and Data fields is sent.  In addition, the MASC connection might be
   closed.  If no Error Subcode is specified, then a zero (Unspecific)
   must be used.

   The phrase "the MASC connection is closed" means that the transport
   protocol connection has been closed and that all resources for that
   MASC connection have been deallocated.

   Unless specified explicitly, the Data field of the NOTIFICATION
   message is empty.

8.1.  Message Header Error Handling

   All errors detected while processing the Message Header are indicated
   by sending the NOTIFICATION message with Error Code Message Header
   Error.  The Error Subcode elaborates on the specific nature of the
   error.  The Data field contains the erroneous Message (including the
   message header).

   If the Length field of the message header is less than 4 or greater
   than 4096, or if the length of an OPEN message is less  than the
   minimum length of the OPEN message, or if the length of an UPDATE
   message is less than the minimum length of the UPDATE message, or if
   the length of a KEEPALIVE message is not equal to 4, then the Error
   Subcode is set to Bad Message Length.

   If the Type field of the message header is not recognized, then the
   Error Subcode is set to Bad Message Type.







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


8.2.  OPEN Message Error Handling

   All errors detected while processing the OPEN message are indicated
   by sending the NOTIFICATION message with Error Code OPEN Message
   Error.  The Error Subcode elaborates on the specific nature of the
   error.  The Data field contains the erroneous OPEN Message (excluding
   the Message Header), unless stated otherwise.

   If the version number contained in the Version field of the received
   OPEN message is not supported, then the Error Subcode is set to
   Unsupported Version Number.  The Data field is a 1-octet unsigned
   integer, which indicates the largest locally supported version number
   less than the version the remote MASC node bid (as indicated in the
   received OPEN message).

   If the Sender Domain Identifier field of the OPEN message is
   unacceptable, then the Error Subcode is set to Bad Peer Domain ID.
   The determination of acceptable Domain IDs is outside the scope of
   this protocol.

   If the Sender MASC Node Identifier field of the OPEN message is
   unacceptable, then the Error Subcode is set to Bad Peer MASC Node ID.
   The determination of acceptable Node IDs is outside the scope of this
   protocol.

   If the Hold Time field of the OPEN message is unacceptable, then the
   Error Subcode MUST be set to Unacceptable Hold Time.  An
   implementation MUST reject Hold Time values of one or two seconds.
   An implementation MAY reject any proposed Hold Time.  An
   implementation which accepts a Hold Time MUST use the negotiated
   value for the Hold Time.

   If the remote system's proposed Role is INTERNAL_PEER, and either
   (but not both) the local system or the remote system's Parent Domain
   ID is [TLD_ID], then the Error Subcode is set to Invalid Parent
   Configuration.  The Data field must be filled with all the local
   system's Parent Domain IDs.

   If the remote system's proposed Role conflicts with its expected role
   (based on the local system's configured Role), then the Error Subcode
   is set to Inconsistent Role.  The Data field is 1-octet long, and
   contains the local system's configured Role.

   If the remote system's Parent Domain ID is unacceptable, then the
   Error Subcode is set to Bad Parent Domain ID, and the Data field is
   filled with the erroneous Parent Domain ID.  The determination of
   acceptable Parent Domain ID is outside the scope of this protocol.




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


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

   If the Address Family is unrecognized, then the Error Subcode is set
   to Unrecognized Address Family.

8.3.  UPDATE Message Error Handling

   All errors detected while processing the UPDATE message are indicated
   by sending the NOTIFICATION message with Error Code UPDATE Message
   Error.  The error subcode elaborates on the specific nature of the
   error.  The Data field contains the erroneous UPDATE Message
   (including the attribute header, but excluding the Message Header),
   unless stated otherwise.

   If any recognized attribute has an Attribute Length that conflicts
   with the expected length (based on the attribute type code), then the
   Error Subcode is set to Attribute Length Error.

   If any of the mandatory well-known attributes are not recognized,
   then the Error Subcode is set to Unrecognized Required Attribute.

   If the Address field includes an invalid address (except 0), then the
   Error Subcode is set to Invalid Address.

   If the Mask field includes an invalid mask (for example, starting
   with 0), then the Error Subcode is set to Invalid Mask.

   If the Mask field includes a non-contiguous bitmask, and that MASC
   server does not support, or is not configured to use non-contiguous
   masks, then the Error Subcode is set to Non-Contiguous Mask.

   If the Address Family is unrecognized, then the Error Subcode is set
   to Unrecognized Address Family.

   If the Origin Role/Claim Type combination is not one of the
   following, then the Error Subcode is set to Claim Type Error.











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


      Origin  Claim
      Role    Type

      ICS     PREFIX_IN_USE   (0)
      I  P    CLAIM_DENIED    (1)
      ICS     CLAIM_TO_EXPAND (2)
      ICS     NEW_CLAIM       (3)
      I  P    PREFIX_MANAGED  (4)
      ICSP    WITHDRAW        (5)

   If there is a reason to believe that the Origin Domain ID is invalid,
   then the Error Subcode is set to Origin Domain ID Error.  The same
   applies for Origin Node ID (the corresponding error is Origin Node ID
   Error).

   If a node (usually a parent receiving a claim from a child) decides
   that the Claim Lifetime is too short (for example, less than 172800,
   i.e. 48 hours), it MAY send an UPDATE Message Error with subcode
   Claim Lifetime Too Short.

   If a node (usually a parent receiving a claim from a child) decides
   that the Claim Lifetime is too long (for example, more than
   15,768,000, i.e. half year), then it MAY send an UPDATE Message Error
   with subcode Claim Lifetime Too Long.  Note that usually a parent
   MASC node should send first CLAIM_DENIED collision messages with
   Claim Lifetime field filled with the longest acceptable lifetime.  If
   the child refuses to claim with shorter lifetime, then Claim Lifetime
   Too Long should be sent.

   If a node (usually a parent receiving a claim from a child) decides
   that the Claim Timestamp is too small, i.e. too old (for example, if
   a node is self-confident that its clock is quite accurate), then it
   MUST send an UPDATE Message Error with subcode Claim Timestamp Too
   Old.  Claim Timestamp Too New is defined similarly.

   If a node (usually a parent receiving a claim from a child) decides
   that the prefix size implied by the Mask field is too small (for
   example, smaller than 16 addresses), then it MAY send an UPDATE
   Message Error with subcode Claim Prefix Size Too Small.

   If a node (usually a parent receiving a claim from a child) decides
   that the prefix size implied by the Mask field is too large, then it
   MAY send an UPDATE Message Error with subcode Claim Prefix Size Too
   Large.  Note that usually a parent MASC node should send first
   CLAIM_DENIED collision messages for some subrange of the child's
   large claimed address range.  If the child refuses to shrink the
   claim size, then Claim Prefix Size Too Large should be sent.




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


   If the received UPDATE message's computed Updated Origin Role is
   illegal (see Table 1 in Section 11.1), then the Error Subcode is set
   to Illegal Origin Role Error.

   If the received UPDATE message needs to be associated with a parent's
   prefix, but the association is not successful, then the Error Subcode
   is set to No Appropriate Parent Prefix.  The No Appropriate Child
   Prefix, No Appropriate Internal Prefix, and No Appropriate Sibling
   Prefix Error Subcodes are defined similarly.

   If a node decides that the Claim Holdtime is too short (for example,
   just few seconds), it MAY send an UPDATE Message Error with subcode
   Claim Holdtime Too Short.

   If a node decides that the Claim Holdtime is too long (for example,
   more than 15,768,000, i.e. half year), then it SHOULD send an UPDATE
   Message Error with subcode Claim Holdtime Too Long.

   If any other error is encountered when processing attributes, then
   the Error Subcode is set to Malformed Attribute List, and the erratic
   attribute is included in the data field.

8.4.  Hold Timer Expired Error Handling

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

8.5.  Finite State Machine Error Handling

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

8.6.  NOTIFICATION Message Error Handling

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





Radoslavov, et al.            Experimental