One document matched: draft-zhao-multimob-pmip6-solution-00.txt
Network Working Group Y. ZHAO(Editors)
Internet-Draft SH. Huawei Tech.
Intended status: Standards Track October 28, 2008
Expires: May 1, 2009
The solution for pmip multicast service
draft-zhao-multimob-pmip6-solution-00.txt
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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 1, 2009.
ZHAO(Editors) Expires May 1, 2009 [Page 1]
Internet-Draft The solution for pmip multicast service October 2008
Abstract
An example.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Conventions & Terminology . . . . . . . . . . . . . . . . . . 5
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Initiation of proxy mobile multicast service . . . . . . . 6
4.1.1. Triggered from network . . . . . . . . . . . . . . . . 6
4.1.2. Triggered by mobile node . . . . . . . . . . . . . . . 7
4.2. proxy mobile multicast service during handover . . . . . . 8
4.3. Termination of proxy mobile multicast service . . . . . . 8
4.3.1. Terminated from network . . . . . . . . . . . . . . . 8
4.3.2. Terminated by mobile node . . . . . . . . . . . . . . 8
5. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 9
5.1. Operated as MLD Proxy . . . . . . . . . . . . . . . . . . 9
5.2. Operated as MLD Router . . . . . . . . . . . . . . . . . . 9
5.3. Operated as MLD listener . . . . . . . . . . . . . . . . . 9
6. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 10
6.1. Operated as MLD Proxy . . . . . . . . . . . . . . . . . . 10
6.2. Operated as MLD Router . . . . . . . . . . . . . . . . . . 10
7. Mobile Node Consideration . . . . . . . . . . . . . . . . . . 11
7.1. Operation without MLD . . . . . . . . . . . . . . . . . . 11
8. Protocol compitable considerations . . . . . . . . . . . . . . 12
8.1. negotiation during handover . . . . . . . . . . . . . . . 12
9. Context definition during handover . . . . . . . . . . . . . . 13
10. Protocol configuration variables . . . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . . 15
12. Normative References . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
ZHAO(Editors) Expires May 1, 2009 [Page 2]
Internet-Draft The solution for pmip multicast service October 2008
1. Requirements notation
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 [RFC2119].
ZHAO(Editors) Expires May 1, 2009 [Page 3]
Internet-Draft The solution for pmip multicast service October 2008
2. Introduction
Multicast is a very important fundamention service. It can be
applied to support so many difference applications, such as IPTV,MBMS
etc.Meanwhile,Proxy mobile IP is a technology to be provided to those
hosts that didn't need MIP to do mobility management by network.So
how to support multicast service for hosts used the proxy mobile IP
protocol is needed to be designed and definitioned.
draft-deng-multimob-pmip6-requirement-01.txt has discussed this kind
of requirement. In this draft, we will discuss how to meet those
requirement and make the hosts with pmip protocol to support
multicast.
ZHAO(Editors) Expires May 1, 2009 [Page 4]
Internet-Draft The solution for pmip multicast service October 2008
3. Conventions & Terminology
TBD.
ZHAO(Editors) Expires May 1, 2009 [Page 5]
Internet-Draft The solution for pmip multicast service October 2008
4. Overview
To proxy mobile multicast protocol, we need to re-use those current
existed mature protocols related to pmip and multicast as more as
possible. And keep the requirement of mobile node as simple as
possible. In this direction, it need to keep consistent with
RFC5213. The MAG can represent the MN to establish and maintenance
the multicast service based on existed info provided by pre-config ,
policy store, context transfer or even MN's request.And the multicast
service can be terminated by MN,network policy or multicast service
it self.
4.1. Initiation of proxy mobile multicast service
The mobile multicast service in proxy mobile IP domain can be
initiated by both of network and mobile node. They have the common
handover process. When it is initiated from mobile node, the MN will
need to send IGMP/MLD to triggered MAG to start to establish the
multicast service,Meanwhile, from those profile infomation or some
pre-configured materials , MAG can just start the multicast service
represent that Mobile node without the need of IGMP/MLD sent from
Mobile node. Becarefully, even in this case, Mobile node still can
ask for join some multicast group, it is no any impact on that.
4.1.1. Triggered from network
In some multicast architecture, the MAG may initiate multicast
subscription.In that case,the MAG will initiates multicast
subscription and MN just sends IGMP to avoid the packet to be
filtered by the OS; but IGMP is not sent to the network. And if
implementation support,MN can also didn't send MLD out to ask for
join those related multicast group.
When the MN just attachs to a MAG, the MAG gets the MN's profile and
knows some pre-configured multicast services need to be established,
then it will request the LMA to provide the respective service, in
this case, the method used to communicate to LMA from MAG can be
either PMIP signals or MLD report(join) messages etc. LMA will check
about this request and do the decision based on it's acknowledges
about it. The progress as the following:
ZHAO(Editors) Expires May 1, 2009 [Page 6]
Internet-Draft The solution for pmip multicast service October 2008
_________ ____________
........ ....... ...... | Policy| | Multicast|
| MN | | MAG | |LMA | | Store | | Source |
`'|''' '`'|''' `'|'' `'''|''' `''''|''''
|1)Attachment | | |
|<--------->|2)Entry network authorization | |
| |------------------------------->| |
| |<-------------------------------| |
| | 3)Retrieve MN's profile | |
| | ( including multicast info) | |
| ........................ | | |
| | 4)Based on profile | | | |
| | Decided if need to | | | |
| | Join multicast group | | | |
| `''''''''''''''''''''' | | |
| | | | |
| | 5)PMIP Registration | | |
| | &Multicast joining | | |
| |---------------------->|________|__________ |
| | |6)possible multicast | |
| | |authorization progress| |
| | '`'''''''''''''''''''''' |
| | | | |
| | | 7)Multicast joining |
| | |--------+----------->|
|8)Multicast| 8)Multicast traffic | 8)Multicast traffic |
|<----------|<----------------------|<--------------------|
| | | | |
Figure 1: Network-Initiated multicast service establish progress
4.1.2. Triggered by mobile node
If the mobile node knows some multicast groups should be joined , it
can send MLD report to MAG about those target multicast groups it
want to join in.
In addition, if the mobile node has just received the MLD query from
MAG, it can also response to it by MLD report including those
multicast groups it want to receive.
After receiving MLD report sent from MN,MAG will inform this to LMA/
Multicast router. But before that, MAG will do some related
authorization or authentication to check about this request.
Meanwhile,MAG didn't need to inform LMA/Multicast router about every
request from MNs, it just inform LMA about those the firstest comer
ZHAO(Editors) Expires May 1, 2009 [Page 7]
Internet-Draft The solution for pmip multicast service October 2008
to some one multicast group.
4.2. proxy mobile multicast service during handover
Generally,without any optimization,the handover will need the
involved of MNs by sending MLD report to inform new MAG about those
multicast services they want to receive.
But,for performance consideration,the CXT is expect to provide
necessary multicast infomation during handover progress. And if
needed, a 3-rd party policy store is required to be used to provide
necessary information whenever CXT will be used or not.
4.3. Termination of proxy mobile multicast service
4.3.1. Terminated from network
When the schedule of some on-going multicast service is to the
end,then the MAG can terminate to send those traffic to MNs whatever
the multicast source is work or not.If no receiver of a multicast
service under a MAG is existed, it will inform LMA about this event
by related signals depend on which one is selected by LMA, for
example, PBU/PBA,MLD leave message etc.
4.3.2. Terminated by mobile node
Mobile Node will send MLD leave message to inform MAG about the
termination of a/some multicast service if he won't receive that
service.After receiving that and finishing some necessary checkings
for authorization or authentication , MAG will end to send that/those
multicast services to MN again. Respectly, if no one receiver of
a/some multicast service under the MAG will be existed,MAG can inform
LMA about this event by related signals depend on which one is
selected by LMA, for example, PBU/PBA,MLD leave message etc.
ZHAO(Editors) Expires May 1, 2009 [Page 8]
Internet-Draft The solution for pmip multicast service October 2008
5. Mobile Access Gateway Operation
To MAG, whether MN will run MLD protocol is not the key. MAG should
have the ability to interact with MN via MLD messages.And it also
didn't need to ask MN must to send the MLD message for initiate or
end a multicast service.Respectively, MAG can get related multicast
infomation for particular MN from such as policy store, to initiate
or terminate a multicast service.
Meanwhile,MAG can disable all timers listening for MLD query if it
has sent to MN.As to when the multicast should be ended, that will
depend on related network policy and MN's interesting,and can be
triggered from both of network and MN.
5.1. Operated as MLD Proxy
TBD.
5.2. Operated as MLD Router
TBD.
5.3. Operated as MLD listener
For route optimization reason, MAG should have the ability to join a
Multicast group without the bi-direction tunnel between MAG and
LMA.This can based a pre-configured configuration or MN's profile or
a interaction between MAG and LMA. But difference the possible
multicast router in current design, the MAG no need so heavy
implement to support it. A MLD listener is enough.
ZHAO(Editors) Expires May 1, 2009 [Page 9]
Internet-Draft The solution for pmip multicast service October 2008
6. Local Mobility Anchor Operation
6.1. Operated as MLD Proxy
In pmipv6,every MAG and LMA will own a bi-direction tunnel. There
are only these two nodes on this tunnel. Meanwhile, there are PBUs/
PBAs are applicable for multicast group management. In addition,
since the tunnel between MAG and LMA can be multicast capable,IGMP/
MLD can also be run in that tunnel.To one multicast group, MAG can
only join once to LMA,it will save a lagre signal consumtion and
including following multicast traffics invoide to make the tunnel to
be involved the neck phenomenon.
A MLD proxy can simplify the implementation of LMA, so that is a
valued choice as well.The benefit is similiar to the description of
MLD proxy located on MAG.
To query those MAGs connected to a LMA,the LMA acting as an MLD proxy
can use MLD Query messages or PBAs(Need some extensions) to inform
those MAGs.After that, if LMA receives MLD Report messages or
PBUs(Also need some extensions) from MAGs,it will forwards or send
MLD Report messages to the multicast router it has connected with
using it's link-local address. That is belong to current regular
multicast domain.
As a MLD proxy, LMA need configure its upstream and downstream
interfaces statistically.To downstream , it is connected those MAGs
and to upstream , it is suggested a multicast router or maybe the
multicast source is dedicated. Since, there are some many difference
prefixes located LMA,it can select only one or several interfaces
owned for respective prefixes as the multicast listener interface
face to upstream.
6.2. Operated as MLD Router
TBD.
ZHAO(Editors) Expires May 1, 2009 [Page 10]
Internet-Draft The solution for pmip multicast service October 2008
7. Mobile Node Consideration
7.1. Operation without MLD
After all, the MLD protocol need host to support and the
transfermation of MLD protocol over air-interface will cost another
consumetion. In addition, the network have so many infomation can be
referenced in some cases in pmip domian. MAG can establish and
maintenance the proxy mobile multicast service represent the MN. So
MN can just keep listening about the multicast traffic without send
any expicite messages to MAG to manage the multicast service.
It should be noted that, even if MLD report is not expected to be
sent to the MAG many kernel implementation requires host's
application to create/add joined multicast group membership structure
inside its kernel and open device driver to capture the data whose IP
multicast address is the specified one.
If no such operation, the host must receive all multicast data with
promiscuous mode, which is worst and not willing to any host.
To this case, one hand,this mode is applicable to those hosts that
didn't support MLD protocol.In addition, to those support MLD hosts
it will rely on the management of MAG. Since the link mode is p2p
link. the MN is only connected to MAG on like. So it require the MAG
just control to send which kind of multicast services and send what
to this mobile node. In another hand, to p2p link, what will be the
promiscuous mode? Since all of data need to be received by hosts,
and MAG just kick off those service that not related to that MN.So,it
will be not worst in pmip case.
ZHAO(Editors) Expires May 1, 2009 [Page 11]
Internet-Draft The solution for pmip multicast service October 2008
8. Protocol compitable considerations
By the introduction of difference roles of MAG and LMA, the co-
ordination between the differentiate type of p-MAG and n-MAG is a
requirement. But, of course, we can pre-defined or advice to
operators to only deploy one type of function (MLD Proxy/MLD Router
etc) inside of MAG or LMA. That can make both of this protocol and
PMIPv6 domain as simple as possible. If we can make this assumtion,
then a negotiation will be needed. Here we can utilize CXT or policy
store to do this. And a dual-mode MAG will be required to be
operated in different method.
8.1. negotiation during handover
TBD.
ZHAO(Editors) Expires May 1, 2009 [Page 12]
Internet-Draft The solution for pmip multicast service October 2008
9. Context definition during handover
ZHAO(Editors) Expires May 1, 2009 [Page 13]
Internet-Draft The solution for pmip multicast service October 2008
10. Protocol configuration variables
ZHAO(Editors) Expires May 1, 2009 [Page 14]
Internet-Draft The solution for pmip multicast service October 2008
11. Security Considerations
To pmip multicast service, we should based on current pmip security
consideration and multicast security mechanism. To detail,it is TBD.
ZHAO(Editors) Expires May 1, 2009 [Page 15]
Internet-Draft The solution for pmip multicast service October 2008
12. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
ZHAO(Editors) Expires May 1, 2009 [Page 16]
Internet-Draft The solution for pmip multicast service October 2008
Author's Address
Yuan Kui.ZHAO
Shanghai Huawei Technology
Qian Chang Building
No.450,Jin Yu Road,
Shanghai, Shanghai 201206
P.R.C
Phone: +86 21 28920578
Email: john.zhao@huawei.com
URI: http://www.huawei.com/
ZHAO(Editors) Expires May 1, 2009 [Page 17]
Internet-Draft The solution for pmip multicast service October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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.
Intellectual Property
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.
ZHAO(Editors) Expires May 1, 2009 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-24 02:46:04 |