rfc2909.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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

4.  MASC Topology

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



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


   children domains.  At the top, a  number of Top-Level Domains are
   connected in a (sparse) mesh and share the global multicast address
   space.  To improve the robustness, a pair of children of the same
   parent domain MAY be configured as siblings with regard to that
   parent.

   Figure 1 illustrates a sample topology.  Double-line links denote
   intra-domain TCP peering sessions, and single-line links denote
   inter-domain TCP connections. T1 and T2 are Top-Level Domains (e.g.,
   backbone providers), containing MASC speakers T1a and T2a,
   respectively.  P3 and P4 are regional domains, containing (P3a, P3b),
   and (P4a, P4b) respectively.  P3 has a single customer (or "child"),
   C5, containing (C5a, C5b, C5c).  P4 has three children, C5, C6, C7,
   containing (C5a, C5b, C5c), (C6a, C6b), and (C7a) respectively.

                         T1a-----------T2a
                          |             |
                          |             |
                          |             |
                  P3a====P3b           P4a====P4b
                   |      |           / |    / | \
                   |      |   _______/  |   /  |  \
                   |      |  /          |  /   |   \______
                   |      | /           | /    |          \
                  C5a====C5b           C6a====C6b----------C7a
                    \\  //
                     \\//
                     C5c

                  Figure 1: Example MASC Topology

   All MASC communications use TCP. Each MASC node is connected to and
   communicates directly with other MASC nodes.  The local node acts in
   exactly one of the following four roles with respect to each remote
   note:

   INTERNAL_PEER
      The local and remote nodes are both in the same MASC domain.  For
      example, P4b is an INTERNAL_PEER of P4a.

   CHILD
      A customer relationship exists whereby the local node may obtain
      address space from the remote node.  For example, C6a is a CHILD
      in its session with P4a.







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


   PARENT
      A provider relationship exists whereby the remote node may obtain
      address space from the local node.  For example, T2a is a PARENT
      in its session with P4a.  Whether space is actually requested is
      up to the implementation and local policy configuration.

   SIBLING
      No customer-provider relationship exists.  For example, T2a is a
      SIBLING in its session with T1a (Top-Level Domain SIBLING
      peering).  Also, C6b is a SIBLING in its session with C7a with
      regard to their common parent P4.

   A node's message will be propagated to its parent, all siblings with
   the same parent, and its children.  Since a domain need not have a
   direct peering session with every sibling, a MASC domain must
   propagate messages from a child domain to other children, can
   propagate messages from a parent domain to other siblings, and, if a
   Top-Level Domain, it must propagate messages from a sibling to other
   siblings, otherwise may propagate messages from a sibling domain to
   its parent and other siblings.

4.1.  Managed vs Locally-Allocated Space

   Each domain has a "Managed" Address Set, and a "Locally-Allocated"
   Address Set.  The "managed" space includes all address space which a
   domain has successfully claimed via MASC.  The "locally-allocated"
   space, on the other hand, includes all address space which MAASs
   inside the domain may use.  Thus, the locally-allocated space is a
   subset of the managed space, and refers to the portion which a domain
   allocates for its own use.

   For leaf domains (ones with no children), these two sets are
   identical, since all claimed space is allocated for local use.  A
   parent domain, on the other hand, "manages" all address space which
   it has claimed via MASC, while sub-prefixes can be allocated to
   itself and to its children.

4.2.  Prefix Lifetime

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







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


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

4.3.  Active vs. Deprecated Prefixes

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

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

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

