One document matched: draft-hsu-xcast-iana-considerations-00.txt







INTERNET DRAFT                             C. Hsu, E.Muramoto, J. Buford
<draft-hsu-xcast-iana-considerations-00.txt>                   Panasonic
                                                                 Y. Imai
                                                                 Fujitsu
                                                             Ali Boudani
                                                            IRISA-France
                                                               R. Boivie
                                                                     IBM
                                                             April, 2005
                                                  Expires  October, 2005

         IANA Considerations for XCAST (Explicit Multi-Unicast)


Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of RFC 3668.
   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Copyright Notice

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


Abstract

   XCAST (Explicit Multi-Unicast) is an experimental protocol for small



Hsu, et al.               Expires October 2005                  [Page 1]

Internet Draft draft-hsu-xcast-iana-considerations-00.txt     April 2005


   group multicasting.  This protocol requires IANA allocations for a
   new type of multicast address, a routing type of IPv6 routing header,
   an option type of Destination Option header and an option header of
   IPv6 Hop-by-Hop Options header.  This document contains guidelines to
   IANA about what allocations are required for XCAST protocol.


Table of Contents

   1. Introduction
   2. Request for IANA Resources
      2.1 Multicast Address for ALL_XCAST_NODES
      2.2 Routing Type of IPv6 Routing Header
      2.3 Option Type of IPv6 Destination Option Header
      2.4 Option Type of IPv6 Hop-by-Hop Options Header
   3. Security Considerations
   4. References
   5. Authors Addresses
   6. Full Copyright Statement
   7. IPR Notices


1.0 Introduction

   XCAST (Explicit Multi-Unicast) is an experimental multicasting
   protocol for efficient small group communications. The XCAST protocol
   [basic] and related protocols have been proposed as Internet-Drafts
   (ID) over the past few years. These IDs describe our experiences in
   building various small group communication protocols and what we have
   found to be the most important criteria of small group communication
   protocol design.

   XCAST experimentation is quite active, and multiple implementations
   have been developed by several researchers, hackers and companies
   around the world [bcp]. These results have demonstrated the
   effectiveness of the XCAST6 design, the interoperability among
   different platforms and the practical use of XCAST protocols.

   Given the growing interest in XCAST and the need to conduct more
   experimentation and testing among a large group of users, developers
   and industry participants, we would like to accelerate the deployment
   of XCAST-aware routers. According to RFC 3692 [rfc3692], we believe
   that experimental values could be obtained through IESG approval. The
   IANA assignments requested in this document represent the minimum set
   we believe is needed by the XCAST research community at this time.
   This document requires IANA allocations for new types and values of
   IPv6 headers which are defined in the XCAST protocol.




Hsu, et al.               Expires October 2005                  [Page 2]

Internet Draft draft-hsu-xcast-iana-considerations-00.txt     April 2005


   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].
   Allocation policy names Specification Required, IETF Consensus
   Action, and Designated Expert are to be interpreted as described in
   RFC 2434 [rfc2434]


2. Request for IANA Resources

   The XCAST protocol requires IANA allocations for a new type of
   multicast address, a routing type of IPv6 routing header, an option
   type of Destination Option header and an option header of IPv6 Hope-
   by-Hop Options header.

2.1 Multicast Address for ALL_XCAST_NODES

   As defined in section 9.3.1 of [basic], IANA shall assign a new type
   of multicast address, e.g,: ALL_XCAST_NODES (ff05::10), for
   identifying the destination address of IPv6 header utilized by the
   XCAST protocol.

2.2 Routing Type of IPv6 Routing Header

   As defined in section 9.3.2.1 of [basic], IANA shall assign a new
   routing type, e.g., RouteType=XCAST, for identifying the message of
   IPv6 routing header utilized by the XCAST protocol.

2.3 Option Type of IPv6 Destination Option Header

   As defined in section 9.3.2.2 of [basic], IANA shall assign a new
   option type, e.g., Option Type=Ports, for identifying the message of
   IPv6 Destination Options Header utilized by the XCAST protocol. Note
   that, the first three bits must be "010" to indicate that the packet
   must be discarded if the option is unknown and that the option can be
   changed en-route.

