idnits 2.17.1 draft-albuquerque-bi-dir-multicast-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 313. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 284. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 291. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 297. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 4 instances of too long lines in the document, the longest one being 76 characters in excess of 72. ** There are 24 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 129 has weird spacing: '... number and t...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2006) is 6642 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '5' is mentioned on line 50, but not defined == Unused Reference: '1' is defined on line 254, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 256, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 258, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 260, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 264, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2117 (ref. '3') (Obsoleted by RFC 2362) Summary: 7 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Edison de Queiroz Albuquerque 2 INTERNET DRAFT UNICAMP-SP-BRAZIL 3 Document:draft-albuquerque-bi-dir-multicast-00.txt February 2006 4 Expiration Date: August 2006 6 Bi-directional Multicast Protocol 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document addresses the problem of providing a bi-directional 33 multicast protocol in an Intranet environment. A protocol named 34 Switched Bi-directional Multicast Protocol (XMP) is proposed. 35 Participants(Sender, S, or Receivers, Rs)signal their will to join 36 the group sending a START(G) packet toward a Focal Point Router(FP). 37 To take control of transmission a receiver application receives 38 permission from the master application (the master transmitter)and 39 sends a START(G) packet re-labeling the involved routers interfaces 40 from R to S. The master Sender resumes transmission by means of his 41 application commanding the receiver's application to go back to the 42 receiver mode and emitting a START(G)packet to FP. ns-2 has been used 43 to simulate it. 45 Conventions used in this document 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 49 this document are to be interpreted as described in RFC-2119 [5]. 51 Table of Contents 53 Status of this Memo.................................................1 54 Abstract............................................................1 55 1. Introduction....................................................3 56 2. Concepts and Framework..........................................3 57 3. Operation of XMP................................................4 58 4. State Table.....................................................6 59 5. Conclusion......................................................6 60 6. Acknowledgements................................................7 61 7. Informative Reference...........................................7 62 8. Normative Reference.............................................7 63 9. Authors' Addresses...............................................7 64 10. Intellectual Property Statement.................................8 66 1. Introduction 68 Applications of multicast include Distance learning, group meeting, 69 and so on. Seeing one another increases interactivity specially for 70 distance learning use. IP multicast is a reasonable solution once 71 the use of Multi-point Control Unit (MCU) is expensive. Furthermore 72 dividing a screen in more than 4(four) parts is useless for the faces 73 appear too small and it is uncomfortable for the eyes. Besides, just 74 like any conference, participants are not allowed to place their 75 contributions and/or questions but one at a time. And just like any 76 regular conference people enroll for questioning and are allowed to 77 speak when a moderator gives him (her) his (her)turn. This proposed 78 protocol aims simplicity which means low costs when it comes to 79 upgrade routers and pay for more speed in the links (or none at all). 80 As long as intranets (corporate networks) usually has a main site 81 (not necessarily the headquarter) it is natural to locate a Focal 82 Point router at this site which will be the reference for all 83 participants of a multicast session to point to, wherever they are 84 inside a (nation or worldwide)company. Although this anchor approach 85 does not optimize traffic on the network it greatly simplifies the 86 protocol, its operation and the program source switching mechanism. 88 2. Concepts and Framework 90 In this document, two key roles are defined for Bi-directional 91 Multicast Protocol (XMP): 93 - MH: Master Host, which is the main source of program (for example, 94 audio/video). MH initiates and ends transmission of a multicast 95 session. 96 - RH: Receiving Host, which participates passively receiving the MH 97 transmission but can ask to become (and effectively become) a 98 temporary program source. 99 - SM: Session Moderator, which will manage the participants 100 interventions. SM application will be asked by some participant 101 to become a program source. SM application will allow the 102 participant's application to take over transmission and will end 103 it returning transmission to MH. It is acceptable to make MH 104 also perform SM activities unless a specific situation requires 105 their separation. 106 - TM: Transient Master, which is a regular RH that asked and was 107 allowed to behave as a MH temporarily. 109 - FP: Focal Point router, which anchors the multicast session. Every 110 participant points to FP's IP address wherever they are all over 111 the intranet. FP is a dedicated router and its location is a 112 convenient site chosen by the corporate network administrator, 113 usually the site with a great concentration of equipment and 114 traffic. Although the company's Headquarter fulfills this 115 requirement for most companies it isn't always the case. FP will 116 build and maintain an additional routing table which will be 117 called XMP Routing Table (XRT) for each group, as will be 118 described later, as long as the group is active. 119 - IR: Intermediate router, which is any router in the path of XMP 120 packets to and from FP and the participant hosts. Every IR will 121 build and maintain an XRT, for each group, as long as the group 122 is active. 124 3. Operation of XMP 125 XMP may be explained as the set of 5 (five) phases: 127 Initially the applications gather information about the multicast 128 session via, for example, a Web page. The info needed are the FP's IP 129 address, the group number and the group class D address (assigned 130 by the network administrator). 132 Phase 1:In this phase MH/SM (will be referenced by S, Sender) and RHs 133 (will be referenced by R, Receiver) send a START(G)(Figure 1.1) 134 message to FP. 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Group Number| Who I Am | Message Type | 137 | | (WIAm) | | 138 |_____________|_______________|_______________| 139 | Pay Load (only for PGM packets) | 140 |_____________________________________________| 141 Figure 1.1 - XMP packet format 143 This message contains the fields Group Number, Who I Am (MH or RH) 144 and the type of message (START, STOP or PGM). PGM usually is an 145 audio/video signal from MH to all RHs. The START(G) is sent unicast 146 to FP. At each router in its way to FP this packet is forwarded by 147 conventional means, i.e., consulting the regular Routing Table. Each 148 router in the path to FP will build an additional routing table (XRT) 149 for each active group. FP will build its own XRT (see example in the 150 Figure 1.2). 151 _____________________ 152 | Interface | Label | 153 |___________|_______| 154 | 1 | S | 155 |___________|_______| 156 | 2 | R | 157 |___________|_______| 158 Figure 1.2 - XRT format 159 In case that, for a given interface, there are packets coming from 160 either S and R that interface will be labeled as S. 162 Phase 2: MH (the Sender, S) start transmitting PGM Packets in 163 multicast mode. Intermediate Routers (IR) will send this packet in 164 every interface labeled as R. FP does the same, consulting its XRT. 166 Phase 3: When some RH wants to make an intervention it asks MH/SM. 167 This is done by RH's application sending a unicast packet to MH/SM 168 application (the MH/SM's IP address comes in the XMP PGM packet in 169 the origin IP address field of the IP datagram). MH/SM applications 170 send a unicast packet to this RH application authorizing it to enter 171 Transient Master mode. This will make that application will send a 172 PDU to XMP commanding it to send a START(G) packet with the field 173 WIAm set to S. This will make every IR, and FP, to change the label 174 of their XRT interface entry from R to S' and old S interface to R', 175 where applicable. FP will relay this packet to MH (this is the only 176 case that FP do not discard START(G) packets after processing it). 177 This mechanism works as an ACKNOWLEDGEMENT to MH which, in turn, 178 changes to RH mode. This RH, now a TM, starts sending PGM multicast 179 packets to all participants including the former MH. 181 Phase 4: To resume the initial condition, MH application sends a 182 unicast packet to the RH (TM) who took over the transmission 183 disabling forcing its application to return to RH mode and commanding 184 XMP to send START(G) packet with the field WIAm set to R. MH sends 185 START(G) packet with the field WIAm set to S. Remember that START(G) 186 packets are sent to FP either from MH/SM or RH/TM. Again IRs and FP 187 will change the interfaces to the old labels, where applicable. 189 Phase 5: To end the current multicast session, MH sends a STOP(G) 190 packet the field WIAm set to S, of course, to FP. This will make 191 every IR, and FP, to delete its XRT for this group. RHs sends 192 START(G) packets every 3 minutes (or other configurable time 193 interval) so the routers involved will know they are alive. If if any 194 START(G) packet is not receive for more that 3 minutes than the 195 respective interface is removed from XRT. 197 4. State Table 198 It is presented, in Table 1.1, the State Table for XMP interface 199 processing at each router involved. 201 Table 1.1 - State Table (for every Group and interface) 202 __________________________________________________________________ 203 | | Event = incoming packet (if = interface) | 204 |__________|______________________________________________________| 205 | Previous | | | | | Time-out | 206 | State | START+R | START+S | PGM+S | STOP+S | (3 min) | 207 |__________|__________|__________|___________|________|___________| 208 |if = idle | if -> R | if -> S | -- | -- | -- | 209 | |do 1,2,(3)|do 1,2,(3)| | | | 210 |__________|__________|__________|___________|________|___________| 211 |if = R | do 2,(3) | if -> S | -- | -- |delete this| 212 | | | do 2,(3) | | |if from XRT| 213 |__________|__________|__________|___________|________|___________| 214 |if = S | do 2,(3) | do 2,(3) |send packet|del XRT.| -- | 215 | | | |to every if|do 2,(3)| | 216 | | | |labeled R | | | 217 | | | | do 2,(3) | | | 218 |__________|__________|__________|___________|________|___________| 220 Notes: 221 do 1 - enter XRT with incoming if and WIAm 222 do 2 - (re)start timer for this if 223 do 3 - send packet to FP (not applicable for FP router) 224 Important - Every event not considered in the State Table should 225 result in packet discard. 227 5. Conclusion 229 This document has discussed the delivering of a multicast protocol 230 that provides bi-directionality allowing receivers, in a multicast 231 session, to become senders. The design of XMP aimed a light protocol 232 so not to pose overload on existing routers and links avoiding 233 undesirable costs to change or upgrade routers and/or increase the 234 speed of links. It was thought of, but not proposed here, two 235 additional players (the WIAm field) such as SenderPlayingReceiver and 236 ReceiverPlayingSender (the mentioned TM). In the simulation it was 237 found that XMP works well without these additional types of 238 participants. Another feature that was thought of, but not 239 implemented, was a TOKEN type packet, which would pass permission to 240 RH to become a Sender inside the XMP protocol. Again, for the sake of 241 simplicity (read few lines of code and/or small router memory and CPU 242 usage) this feature has been left for the applications to take care 243 of. Depending on the implementation of the router's IOS it might be 244 better to build a single XRT for all groups adding a column for the 245 group number. 247 6. Acknowledgements 249 We would like to thank Alexandre Falcao for his 250 valuable comments and suggestions on this document. 252 7. Informative References 254 [1] Martin W. Murhammer, et al., "TCP/IP Tutorial and Technical Overview", MAKRON Books, 2000. 256 [2] Stevens, W. Richard, "TCP/IP Illustrated - vol 1, Addison Wesley 1994. 258 [3] Estrin D., et al., Request for Comments: RFC 2117 - Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification. 260 [4] Handley M., et al, Bi-directional Protocol Independet Multicast (BIDIR-PIM), http://www.ietf.org/internet-drafts/draft-ietf-pim-bidir-05.txt. 262 8. Normative References 264 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 265 Levels", BCP 14, RFC 2119, March 1997. 267 9. Authors' Address 269 Edison de Queiroz Albuquerque 270 UNIBRATEC 271 Recife, Pernambuco, Brasil 272 Tel: +55 81 33048714 273 Email: albuquerque@ieee.org 275 10. Intellectual Property Statement 277 The IETF takes no position regarding the validity or scope of any 278 Intellectual Property Rights or other rights that might be claimed to 279 pertain to the implementation or use of the technology described in 280 this document or the extent to which any license under such rights 281 might or might not be available; nor does it represent that it has 282 made any independent effort to identify any such rights. Information 283 on the procedures with respect to rights in RFC documents can be 284 found in BCP 78 and BCP 79. 286 Copies of IPR disclosures made to the IETF Secretariat and any 287 assurances of licenses to be made available, or the result of an 288 attempt made to obtain a general license or permission for the use of 289 such proprietary rights by implementers or users of this 290 specification can be obtained from the IETF on-line IPR repository at 291 http://www.ietf.org/ipr. 293 The IETF invites any interested party to bring to its attention any 294 copyrights, patents or patent applications, or other proprietary 295 rights that may cover technology that may be required to implement 296 this standard. Please address the information to the IETF at ietf- 297 ipr@ietf.org. 299 Full Copyright Notice 301 Copyright (C) The Internet Society (2006). This document is 302 subject to the rights, licenses and restrictions contained in BCP 303 78, and except as set forth therein, the authors retain all their 304 rights. 306 This document and the information contained herein are provided 307 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 308 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 309 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 310 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 311 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 312 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 313 PARTICULAR PURPOSE.