idnits 2.17.1 draft-sijeon-mext-dmm-mc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 24, 2011) is 4565 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- == Missing Reference: 'RFC 4605' is mentioned on line 88, but not defined == Unused Reference: 'RFC2119' is defined on line 233, but no explicit reference was found in the text == Unused Reference: 'RFC5213' is defined on line 236, but no explicit reference was found in the text == Unused Reference: 'RFC4605' is defined on line 239, but no explicit reference was found in the text == Unused Reference: 'RFC6424' is defined on line 244, but no explicit reference was found in the text == Unused Reference: 'RFC3810' is defined on line 248, but no explicit reference was found in the text == Unused Reference: 'I-D.chan-distributed-mobility-ps' is defined on line 253, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6424 (Obsoleted by RFC 8029) Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network working group Seil Jeon 2 Internet Draft Younghan Kim 3 Intended status: Informational Track Soongsil University 4 Expires: April 23, 2012 October 24, 2011 6 Multicast services support for distributed mobility architecture 7 draft-sijeon-mext-dmm-mc-00.txt 9 Abstract 11 IP multicasting is expected to become essential technique for mobile 12 video services. As the mobility management is being covered with 13 distributed manner, corresponding IP multicasting is also required to 14 fit the distributed manner. This document specifies IP multicasting 15 support method and procedures for distributed mobility architecture. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 23, 2012. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction ................................................ 2 52 2. Terminology ................................................. 3 53 3. Overview .................................................... 3 54 4. Protocol operation .......................................... 4 55 4.1. Initial attach ......................................... 4 56 4.2. Handover ............................................... 5 57 5. Security Considerations ..................................... 6 58 6. IANA Considerations ......................................... 6 59 7. References .................................................. 6 60 7.1. Normative References ................................... 6 61 7.2. Informative References ................................. 7 63 1. Introduction 65 As mobile traffic greatly increases, the distributed mobility 66 management (DMM) is highly being in the spotlight as a next- 67 generation mobility solution. 69 IP multicasting is essential technique to facilitate real-time 70 streaming services e.g. mobile IPTV, hence it should also be 71 available under the DMM. 73 Anchor node in DMM becomes changed for the mobile nodes (MNs) 74 whenever they are moving towards another access router, while the 75 anchor node is dedicated in centralized mobility management. This 76 difference should be reflected for designing IP multicast into DMM. 77 In other words, which router should provide multicast stream to 78 anchor node the MN currently attach to e.g. multicast router or 79 previous anchor node and who does decide. 81 In this document, we offer basic multicast support method in 82 distributed mobility management by using mobility information server 83 managing multicast channel for each anchor node. 85 2. Terminology 87 o MMAA (Mobility Anchor and Access Agent): access router to which a 88 mobile node connects. MLD proxy function defined in [RFC 4605] is 89 operated on the MMAA. 91 o MIS (Mobility Information Server): it stores the information of an 92 MN at which is attached and what channel it is receiving if the MN 93 gets IP multicasting serviced. The MMIS has a decision engine for 94 each MMAA to support efficient multicast traffic delivery. 96 o MTD (Multicast Traffic Distributor): for receiving multicast data, 97 each MMAA should be connected to the one among a multicast router or 98 a MMAA depending on the decision of MMIS. 100 o Proxy Channel Registration (PCR): it is transmitted to the MMIS by 101 a MMAA and used to report multicast information on the MMAA in use. 102 Specifically, it is {channel, multicast traffic distributor 103 connected}. 105 o Proxy Channel Acknowledgement (PCA): it is transmitted to the MMAA 106 by the MMIS and used to. 108 3. Overview 110 +------+ 111 | MTD | 112 +------+ 113 | 114 ******************** 115 +----+ * * 116 |MIS |-----* Fixed Internet * 117 +----+ * * 118 ******************** 119 | | 120 +----+ +----+ 121 |MMAA| |MMAA| 122 +----+ +----+ 124 Figure 1 Proposed architecture for DMM multicast 126 To support IP multicasting in DMM, all MMAAs are required to have MLD 127 proxy function so they need to connect to multicast traffic 128 distributor (MTD) defined in this document. The MTD may be multicast 129 router (MR) or the multicast source directly. In the case of mobile 130 node (MN)'s handoff, the MMAA where the MN attach connects to the MR 131 or previous MMAA using tunneling mechanism for seamless multicast 132 handoff. DMM multicasting requires the method how and where current 133 MMAA will retrieve multicast stream from. 135 4. Protocol operation 137 4.1. Initial attach 139 MN MMAA MIS MTD 140 | | | | 141 | MN attach | | 142 | | | | 143 | |----- PBU ---->| | 144 | | | | 145 | |<---- PBA -----| | 146 | | | | 147 | | | | 148 |<-MLD Query---| | | 149 | | | | 150 |--MLD Report->| | | 151 | | | | 152 | |-----Aggregated MLD Report--->| 153 | | | | 154 | | | | 155 | |--- PC Req.--->| | 156 | |{"G1",MTD-Addr}| | 157 | | | | 158 | |<---PC Ack.----| | 159 | |{"G1",MTD-Addr}| | 160 | | | | 162 Figure 2 Initial attach 164 Once MMAA detect MN's attachment, it transmits PBU message on behalf 165 of the MN to MIS that manages all the MN's information. The MIS sends 166 back PBA message to current MMAA. The MMAA sends General MLD Query to 167 the MN. The MN transmits MLD Report message to the MMAA. Then, the 168 MMAA sends aggregated MLD Report to the MTD. If the MMAA has no 169 multicast listener, the MTD is MR or content source natively. After 170 the MMAA starts multicast services, it SHOULD register and report its 171 service status including what kind of channel is serviced and its 172 corresponding MTD address to the MIS. 174 4.2. Handover 176 MMAA1 MIS MMAA2 MR MN 177 | | | | | 178 | | | | | 179 |<--BCE Update---|<---- PBU -----| | | 180 | Reg. | | | | 181 | | | | | 182 |---BCE Update-->|----- PBA ---->| | | 183 | Ack. |{"G1",MTD-Addr}| | | 184 | | | | | 185 | | | | | 186 | | |-------- MLD Query --------->| 187 | | | | | 188 | | |<------- MLD Report----------| 189 | | | | | 190 | | |--Aggregated->| | 191 | | | MLD Report | | 192 | | | | | 193 | |<-- PC Reg.----| | | 194 | |{"G1",MTD-Addr}| | | 195 | | | | | 196 | |--- PC Ack.--->| | | 197 | |{"G1",MTD-Addr}| | | 198 | | | | | 199 Figure 3 Handoff procedure 201 Once the MN moves to MMAA2 from MMAA1, the MMAA2 transmits PBU 202 message to the MIS. The MIS knowing previous MMAA where the MN stayed 203 makes the MMAA1's BCE updated and gets multicast information the MN 204 listened. Through the interaction between the MIS and MMAA1, the MIS 205 transmits PBA message including channel information "G1" and 206 corresponding MTD address to the MMAA2. Figure 3 assumed that there 207 are no multicast listeners in MMAA2 for same multicast group "G1" 208 before MN's arrival. So, the MTD for the MN is MR. Through the 209 interaction of MLD Query/Report message, the MMAA2 sends aggregated 210 MLD Report message to the MR. If there is a multicast listener for 211 group "G1", the MIS will give existing MTD address in use to the 212 MMAA2 to avoid duplicated multicast traffic. This decision is made on 213 the MIS. If the MTD determined by the MIS is the MMAA1, the MMAA2 214 establishes the tunnel with the MMAA1 to retrieve multicast data. 216 After the MMAA2 joins multicast channel complete by sending 217 aggregated MLD Report, it registers current multicast channel 218 serviced currently to the MIS with proxy channel registration (PCR) 219 message. Then, it receives proxy channel acknowledgment (PCA) message. 221 5. Security Considerations 223 TBD. 225 6. IANA Considerations 227 TBD. 229 7. References 231 7.1. Normative References 233 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 234 Requirement Levels", BCP 14, RFC 2119, March 1997. 236 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 237 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 239 [RFC4605] B. Fenner, H. He, B. Haberman, and H. Sandick, "Internet 240 Group Management Protocol (IGMP) / Multicast Listener 241 Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD 242 Proxying")", IETF RFC 4605, August 2006. 244 [RFC6424] T. Schmidt, M. Waehlisch, and S. Krishnan, "Base Deployment 245 for Multicast Listener Support in PMIPv6 Domains", IETF RFC 246 6424, April 2011. 248 [RFC3810] R. Vida and L. Costa, "Multicast Listener Discovery Version 249 2 (MLDv2) for IPv6", RFC 3810, June 2004. 251 7.2. Informative References 253 [I-D.chan-distributed-mobility-ps] 255 A. Chan, "Problem statement for distributed and dynamic 256 mobility management", draft-chan-distributed-mobility-ps-03 257 (work in progress), July 2011. 259 Authors' Addresses 261 Seil Jeon 262 Soongsil University 263 Email: sijeon@dcn.ssu.ac.kr 264 URI: http://sites.google.com/site/seiljeon 266 Younghan Kim 267 Soongsil University 268 Email: younghak@ssu.ac.kr