rfc2909.txt

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

Network Working Group                                      P. Radoslavov
Request for Comments: 2909                                     D. Estrin
Category: Experimental                                       R. Govindan
                                                                 USC/ISI
                                                              M. Handley
                                                                   ACIRI
                                                                S. Kumar
                                                                 USC/ISI
                                                               D. Thaler
                                                               Microsoft
                                                          September 2000


            The Multicast Address-Set Claim (MASC) Protocol

Status of this Memo

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

Copyright Notice

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

Abstract

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













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


Table of Contents

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



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


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




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


1.  Introduction

   This document describes MASC, a protocol for inter-domain multicast
   address set allocation.  The MASC protocol (a Layer-3 protocol in the
   multicast address allocation architecture [MALLOC]) is used by a node
   (typically a router) to claim and allocate one or more address
   prefixes to that node's domain.  Each prefix has an associated
   lifetime, and is chosen out of a larger prefix with a lifetime at
   least as long, in a manner such that prefixes are aggregatable.  At
   any time, each MASC node (a Prefix Coordinator in [MALLOC]) will
   typically advertise several prefixes with different lifetimes and
   scopes, allowing Multicast Address Allocation Servers (MAAS's) in
   that domain or child MASC domains to choose appropriate addresses for
   their clients.

   The set of prefixes ("address set") associated with a domain is
   injected into an inter-domain routing protocol (e.g., BGP4+ [MBGP]),
   where it can be used by an inter-domain multicast tree construction
   protocol (e.g., BGMP [BGMP]) to construct inter-domain group-shared
   trees.

   Note that a domain does not need to allocate an address set for the
   hosts in that domain to be able to allocate group addresses, nor does
   allocating necessarily guarantee that hosts in other domains will not
   use an address in the set (since, for example, hosts are not forced
   to contact a MAAS before using a group address).  Allocating an
   address set to a domain does, however, ensure that inter-domain
   group-specific multicast distribution trees for any group in the
   address set will be locally-rooted, and that traffic will be sent
   outside the given domain only when and where external receivers
   exist.

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   Constants used by this protocol are shown as [NAME_OF_CONSTANT], and
   summarized in Section 6.

1.2.  Definitions

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





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


   MAAS (Multicast Address Allocation Server)
      A host providing multicast address allocation services to end
      users (e.g. via MADCAP [MADCAP]).

   MASC server
      A node running MASC.

   Peer
      Other MASC speakers a node directly communicates with.

   Multicast
      IP Multicast, as defined for IPv4 in [RFC1112] and for IPv6 in
      [RFC2460].

   Multicast Address
      An IP multicast address or group address, as defined in [RFC1112]
      and [RFC2373].  An identifier for a group of nodes.

2.  Requirements for Inter-Domain Address Allocation

   The key design requirements for the inter-domain address allocation
   mechanism are:

   o  Efficient address space utilization when space is scare, which
      naturally implies that address allocations be based on the actual
      address usage patterns, and therefore that it be dynamic.

   o  Address aggregation, that implies that the address allocation
      mechanism be hierarchical.

   o  Minimize flux in the allocated address sets (e.g. the address sets
      should be reused when possible).

   o  Robustness, by using decentralized mechanisms.

   The timeliness in obtaining an address set is not a major design
   constraint as this is taken care of at a lower level [MALLOC].

3.  Overall Architecture

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



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


   sends a claim to other MASC domains in the network, and waits while
   listening for any colliding claims. If there is a collision, the
   losing claimer gives up the colliding claim and claims a different
   address set.

   After a sufficiently long collision-free waiting period, the address
   set chosen by a MASC node is considered allocated to that node's
   domain.  Three things may then happen:

   a) The allocated prefix can then be injected as a "multicast route"
      into the inter-domain routing protocol  (e.g., BGP4+ [MBGP]) as
      "G-RIB" Network Layer Reachability Information (NLRI), where it
      may be used by an inter-domain multicast routing protocol (e.g.,
      BGMP [BGMP]) to construct group-shared trees.  To reduce the size
      and slow the growth of the G-RIB, MASC nodes may perform CIDR-like
      aggregation [CIDR] of the multicast NLRI information.  This
      motivates the need for an algorithm to select prefixes for domains
      in such a way as to ensure good aggregation in addition to
      achieving good address space utilization.

   b) The node's domain may assign to itself a sub-prefix which can be
      used by MAASs within the domain.

   c) Sub-prefixes may be allocated to child domains, if any.

3.1.  Claim-Collide vs. Query-Response Rationale

   We choose a claim-collide mechanism instead of a query-response