Internet Engineering Task Force Edison de Queiroz Albuquerque INTERNET DRAFT UNICAMP-SP-BRAZIL Document:draft-albuquerque-bi-dir-multicast-00.txt February 2006 Expiration Date: August 2006 Bi-directional Multicast Protocol 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document addresses the problem of providing a bi-directional multicast protocol in an Intranet environment. A protocol named Switched Bi-directional Multicast Protocol (XMP) is proposed. Participants(Sender, S, or Receivers, Rs)signal their will to join the group sending a START(G) packet toward a Focal Point Router(FP). To take control of transmission a receiver application receives permission from the master application (the master transmitter)and sends a START(G) packet re-labeling the involved routers interfaces from R to S. The master Sender resumes transmission by means of his application commanding the receiver's application to go back to the receiver mode and emitting a START(G)packet to FP. ns-2 has been used to simulate it. Albuquerque, E.Q. Expires August 2006 [Page 1] INTERNET DRAFT Bi-directional Multicast Protocol February 2006 Conventions used in this document 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 [5]. Table of Contents Status of this Memo.................................................1 Abstract............................................................1 1. Introduction....................................................3 2. Concepts and Framework..........................................3 3. Operation of XMP................................................4 4. State Table.....................................................6 5. Conclusion......................................................6 6. Acknowledgements................................................7 7. Informative Reference...........................................7 8. Normative Reference.............................................7 9. Authors' Addresses...............................................7 10. Intellectual Property Statement.................................8 Albuquerque, E.Q. Expires August 2006 [Page 2] INTERNET DRAFT Bi-directional Multicast Protocol February 2006 1. Introduction Applications of multicast include Distance learning, group meeting, and so on. Seeing one another increases interactivity specially for distance learning use. IP multicast is a reasonable solution once the use of Multi-point Control Unit (MCU) is expensive. Furthermore dividing a screen in more than 4(four) parts is useless for the faces appear too small and it is uncomfortable for the eyes. Besides, just like any conference, participants are not allowed to place their contributions and/or questions but one at a time. And just like any regular conference people enroll for questioning and are allowed to speak when a moderator gives him (her) his (her)turn. This proposed protocol aims simplicity which means low costs when it comes to upgrade routers and pay for more speed in the links (or none at all). As long as intranets (corporate networks) usually has a main site (not necessarily the headquarter) it is natural to locate a Focal Point router at this site which will be the reference for all participants of a multicast session to point to, wherever they are inside a (nation or worldwide)company. Although this anchor approach does not optimize traffic on the network it greatly simplifies the protocol, its operation and the program source switching mechanism. 2. Concepts and Framework In this document, two key roles are defined for Bi-directional Multicast Protocol (XMP): - MH: Master Host, which is the main source of program (for example, audio/video). MH initiates and ends transmission of a multicast session. - RH: Receiving Host, which participates passively receiving the MH transmission but can ask to become (and effectively become) a temporary program source. - SM: Session Moderator, which will manage the participants interventions. SM application will be asked by some participant to become a program source. SM application will allow the participant's application to take over transmission and will end it returning transmission to MH. It is acceptable to make MH also perform SM activities unless a specific situation requires their separation. - TM: Transient Master, which is a regular RH that asked and was allowed to behave as a MH temporarily. Albuquerque, E.Q. Expires August 2006 [Page 3] INTERNET DRAFT Bi-directional Multicast Protocol February 2006 - FP: Focal Point router, which anchors the multicast session. Every participant points to FP's IP address wherever they are all over the intranet. FP is a dedicated router and its location is a convenient site chosen by the corporate network administrator, usually the site with a great concentration of equipment and traffic. Although the company's Headquarter fulfills this requirement for most companies it isn't always the case. FP will build and maintain an additional routing table which will be called XMP Routing Table (XRT) for each group, as will be described later, as long as the group is active. - IR: Intermediate router, which is any router in the path of XMP packets to and from FP and the participant hosts. Every IR will build and maintain an XRT, for each group, as long as the group is active. 3. Operation of XMP XMP may be explained as the set of 5 (five) phases: Initially the applications gather information about the multicast session via, for example, a Web page. The info needed are the FP's IP address, the group number and the group class D address (assigned by the network administrator). Phase 1:In this phase MH/SM (will be referenced by S, Sender) and RHs (will be referenced by R, Receiver) send a START(G)(Figure 1.1) message to FP. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Number| Who I Am | Message Type | | | (WIAm) | | |_____________|_______________|_______________| | Pay Load (only for PGM packets) | |_____________________________________________| Figure 1.1 - XMP packet format This message contains the fields Group Number, Who I Am (MH or RH) and the type of message (START, STOP or PGM). PGM usually is an audio/video signal from MH to all RHs. The START(G) is sent unicast to FP. At each router in its way to FP this packet is forwarded by conventional means, i.e., consulting the regular Routing Table. Each router in the path to FP will build an additional routing table (XRT) for each active group. FP will build its own XRT (see example in the Figure 1.2). _____________________ | Interface | Label | |___________|_______| | 1 | S | |___________|_______| | 2 | R | |___________|_______| Figure 1.2 - XRT format Albuquerque, E.Q. Expires August 2006 [Page 4] INTERNET DRAFT Bi-directional Multicast Protocol February 2006 In case that, for a given interface, there are packets coming from either S and R that interface will be labeled as S. Phase 2: MH (the Sender, S) start transmitting PGM Packets in multicast mode. Intermediate Routers (IR) will send this packet in every interface labeled as R. FP does the same, consulting its XRT. Phase 3: When some RH wants to make an intervention it asks MH/SM. This is done by RH's application sending a unicast packet to MH/SM application (the MH/SM's IP address comes in the XMP PGM packet in the origin IP address field of the IP datagram). MH/SM applications send a unicast packet to this RH application authorizing it to enter Transient Master mode. This will make that application will send a PDU to XMP commanding it to send a START(G) packet with the field WIAm set to S. This will make every IR, and FP, to change the label of their XRT interface entry from R to S' and old S interface to R', where applicable. FP will relay this packet to MH (this is the only case that FP do not discard START(G) packets after processing it). This mechanism works as an ACKNOWLEDGEMENT to MH which, in turn, changes to RH mode. This RH, now a TM, starts sending PGM multicast packets to all participants including the former MH. Phase 4: To resume the initial condition, MH application sends a unicast packet to the RH (TM) who took over the transmission disabling forcing its application to return to RH mode and commanding XMP to send START(G) packet with the field WIAm set to R. MH sends START(G) packet with the field WIAm set to S. Remember that START(G) packets are sent to FP either from MH/SM or RH/TM. Again IRs and FP will change the interfaces to the old labels, where applicable. Phase 5: To end the current multicast session, MH sends a STOP(G) packet the field WIAm set to S, of course, to FP. This will make every IR, and FP, to delete its XRT for this group. RHs sends START(G) packets every 3 minutes (or other configurable time interval) so the routers involved will know they are alive. If if any START(G) packet is not receive for more that 3 minutes than the respective interface is removed from XRT. Albuquerque, E.Q. Expires August 2006 [Page 5] INTERNET DRAFT Bi-directional Multicast Protocol February 2006 4. State Table It is presented, in Table 1.1, the State Table for XMP interface processing at each router involved. Table 1.1 - State Table (for every Group and interface) __________________________________________________________________ | | Event = incoming packet (if = interface) | |__________|______________________________________________________| | Previous | | | | | Time-out | | State | START+R | START+S | PGM+S | STOP+S | (3 min) | |__________|__________|__________|___________|________|___________| |if = idle | if -> R | if -> S | -- | -- | -- | | |do 1,2,(3)|do 1,2,(3)| | | | |__________|__________|__________|___________|________|___________| |if = R | do 2,(3) | if -> S | -- | -- |delete this| | | | do 2,(3) | | |if from XRT| |__________|__________|__________|___________|________|___________| |if = S | do 2,(3) | do 2,(3) |send packet|del XRT.| -- | | | | |to every if|do 2,(3)| | | | | |labeled R | | | | | | | do 2,(3) | | | |__________|__________|__________|___________|________|___________| Notes: do 1 - enter XRT with incoming if and WIAm do 2 - (re)start timer for this if do 3 - send packet to FP (not applicable for FP router) Important - Every event not considered in the State Table should result in packet discard. 5. Conclusion This document has discussed the delivering of a multicast protocol that provides bi-directionality allowing receivers, in a multicast session, to become senders. The design of XMP aimed a light protocol so not to pose overload on existing routers and links avoiding undesirable costs to change or upgrade routers and/or increase the speed of links. It was thought of, but not proposed here, two additional players (the WIAm field) such as SenderPlayingReceiver and ReceiverPlayingSender (the mentioned TM). In the simulation it was found that XMP works well without these additional types of participants. Another feature that was thought of, but not implemented, was a TOKEN type packet, which would pass permission to RH to become a Sender inside the XMP protocol. Again, for the sake of simplicity (read few lines of code and/or small router memory and CPU usage) this feature has been left for the applications to take care of. Depending on the implementation of the router's IOS it might be better to build a single XRT for all groups adding a column for the group number. Albuquerque, E.Q. Expires August 2006 [Page 6] INTERNET DRAFT Bi-directional Multicast Protocol February 2006 6. Acknowledgements We would like to thank Alexandre Falcao for his valuable comments and suggestions on this document. 7. Informative References [1] Martin W. Murhammer, et al., "TCP/IP Tutorial and Technical Overview", MAKRON Books, 2000. [2] Stevens, W. Richard, "TCP/IP Illustrated - vol 1, Addison Wesley 1994. [3] Estrin D., et al., Request for Comments: RFC 2117 - Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification. [4] Handley M., et al, Bi-directional Protocol Independet Multicast (BIDIR-PIM), http://www.ietf.org/internet-drafts/draft-ietf-pim-bidir-05.txt. 8. Normative References [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9. Authors' Address Edison de Queiroz Albuquerque UNIBRATEC Recife, Pernambuco, Brasil Tel: +55 81 33048714 Email: albuquerque@ieee.org Albuquerque, E.Q. Expires August 2006 [Page 7] INTERNET DRAFT Bi-directional Multicast Protocol February 2006 10. 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. Full Copyright Notice 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. 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. Albuquerque, E.Q. Expires August 2006 [Page 8]