2.4 Option Type of IPv6 Hop-by-Hop Options Header

   As defined in section 11.3 of [basic], IANA shall assign a new option
   type, e.g., Option Type=XCAST, for identifying the message of IPv6
   Hop-by-Hop Options Header utilized by the semi-permeable tunneling
   mechanism of the XCAST protocol. Note that, the first two bits must
   be "00" to ensure that routers that cannot recognize XCAST can treat
   the XCAST datagram as a normal IPv6 datagram and forward it toward
   the destination in the IPv6 header.





Hsu, et al.               Expires October 2005                  [Page 3]

Internet Draft draft-hsu-xcast-iana-considerations-00.txt     April 2005


3. Security Considerations

   This document has no known security implications.


4. References


[rfc2026]   S. Bradner, "The Internet Standards Process -- Revision 3",
            BCP 9, RFC 2026, October 1996.

[rfc2434]   Narten, T., and Alvestrand, H., "Guidelines for Writing an
            IANA Considerations Section in RFCs", RFC 2434, October,
            1998.

[basic]     R. Boivie, et al., "Explicit Multicast (XCAST) Basic Speci-
            fication",draft-ooms-xcast-basic-spec-07.txt. January 2005

[bcp]       Y. Imai, et al., "Best Current Practices of XCAST (Explicit
            Multi-Unicast) by 2004", draft-imai-xcast-bcp-2004-00.txt.
            Feburuary 2005. Submitted for Informational RFC.

[rfc3692]   Narten, T., "Assigning Experimental and Testing Numbers Con-
            sidered Useful", RFC 3692, January, 2004.


5. Authors Addresses


      Chih-Chang Hsu
      Matsushita Electric Industrial Co., Ltd.
      4-5-15 Higashi-shinagawa, Shinagawa-ku, Tokyo 140-8632, Japan
      Phone : +81-3-5460-2734
      E-mail: hsu.mike@jp.panasonic.com

      Eiichi Muramoto
      Matsushita Electric Industrial Co., Ltd.
      4-5-15 Higashi-shinagawa, Shinagawa-ku, Tokyo 140-8632, Japan
      Phone : +81-3-5460-2734
      E-mail: muramoto.eiichi@jp.panasonic.com

      Yuji Imai
      Fujitsu LABORATORIES Ltd.
      1-1, Kamikodanaka 4-Chome, Nakahara-ku, Kawasaki 211-8588, Japan
      Phone : +81-44-754-2628
      Fax   : +81-44-754-2793
      E-mail: kimai@flab.fujitsu.co.jp




Hsu, et al.               Expires October 2005                  [Page 4]

Internet Draft draft-hsu-xcast-iana-considerations-00.txt     April 2005


      John F. Buford
      Panasonic Digital Networking Laboratory
      Two Research Way, Princeton, NJ 08540, USA
      Phone : +1-609-734-7342
      Fax   : +1-609-987-8827
      E-mail: buford@research.panasonic.com

      Ali Boudani
      IRISA/INRIA Rennes
      Campus Universitaire de Beaulieu
      Avenue du General Leclerc 35042 Rennes France
      Phone : (33) 02 99 84 25 37
      Fax : (33) 02 99 84 25 29
      E-mail : aboudani@irisa.fr

      Rick Boivie
      IBM T. J. Watson Research Center
      19 Skyline Drive
      Hawthorne, NY 10532
      Phone: 914-784-3251
      Email: rhboivie@us.ibm.com


7. Full Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM 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.


8. IPR Notices

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology
   described in this document or the extent to which any license
   under such rights might or might not be available; nor does it
   represent that it has made any independent effort to identify any
   such rights.  Information on the procedures with respect to
   rights in RFC documents can be found in BCP 78 and BCP 79.



Hsu, et al.               Expires October 2005                  [Page 5]

Internet Draft draft-hsu-xcast-iana-considerations-00.txt     April 2005


   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention
   any copyrights, patents or patent applications, or other
   proprietary rights that may cover technology that may be required
   to implement this standard.  Please address the information to the
   IETF at ietf-ipr@ietf.org.







































Hsu, et al.               Expires October 2005                  [Page 6]


PAFTECH AB 2003-20262026-04-24 09:08:09