Internet DRAFT - draft-albuquerque-bi-dir-multicast
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
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]