4.5.  Administratively-Scoped Address Allocation

   MASC can also be used for sub-allocating prefixes of addresses within
   an administrative scope zone [SCOPE], but only if the scope is
   "divisible" (as described in [MALLOC] and [MZAP]).  A MASC node can
   learn what scopes it resides within by listening to MZAP [MZAP]
   messages.

   A "Zone TLD" is a domain which has no parent domain within the scope
   zone.  Zone TLDs act as TLDs for the prefix associated with the
   scope.  Figure 2 gives an example, where a scope boundary around
   domains P3 and C5 has been added to Figure 1.  Domain P3 is a Zone
   TLD, since its only parent (T1) is outside the boundary.  Hence, P3
   can claim space directly out of the prefix associated with the scope
   itself.  Domain C5, on the other hand, has a parent within the scope
   (namely, P3), and hence is not a Zone TLD.










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


                                 T1a-----------T2a
                                  |             |
                      ............|.......      |
                      .           |      .      |
                      .   P3a====P3b     .     P4a
                      .    |      |      .    /
                      .    |      |   _______/
                      .    |      |  /   .
                      .    |      | /    .
                      .   C5a====C5b     .
                      .     \\  //       .
                      .      \\//        .
                      .      C5c         .
                      .                  .
                      . Admin Scope Zone .
                      ....................

                 Figure 2: Scope Zone Example

   It is assumed that the role of a node (as discussed in Section 4)
   with respect to a given peering session is the same for every scope
   in which both ends are contained.  A peering session that crosses a
   scope boundary (such as the session between C5b and P4a in Figure 2)
   is ignored when propagating messages that pertain to the given scope.
   That is, such messages are not sent across such sessions.

5.  Protocol Details

5.1.  Claiming Space

   When a MASC node, on behalf of a MASC domain, needs more address
   space, it decides locally the size and the value of the address
   prefix(es) it will claim from one of its parents.  For example, the
   decision might be based on the knowledge this node has about its
   parent's address set, its siblings' claims and allocations, its own
   address set, the claim messages from its siblings, and/or the demand
   pattern of its children and the local domain.  A sample algorithm is
   given in Appendix A.

   A MASC node which is not in a top-level domain can initiate a claim
   toward a parent MASC domain if and only if it currently has an
   established connection with at least one node in that parent domain.

   After the prefix address and size are decided, the claim proceeds as
   follows:






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


   a) The claim is scheduled to be sent after a random delay in the
      interval (0, [INITIATE_CLAIM_DELAY]).  If a claim originated by a
      node from the same MASC domain is received, and that claim
      eliminates the need for the local claim, the local claim is
      canceled and no further action is taken.

   b) The claim is sent to one of the parents (if the domain is not a
      top-level domain), all known siblings with the same parent, and
      all internal peers.  A Claim-Timer is then started at
      [WAITING_PERIOD], and the MASC node starts listening for colliding
      claims.

   c) If a colliding claim is received while the Claim-Timer is running,
      that claim is compared with the locally initiated claim using the
      function described in Section 5.1.1.  If the local claim is the
      loser, a new prefix must be chosen to claim, and the loser claim's
      Claim-Timer must be canceled.  The loser claim can be either
      explicitly withdrawn, or can be left to expire without taking
      further actions.  If the winning claim was originated by a node
      from the same MASC domain, no new claim will be initiated.  If the
      local claim is the winner, no actions need to be taken.

   d) If the Claim-Timer expires, the claimed prefix becomes associated
      with the claimer's domain, i.e. it is considered allocated to that
      domain and the following actions can be performed:

      o  Advertise the prefix to its parent, and to all siblings with
         the same parent, by sending a PREFIX_IN_USE claim to them.

      o  Inject the prefix into the G-RIB of the inter-domain routing
         protocol.

      o  Send a PREFIX_MANAGED message to all children and internal
         peers, informing them that they may issue claims within the
         managed space.  A sub-prefix may then be claimed for local
         usage (see Section 12.2).

   Each MASC node receives all claims from its siblings and children.  A
   received claim must be evaluated against all claims saved in the
   local cache using the function described in Section 5.1.1.  The
   output of the function will define the further processing of that
   claim (see Section 11).









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


5.1.1.  Claim Comparison Function

   Each claim message includes:

   o  a "type", being one of: PREFIX_IN_USE, CLAIM_DENIED,
      CLAIM_TO_EXPAND, or NEW_CLAIM  (PREFIX_MANAGED and WITHDRAW are