Internet-Draft J. Mark Pullen Expires: September 1, 2006 George Mason Univ February 2006 Overlay Multicast Protocol draft-pullen-omcast-00.txt 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 BCP 79. 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. This Internet-Draft will expire on September 1, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines formats and procedures for middleware that operates at the application layer to provide for transmission of IP multicast over IP networks that do not have network layer multicasting enabled, by means of tunneling IP multicast over IP unicast. This capability is called overlay multicast (OMCAST). While it cannot be as efficient as network layer multicasting, OMCAST allows for transparent support of IP multicast applications. Because the relay agents can cooperate to forward multicast messages in a way modeled after network layer multicast trees, significant reductions in network traffic are possible as compared to parallel transmission by each host to all other participating hosts. However, this protocol only provides mechanisms for the agents to cooperate; it does not prescribe a mechanism for routing messages among the agents. Pullen Expires September 1, 2006 [Page 1] Internet-Draft Overlay Multicast Protocol February 2006 Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 2. Basic concept . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Relay identifier . . . . . . . . . . . . . . . . . . . . . 3 2.2. Maximum transfer unit (MTU) . . . . . . . . . . . . . . . . 3 2.3. Time measurement . . . . . . . . . . . . . . . . . . . . . 3 3. Message formats . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Header preamble . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Tunnel header IPv4 . . . . . . . . . . . . . . . . . . . . 5 3.3. Tunnel header IPv6 . . . . . . . . . . . . . . . . . . . . 6 3.4. Routing table . . . . . . . . . . . . . . . . . . . . . . . 7 3.5. Echotimes message . . . . . . . . . . . . . . . . . . . . . 8 3.6. Echo request message . . . . . . . . . . . . . . . . . . . 9 3.7. Echo reply message . . . . . . . . . . . . . . . . . . . . 9 4. Security considerations . . . . . . . . . . . . . . . . . . .10 5. References . . . . . . . . . . . . . . . . . . . . . . . . . .10 Author's Address . . . . . . . . . . . . . . . . . . . . . . .10 Intellectual Property and Copyright Statements . . . . . . . 11 Pullen Expires September 1, 2006 [Page 2] Internet-Draft Overlay Multicast Protocol February 2006 1. Requirements notation 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 [RFC2119]. 2. Basic concept This protocol defines basic mechanisms necessary for middleware agents to support overlay multicasting, where each subnet that is capable of network layer IP multicasting as defined in [RFC1112] is supported by one relay agent host. The relay agents interact with subnet multicast using IGMP v 3 [RFC3376] so as to transparently forward multicast messages among participating subnets as if the forwarding were being accomplished by a multicast router network. The messages are forwarded using IP multicast over IP unicast tunnels. The cooperating relay agents may be able to approximate a network-layer multicast tree and thereby reduce overall network traffic significantly as compared to each host sending to all other hosts requiring group communication. We define a multicasting overlay as a group of agents, one per multicast-capable subnet, that cooperate to ensure that IP multicast traffic for the multicast group address[es] they support is distributed via IP unicast to all members of the overlay. The messages can be sent by any usable transport protocol. This protocol does not address any means of routing traffic among the relay agents in the overlay to reduce overall network traffic; that is left the the implementation. The focus of this protocol is to define message formats and prodedures needed to enable operation of the overlay. 2.1. Relay identifier Each relay is identified by a 32-bit code called a Relay Identifier (RI), which may be its IPv4 address, and must be globally unique within the overlay. The RI has no significance outside of the overlay. 2.2. Maximum transfer unit (MTU) There is an implementation-defined MTU which defines the largest possible message. In addition to the obvious limit imposed on payload message lengths, the MTU also limits the size of the overlay because some control messages contain one or more entries per relay agent in the overlay. However, the natural scope of an overlay is intended to be less than 100 relays. At this scope, the largest control message (routing table message) easily fits within the 1500 byte IEEE 802.3 MTU. Pullen Expires September 1, 2006 [Page 3] Internet-Draft Overlay Multicast Protocol February 2006 2.3. Time measurement The protocol includes a mechanism to obtain round trip timing between any two relays in the overlay. Time is measured for round trips only, avoiding a need to synchronize relay clocks. 3. Message formats 3.1. Header preamble Every OMCAST message begins with the following preamble: 0 8 16 24 32 +--------------+--------------+--------------+--------------+ | version |format| HTL | length | +--------------+--------------+--------------+--------------+ | originating RI | +--------------+--------------+--------------+--------------+ version 8 bits currently x01 format 4 bits one of the message formats below hops to live (HTL) 4 bits decremented by each relay that forwards the message; if 0, message will not be forwarded length 16 bits length of this entire message in bytes originating relay identifier 32 bits RI of the relay that first sent the message Pullen Expires September 1, 2006 [Page 4] Internet-Draft Overlay Multicast Protocol February 2006 3.2. Tunnel header IPv4 The unicast header that encapsulates message payload over IPv4: 0 8 16 24 32 +--------------+--------------+--------------+--------------+ | sending host IPv4 address | +--------------+--------------+--------------+--------------+ | multicast group IPv4 address | +--------------+--------------+--------------+--------------+ | source port | destination port | +--------------+--------------+--------------+--------------+ sending host IPv4 address 32 bits multicast group IPv4 address 32 bits source port 16 bits from original sending host destination port 16 bits This header is followed by the payload message. Total size is not larger than the MTU. Pullen Expires September 1, 2006 [Page 5] Internet-Draft Overlay Multicast Protocol February 2006 3.3. Tunnel header IPv6 The unicast header that encapsulates message payload over IPv6: 0 8 16 24 32 +--------------+--------------+--------------+--------------+ | sending host IPv6 address | +--------------+--------------+--------------+--------------+ | | +--------------+--------------+--------------+--------------+ | | +--------------+--------------+--------------+--------------+ | | +--------------+--------------+--------------+--------------+ | multicast group IPv6 address | +--------------+--------------+--------------+--------------+ | | +--------------+--------------+--------------+--------------+ | | +--------------+--------------+--------------+--------------+ | | +--------------+--------------+--------------+--------------+ | source port | destination port | +--------------+--------------+--------------+--------------+ sending host IPv6 address 128 bits multicast group IPv6 address 128 bits source port 16 bits from original sending host destination port 16 bits This header is followed by the payload message. Total size is not larger than the MTU. Pullen Expires September 1, 2006 [Page 6] Internet-Draft Overlay Multicast Protocol February 2006 3.4. Routing table Each OMCAST relay defines its own distribution tree in terms of the relay identifiers in the overlay. The routing table consists of any number of row entries, with total message size limited by the MTU. The target RI may be a leaf node or another fork. 0 8 16 24 32 +--------------+--------------+--------------+--------------+ | number of rows | reserved | +--------------+--------------+--------------+--------------+ | number of entries row 1 | reserved | +--------------+--------------+--------------+--------------+ | fork RI | +--------------+--------------+--------------+--------------+ | target RI | +--------------+--------------+--------------+--------------+ | ... | +--------------+--------------+--------------+--------------+ | target RI | +--------------+--------------+--------------+--------------+ number of rows 16 bits reserved 16 bits The following is repeated for each row: number of entries row 1 16 bits reserved 16 bits fork RI relay identifier of a fork in the routing tree 32 bits target RI identifier of relay to which the fork is to forward 32 bits (the number of these is number fo entries) Pullen Expires September 1, 2006 [Page 7] Internet-Draft Overlay Multicast Protocol February 2006 3.5. Echotimes message Each OMCAST relay responds to echo requests from all relays in the overlay. This mechanism allows a relay to know the unicast transmit time to all other relays. The relay shares this information with all other relays by means of the echotimes messages, which is forwarded by the multicasting mechanism of the overlay. The message cannot be larger than the MTU. 0 8 16 24 32 +--------------+--------------+--------------+--------------+ | count of echoes | reserved | +--------------+--------------+--------------+--------------+ | echo RI | +--------------+--------------+--------------+--------------+ | echo time | reserved | +--------------+--------------+--------------+--------------+ | ... | +--------------+--------------+--------------+--------------+ | echo RI | +--------------+--------------+--------------+--------------+ | echo time | reserved | | +--------------+--------------+--------------+--------------+ count of echoes number of entries in the message 16 bits reserved 16 bits The following is repeated for each echo: echo RI relay identifier associated with an echo time 32 bits echo time 16 bits round trip time in milliseconds Pullen Expires September 1, 2006 [Page 8] Internet-Draft Overlay Multicast Protocol February 2006 3.6. Echo request message Message to request another relay agent to repond with Echo reply: 0 8 16 24 32 +--------------+--------------+--------------+--------------+ | reserved | SN | +--------------+--------------+--------------+--------------+ reserved 24 bits SN sequence number used to detect out of order messages 8 bits 3.7. Echo reply message Message in response to an Echo request: 0 8 16 24 32 +--------------+--------------+--------------+--------------+ | reserved | SN | +--------------+--------------+--------------+--------------+ reserved a copy of reserved field in the Echo request to which 24 bits this message replies SN sequenceNumber copy of SN field in echoRequestMessage Pullen Expires September 1, 2006 [Page 9] Internet-Draft Overlay Multicast Protocol February 2006 4. Security Considerations Overlay multicast is vulnerable to spoofing messages that purport to be from participating relay agents, which could lead to compromise of supported applications and/or denial of service due to forwarding of unanticipated volumes of attacking traffic. To protect against spoofing, implementations should identify participating overlay agents by source relay identifier and originating IP unicast address, and also should monitor sequence numbers of overlay tunnel messages, rejecting messages that are not within a fixed number (which must not exceed 100) of sequence numbers values from the last messages received. 5. Normative References [RFC1112] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, August 1989 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3376] Cain, B., S. Deering, I. Kouvelas, B. Fenner and A. Thyagarajan, "Internet Group Management Protocol, Version 3" RFC 3376, October 2002 Author's Address J. Mark Pullen Computer Science/C4I Center George Mason University Fairfax, VA 22030 Phone: +1-703-993-1538 EMail: mpullen@netlab.gmu.edu Pullen Expires September 1, 2006 [Page 10] Internet-Draft Overlay Multicast Protocol February 2006 Intellectual Property Statement 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. 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Pullen Expires September 1, 2006 [Page 11]