rfc2771.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 620 行 · 第 1/2 页

   scopes that are defined for this node.

   Possible errors:

           - bad address family

3.5 Querying the name of a scope:

    get_scope_name(in Scope scope,
                   in LanguageTag language,
                   out String name,
                   out LanguageTag languageForName)

   This operation returns a character-string name for a given scope.  If
   the scope has a name in the specified "language", then this name (and
   language) is returned.  Otherwise, the scope's default (language,
   name) pair is returned.

   Possible errors:

           - bad scope.






Finlayson                    Informational                      [Page 6]

RFC 2771     Abstract API for Multicast Address Allocation February 2000


3.6 Querying the nesting state of known usable multicast address scopes:

    get_scope_nesting_state(in "set of" Scope,
                            out "matrix of" NestingRelationship)

   Possible errors:

       - bad scope.
       - nesting state undetermined at this time.

   This operation would return a matrix that shows the
   current nesting relationships between the supplied
   set of scopes which would have previously been supplied
   via the get_multicast_addr_scopes(...) function.

3.7 Querying the set of scopes that a given scope is known to nest inside:

    get_larger_scopes(in Scope,
                      out "set of" Scope)

   This operation returns the set of administrative multicast
   address scopes that are known to encompass the supplied
   Scope.

   Possible errors:

       - bad scope.
       - nesting state undetermined at this time.

3.8 Querying the set of scopes that are known to nest inside a given scope:

    get_smaller_scopes(in Scope,
                      out "set of" Scope)

   This operation returns the set of administrative multicast address
   scopes that are known to nest inside the supplied Scope (NB this
   would include those scopes that are topologically identical to the
   supplied scope).

   Possible errors:

       - bad scope.
       - nesting state undetermined at this time.








Finlayson                    Informational                      [Page 7]

RFC 2771     Abstract API for Multicast Address Allocation February 2000


3.9 Note: The decision as to who is allowed to deallocate (or change
    the lifetime of) a previously allocated multicast address set lease
    is implementation-specific, and depends upon the security policy of
    the host system.  Thus it is not specified in this abstract API.
    One possible starting point, however, is the following:

      A previously allocated multicast address can be deallocated (or
      have its lifetime queried or changed) by the same "principal", and
      on the same node, as that which originally allocated it.
      ("principal" might, for example, be a "user" in the host operating
      system.)

3.10 Advance allocation

      By specifying "minDesiredStartTime = maxDesiredStartTime = 'now'",
      the address allocation operation - "alloc_multicast_addr" -
      described above can be used to request a set of multicast
      addresses that can be used *immediately* (and until their lifetime
      expires).  During this whole time, the addresses are not available
      for allocation to others.

      It is also possible - using the "minDesiredStartTime" and
      "maxDesiredStartTime" parameters - to allocate multicast addresses
      *in advance* - i.e., so that they have a future "start time" as
      well as an expiration time.  Before the start time, the multicast
      addresses may be allocated to others.

      Advance allocation is convenient for allocating addresses for
      events that begin far in the future - e.g., several weeks or
      months away.  Without advance allocation, it would be necessary to
      allocate addresses for a long period of time - even when it will
      not be used.  Such a request would not only be a wasteful use of
      the multicast address space, but it may also be difficult to
      implement (especially since address allocations are expected to
      remain valid in spite of topology changes).

      Advance allocation requests can produce the following errors (in
      addition to those defined earlier):

      - bad start time durations (e.g., max < min)
      - requested start times conflict with requested lifetimes
        (i.e., min start time > max lifetime)









Finlayson                    Informational                      [Page 8]

RFC 2771     Abstract API for Multicast Address Allocation February 2000


   The following operation is also defined:

      change_multicast_addr_start_time(in Lease multicastAddressSetLease,
                                       in Time minDesiredStartTime,
                                       in Time maxDesiredStartTime,
                                       out Time startTime)


      This operation attempts to change the start time of previously
      allocated multicast addresses.  Unless an error occurs, it returns
      the new start time (which might remain unchanged).

      Possible errors: the same as "change_multicast_addr_lifetime"

4. Security Considerations

   As noted in section 5.9 above, each implementation of this abstract
   API should define a security policy that specifies when (and by whom)
   previously allocated multicast addresses can be deallocated (or
   queried, or have their lifetime changed).

   Because multicast addresses are a finite resource, there is a
   potential for a "denial of service" attack by allocating a large
   number of multicast addresses without deallocating them.  Preventing
   such an attack, however, is not the role of the API, but rather by
   the underlying MAAS ("Multicast Address Allocation Server(s)" [6]).

5. Acknowledgements

   Many thanks to other participants in the "MALLOC" working group - in
   particular Steve Hanna, Dave Thaler, Roger Kermode, and Pavlin
   Radoslavov - for their valuable comments.

6. References

   [1] Hanna, S., Patel, B. and M. Shah, "Multicast Address Dynamic
       Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.

   [2] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
       1112, August 1989.

   [3] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
       2365, July, 1998.

   [4] Alvestrand, H., "Tags for the Identification of Languages", RFC
       1766, March 1995.





Finlayson                    Informational                      [Page 9]

RFC 2771     Abstract API for Multicast Address Allocation February 2000


   [5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
       RFC 2327, April 1998.

   [6] Estrin, D., Handley, M. and D. Thaler, "The Internet Multicast
       Address Allocation Architecture", Work in Progress.

   [7] Kermode, R., "MADCAP Multicast Scope Nesting State Option", Work
       in Progress.

7. Author's Address

   Ross Finlayson,
   Live Networks, Inc. (LIVE.COM)

   EMail: [e-mail]
   WWW: http://www.live.com/



































Finlayson                    Informational                     [Page 10]

RFC 2771     Abstract API for Multicast Address Allocation February 2000


8. Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Finlayson                    Informational                     [Page 11]