Internet DRAFT - draft-albuquerque-bi-dir-multicast


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

   The list of Internet-Draft Shadow Directories can be accessed at


   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",
   this document are to be interpreted as described in RFC-2119 [5].

Table of Contents

   Status of this Memo.................................................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
   - 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)  |        |           |

   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),

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
   Recife, Pernambuco, Brasil
   Tel: +55 81 33048714

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

   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-

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

   This document and the information contained herein are provided

Albuquerque, E.Q.               Expires August 2006            [Page 8]