Network Working Group Y K. ZHAO
Internet-Draft SH. Huawei Tech.
Intended status: Standards Track P. Seite
Expires: May 7, 2009 France Telecom
November 3, 2008
The Solution for Pmipv6 Multicast Service
draft-zhao-multimob-pmip6-solution-02.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 7, 2009.
ZHAO & Seite Expires May 7, 2009 [Page 1]
Internet-Draft The Solution for Pmipv6 Multicast Service November 2008
Abstract
To mobility scenario, multicast service is a valuable feature to
those mobile customers. We need to consider how to integrate current
multicast service in PMIPv6 domain. This draft will introduce this
kind of solution about proxy mobile multicast. It explains the
system consideration about how to provide the proxy mobile multicast
system.
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 the network . . . . . . . . . . . . . . 6
4.1.2. Triggered by the mobile node . . . . . . . . . . . . . 9
4.2. Proxy mobile multicast service during handover . . . . . . 11
4.2.1. Proxy mobile multicast service during normal
handover . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.2. Proxy mobile multicast service during fast handover . 12
4.3. Termination of proxy mobile multicast service . . . . . . 12
4.3.1. Terminated from network . . . . . . . . . . . . . . . 12
4.3.2. Terminated by mobile node . . . . . . . . . . . . . . 12
5. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 14
5.1. Operated as the MLDv2 Proxy . . . . . . . . . . . . . . . 14
5.2. Operated as the MLDv2 Router . . . . . . . . . . . . . . . 14
5.3. Operated as the MLDv2 listener . . . . . . . . . . . . . . 14
6. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 15
6.1. Operated as the MLDv2 Proxy . . . . . . . . . . . . . . . 15
6.2. Operated as the MLDv2 Router . . . . . . . . . . . . . . . 15
7. Mobile Node Consideration . . . . . . . . . . . . . . . . . . 16
7.1. Operation without the MLDv2 . . . . . . . . . . . . . . . 16
8. Protocol compatible considerations . . . . . . . . . . . . . . 17
8.1. Negotiation during handover . . . . . . . . . . . . . . . 17
9. Protocol consideration . . . . . . . . . . . . . . . . . . . . 18
9.1. PMIPv6 messages extension . . . . . . . . . . . . . . . . 18
9.2. Context definition during handover . . . . . . . . . . . . 18
9.3. Protocol configuration variables . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
12. Normative References . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
ZHAO & Seite Expires May 7, 2009 [Page 2]
Internet-Draft The Solution for Pmipv6 Multicast Service November 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 & Seite Expires May 7, 2009 [Page 3]
Internet-Draft The Solution for Pmipv6 Multicast Service November 2008
2. Introduction
Multicast is a very important fundamental service. It can be applied
to support many different applications, such as IPTV,MBMS etc.
Meanwhile, Proxy mobile IP is a technology used to be provided for
the hosts that don't need MIP stack installed to make mobility
management. So we need to support multicast service for hosts using
the proxy mobile IP protocol. Such as these requirements are
described in [I-D.deng-multimob-pmip6-requirement]. And in this
draft, we will continue to introduce how to meet those requirements
and make PMIPv6 supply multicast.
ZHAO & Seite Expires May 7, 2009 [Page 4]
Internet-Draft The Solution for Pmipv6 Multicast Service November 2008
3. Conventions & Terminology
Broadcast Services: It may be subscription based and the system
should support means to measuring subscriber usage for billing
purposed.
Dynamic Multicast Service: It is an kind of multicast service in
which the mobile node needs to manage the multicast group it receives
by itself. In this case, the MAG or LMA keeps track of subscribers
using the service, the service is initiated by users's request and is
terminated by the request of the mobile node or when no user is using
the service.
Static Multicast Service: It is an kind of multicast service in which
the transmission of content does not dynamically change based on the
subscriber usage and the network may or may not be aware of
subcribers' using the service at a given time.
Mobile Node: It is the ultimate terminal receives the multicast
service provided by network. But it can run the MLDv2[RFC3810] to
communicate with network or managed by network directly.
LMA: It is the standard entity defined as [RFC5213].
MAG: It is the standard entity defined as [RFC5213].
MLDv2 Listener: It is the standard entity defined as [RFC3810].
MLDv2 Proxy: It is the standard entity defined as [RFC4605].
MLDv2 Router: It is the standard entity defined as [RFC3810].
ZHAO & Seite Expires May 7, 2009 [Page 5]
Internet-Draft The Solution for Pmipv6 Multicast Service November 2008
4. Overview
To proxy mobile multicast protocol, we should reuse the existing
mature protocols related to pmip and multicast as more as we can.
And we shall keep the requirements of the mobile node as simple as we
can. So this draft keeps consistent with PMIPv6[RFC5213]. The MAG
can represent the MN to establish and maintain the multicast service
based on existing info provided by pre-configured, policy store,
context transfer or even MN's request. And the multicast service can
be terminated by MN, the MAG or the source of multicast service
itself.
4.1. Initiation of proxy mobile multicast service
The mobile multicast service in PMIPv6[RFC5213] domain can be
initiated by either network or the mobile node. When it is initiated
by the mobile node, the MN will need to run MLDv2[RFC3810] with the
MAG to triggered the MAG to start to establish the multicast service.
In another case, from those profiles or some pre-configured
materials, the MAG can just start the multicast service representing
the Mobile node in the absense of MLDv2[RFC3810] sent from the Mobile
node. But be noted that, even in this case, the mobile node still
can ask for joining some multicast groups, and the MAG should deal
with it correctly.
4.1.1. Triggered from the network
4.1.1.1. In the absence of the MLDv2
In some multicast architectures, the MAG may initiate multicast
subscription. When this happens, the MAG initiates multicast
subscription and MN sends the MLDv2[RFC3810] message to avoid the
packet to be filtered by the OS; but those MLDv2[RFC3810] message is
not sent to the network. And if implementation supports, MN can also
don't send MLDv2[RFC3810] out to ask for joining those related
multicast groups.
When the MN just attaches to a MAG, the MAG gets the MN's profile and
finds some pre-configured multicast services which need to be
established, then it will request the LMA to provide the respective
service. At this time, the methods which are used to communicate the
LMA with the MAG are either PMIP signals or MLDv2[RFC3810] report
messages etc. The LMA will check those requests and make the
decision based on its acknowledges about it. The process is as the
following:
ZHAO & Seite Expires May 7, 2009 [Page 6]
Internet-Draft The Solution for Pmipv6 Multicast Service November 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)PBA | | |
| | &Multicast joining | | |
| |---------------------->|________|__________ |
| | |6)possible multicast | |
| | 7)PBA&Multicast |authorization progress| |
| |<----------------------|''''''''''''''''''' |
| | subscription result | | |
| | | 8)Multicast joining |
| | |--------+----------->|
|9)Multicast| 9)Multicast traffic | 9)Multicast traffic |
|<----------|<----------------------|<--------------------|
Figure 1: Network-Initiated multicast service establish progress
without the MLDv2
1. The Mobile node attachs to the network.
2. The attachment of MN triggers the MAG to make network entry
progress for the MN. the MAG can contact with policy store to do
authentication and authorization for this MN as description in
PMIPv6[RFC5213].
3. Policy store returns back with those related profiles for this MN
to the MAG.
4. Based on the profile, the MAG decides if it necessary to do PMIP
Registration and join in some multicast groups specified by the
profile.
5. The MAG sends PMIPv6[RFC5213] Binding Updates and/or multicast
message (For join some multicast groups) to the LMA. Here the
ZHAO & Seite Expires May 7, 2009 [Page 7]
Internet-Draft The Solution for Pmipv6 Multicast Service November 2008
multicast message can be integrated with PMIPv6[RFC5213] Binding
Update message, or also MLDv2[RFC3810] report message etc.
6. After receiving PBU, the LMA will do as described in RFC5312 and
necessary authentication and authorization for the multicast
service of that MN.
7. After that, it returns the result of PMIPv6[RFC5213] registration
and multicast subscription. It veries depending on the specific
protocol used by the messages.
8. The MAG adds new multicast group or forwards related traffics to
the MN.
9. The multicast traffics can be forwarded to the MN.
Notes: If the requested multicast resource can't be assigned or need
to be denied, the LMA will inform the MAG via PBA (if PBU is used to
indicate multicast service), or others.
In addition, when the local routing for multicast is enabled, the MAG
should send multicast subscription directly to its near multicast
router but not the LMA. And the reverse multicast traffics can be
received by the MAG directly.
In this case, the MAG plays as a MLD proxy[RFC4605] or MLDv2[RFC3810]
listener if no any MLDv2[RFC3810] messages need to be run between the
MAG and the mobile node.
Here, we don't request the mobile node to send any MLDv2[RFC3810]
messages, but if the mobile node would like to send them, the MAG
that in MLDv2[RFC3810] proxy/router mode should process them
normally, and combine them with the profile got from policy store to
make final decision about such as subscription, joining, leaving etc.
4.1.1.2. With the MLDv2
Except the above progress, the mobile multicast service can also be
initiated from network with MLDv2[RFC3810] protocol running between
the MAG and mobile node. In this case, the MAG retrieves the
multicast services from profile store after a mobile node attach to
the PMIPv6[RFC5213] domain. And then if it finds some multicast
services need to be initiated or in the later , after triggered by
the LMA, it can just send the MLDv2[RFC3810] query message to ask if
the mobile node would like to receive some multicast services. The
message flow is as the following:
ZHAO & Seite Expires May 7, 2009 [Page 8]
Internet-Draft The Solution for Pmipv6 Multicast Service November 2008
_________ ____________
........ ....... ...... | Policy| | Multicast|
| MN | | MAG | |LMA | | Store | | Source |
`'|''' '`'|''' `'|'' `'''|''' `''''|''''
|1)Attachment | | |
|<--------->|2)Entry network authorization | |
| |------------------------------->| |
|4)MLDv2 Query<------------------------------| |
|<----------| 3)Retrieve MN's profile | |
|5)MLDv2 Report ( including multicast info) | |
|----------->................. | | |
| | 6)Based on profile | | | |
| | Decided if need to | | | |
| | Join multicast group | | | |
| `''''''''''''''''''''' | | |
| | | | |
| | 7)PBA | | |
| | &Multicast joining | | |
| |---------------------->|________|__________ |
| | |8)possible multicast | |
| | 9)PBA&Multicast |authorization progress| |
| |<----------------------|''''''''''''''''''' |
| | subscription result | | |
| | |10)Multicast joining |
| | |--------+----------->|
|11)Multicast 11)Multicast traffic |11)Multicast traffic |
|<----------|<----------------------|<--------------------|
| | | | |
Figure 2: Network-Initiated multicast service establish progress with
MLDv2
4.1.2. Triggered by the mobile node
ZHAO & Seite Expires May 7, 2009 [Page 9]
Internet-Draft The Solution for Pmipv6 Multicast Service November 2008
_________ ____________
........ ....... ...... | Policy| | Multicast|
| MN | | MAG | |LMA | | Store | | Source |
`'|''' '`'|''' `'|'' `'''|''' `''''|''''
|1)Attachment | | |
|<--------->|2)Entry network authorization | |
| |------------------------------->| |
| |<-------------------------------| |
| | 3)Retrieve MN's profile | |
|4)MLDv2 Report ( including multicast info) | |
|----------->................. | | |
| | 5)Based on profile | | | |
| | Decided if need to | | | |
| | Join multicast group | | | |
| `''''''''''''''''''''' | | |
| | | | |
| | 6)PBA | | |
| | &Multicast joining | | |
| |---------------------->|________|__________ |
| | |7)possible multicast | |
| | 8)PBA&Multicast |authorization progress| |
| |<----------------------|''''''''''''''''''' |
| | subscription result | | |
| | |9 )Multicast joining |
| | |--------+----------->|
|10)Multicast 10)Multicast traffic |10)Multicast traffic |
|<----------|<----------------------|<--------------------|
| | | | |
Figure 3: mobile node-Initiated multicast service establish progress
If the mobile node knows some multicast groups should be joined, it
will send the MLDv2[RFC3810] report to the MAG about those target
multicast groups which it wants to join in.
In addition, if the mobile node receives the MLDv2[RFC3810] query
from the MAG, it will also make response by sending the
MLDv2[RFC3810] report about those multicast groups which it wants to
get.
After receiving MLDv2[RFC3810] report which is sent from MN, the MAG
will inform the LMA/Multicast router. And before this, the MAG will
do some related authorization or authentication to check the request.
While the MAG don't inform the LMA/Multicast router about every
request from MNs, it just inform the LMA about those the ones which
are the first comers to some one multicast groups.
ZHAO & Seite Expires May 7, 2009 [Page 10]
Internet-Draft The Solution for Pmipv6 Multicast Service November 2008
4.2. Proxy mobile multicast service during handover
No matter what the initiator is (network or mobile node), both cases
have the common handover process.
4.2.1. Proxy mobile multicast service during normal handover
Generally, when there is not any optimization, the handover will
involve of MNs by running the MLDv2[RFC3810] protocol with new MAG to
receive the related on-going multicast services.
......... ............
........ ....... ,______ ...... | Policy| | Multicast|
| MN | |p-MAG| |n-MAG| |LMA | | Store | | Source |
`'|''' '`'| | '|'' `'''|''' `''''|''''
|1)Attaching to new MAG | | |
|------------------->| | | |
| | '2)Request MN's profile | |
| | +--------------+------->+ |
|4)MLDv2 query |3)Response with MN's profile |
|<-------------------|<----------------------| |
|5)MLDv2 report | (multicast info) | |
|------------------->| |
| | ,_____|____________ | | |
| | |6)Checking profile| | | |
| | |parsing multicast | | | |
| | |related info and | | | |
| | |decide multicast | | | |
| | |group management | | | |
| | |action | | | |
| | '`''''''''''''''''' | | |
| | |7)multicast | |
| | |------------->| 8)multicast group |
| | | subscription|<===================>|
| | |9)multicast | management |
| | |<-------------| | |
| | | subscription response | |
| | | | | |
Figure 4: Proxy mobile multicast service during normal handover
ZHAO & Seite Expires May 7, 2009 [Page 11]
Internet-Draft The Solution for Pmipv6 Multicast Service November 2008
4.2.2. Proxy mobile multicast service during fast handover
But, for performance consideration, the method of context transfer is
expected to provide necessary multicast information during handover
progress. And if it is necessary, a 3-rd party policy store is
required to be used to provide necessary information no matter
whether context transfer will be used or not.
......... ............
........ ,______ ...... | Policy| | Multicast|
|p-MAG | |n-MAG| |LMA | | Store | | Source |
`'|''' | '|'' `'''|''' `''''|''''
1)handover event | | |
|2)handover request | | | |
|------------------->'3)Request MN's profile | |
| (multicast info.) +--------------+------->+ |
| |4)Response with MN's profile |
| |<----------------------| |
| | (multicast info) | |
| | | | |
| |5)multicast | |
| |------------->| 6)multicast group |
| | subscription|<===================>|
| |7)multicast | management |
| |<-------------| | |
|5)handover response | subscription respone | |
|<------------------ | | | |
Figure 5: Proxy mobile multicast service during fast handover
4.3. Termination of proxy mobile multicast service
4.3.1. Terminated from network
When it is the time to get to the end of some on-going multicast
services or no any mobile node are receiving it, or for some other
reasons, the MAG can decide to terminate those multicast services no
matter whether the multicast source works or not. On this occasion,
the MAG will inform the LMA/multicast router about this event.
4.3.2. Terminated by mobile node
The Mobile Node sends MLDv2[RFC3810] done message to the MAG and
inform the MAG that it will never receive them again. Upon receipt
this information the MAG will do necessary verification for
ZHAO & Seite Expires May 7, 2009 [Page 12]
Internet-Draft The Solution for Pmipv6 Multicast Service November 2008
authorization or authentication, then stop sending those multicast
services to MN again. Accordingly, if no one receiver of a/some
multicast service under the MAG, it can inform the LMA about this
event.
ZHAO & Seite Expires May 7, 2009 [Page 13]
Internet-Draft The Solution for Pmipv6 Multicast Service November 2008
5. Mobile Access Gateway Operation
For the MAG, whether the MN will run MLDv2[RFC3810] protocol or not
is all right. The MAG should have the capability to interact with
the MN via the MLDv2[RFC3810] messages. And there is no need to ask
the MN to send the MLDv2[RFC3810] message to initiate or stop a
multicast service. The MAG can get related multicast information of
the MN from policy stores etc., to initiate or terminate a multicast
service.
Meanwhile, the MAG can disable all timers listening to MLDv2[RFC3810]
query sent to the MN. As to the problem when the multicast should be
ended, it depends on related network policy and MN's interest. And
the termination of multicast can be triggered by both of network and
MN.
5.1. Operated as the MLDv2 Proxy
For route optimization reason, the MAG should have the ability to
join a Multicast group without the bi-direction tunnel between the
MAG and LMA. This can be based on a pre-configured configuration or
MN's profile or a interaction between the MAG and LMA. To reduce the
heavy load to implement the multicast router on a MAG, one
MLDv2[RFC3810] listener is enough to that MAG.
5.2. Operated as the MLDv2 Router
For route optimization reason, the MAG should have the ability to
join a Multicast group without the bi-direction tunnel between the
MAG and LMA. This can be based on a pre-configured configuration or
MN's profile or an interaction between the MAG and LMA. To reduce
the heavy load to implement the multicast router on a MAG, one MLDv2
listener is enough to that MAG.
5.3. Operated as the MLDv2 listener
If network decides that MAG doesn't deal with MLDv2[RFC3810] protocol
in the interface to the mobile node, the MAG can just be operated as
a MLDv2[RFC3810] listener. The MAG will collect those multicast
related information about those mobile nodes under it, and base on
the policies defined by network to make mobility multicast management
for the mobile node. The protocol between the MAG and upper level
multicast entity should be MLDv2[RFC3810] protocol. And that
multicast entity can be either the LMA or a standalone multicast
router. If the LMA become the multicast entity that MAG must face to
communicate with, then the PMIPv6[RFC5213] protocol can also be used
to achieve the goal.
ZHAO & Seite Expires May 7, 2009 [Page 14]
Internet-Draft The Solution for Pmipv6 Multicast Service November 2008
6. Local Mobility Anchor Operation
6.1. Operated as the MLDv2 Proxy
In PMIPv6[RFC5213], every MAG and LMA will own a bi-direction tunnel.
There are only these two nodes on this tunnel. Meanwhile, the PBUs/
PBAs are applicable for multicast group management. In addition,
since the tunnel between the MAG and LMA can be multicast capable,
MLDv2[RFC3810] can also be run in that tunnel. To one multicast
group, the MAG can only join once to the LMA, it will save a large
signal consumption and multicast traffics to avoid making the tunnel
to be involved in the neck phenomenon.
A MLDv2 proxy[RFC4605] can simplify the implementation of the LMA.
At this point, it is a valuable choice as well. The benefit is
similar to the description of MLDv2 proxy[RFC4605] on the MAG.
To query those MAGs which are connected to a LMA, the LMA which is
acting as an MLDv2 proxy[RFC3810] can use MLDv2[RFC3810] Query
messages or PBAs (Need some extensions) to inform the MAGs. And
then, if the LMA receives MLDv2[RFC3810] Report messages or PBUs
(Also need some extensions) from MAGs, it will forward or send
MLDv2[RFC3810] Report messages to the multicast router it has
connected with by using it's link-local address. That belongs to
current regular multicast domain.
As a MLDv2 proxy[RFC3810], the LMA needs to configure its upstream
and downstream interfaces statistically. As to downstream, it is
connected to those MAGs and for upstream. Since, there are some many
different prefixes on the LMA, it can select one or several
interfaces owned by respective prefixes as the multicast listener
interface faces upstream.
6.2. Operated as the MLDv2 Router
TBD.
ZHAO & Seite Expires May 7, 2009 [Page 15]
Internet-Draft The Solution for Pmipv6 Multicast Service November 2008
7. Mobile Node Consideration
7.1. Operation without the MLDv2
After all, the MLDv2[RFC3810] protocol needs hosts to support and the
cost of MLDv2[RFC3810] protocol over air-interface is existed. In
addition, the network has such information can be referred in pmip
domain. The MAG can establish and maintain the proxy mobile
multicast service to represent the MN. So the MN can just keep
listening the multicast traffics without sending any explicit
messages to the MAG to manage the multicast services.
It should be noted that, even if the MLDv2[RFC3810] 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 a specified one.
If no such operation, the host must receive all multicast datas with
promiscuous mode, which is worst and not willing to any host. To
make the system available in this kind of worst situation, unicast
can be used between the MAG and mobile node to transfer those
specified multicast traffics. the MAG can just play as a
MLDv2[RFC3810] listener. After receiving those multicast traffics,
the MAG can encapsulate them destined to the mobile node directly.
As to detail port will be used, it will be provided as the part of
the profile the MAG has just found. Because, currently p2p link is
specified to PMIPv6[RFC5213]. So multicast or unicast between the
MAG and the mobile node will not bring any additional cost to it.
Note: Here the static multicast services can be used and the service
is pre-configured. No any substantial large change after signing
those services with operators or the deployment of them in network
side. Meanwhile, some layer-2 mechanism or custom-specific protocols
can be used to help the multicast group management for the mobile
node when dynamic multicast service is expected to this architecture.
In this case, the MAG doesn't need to run the MLDv2[RFC3810] protocol
with the mobile node.
ZHAO & Seite Expires May 7, 2009 [Page 16]
Internet-Draft The Solution for Pmipv6 Multicast Service November 2008
8. Protocol compatible considerations
By the introduction of the different roles of the MAG and the LMA,
the co-ordination between the different type of the p-MAG and the
n-MAG is a requirement. But, of course, we can pre-defined or advice
to operators to only deploy one type of function (MLDv2
proxy[RFC3810]/MLDv2 router etc) inside of the MAG or LMA. That can
make both protocol and PMIPv6[RFC5213] domain as simple as possible.
Upon this assumption, a negotiation will be needed. Here we can
utilize context transfer or policy store. And a dual-mode MAG will
be required to be operated in different method.
8.1. Negotiation during handover
TBD.
ZHAO & Seite Expires May 7, 2009 [Page 17]
Internet-Draft The Solution for Pmipv6 Multicast Service November 2008
9. Protocol consideration
This part describes those extensions or definitions to current
PMIPv6[RFC5213] protocol, or context transfer progress.
9.1. PMIPv6 messages extension
Once PMIPv6[RFC5213] is used as the pmip multicast management method
between the MAG and the LMA, then it will be needed to be extended to
support the transfer or negotiation of those multicast related
information.
9.2. Context definition during handover
Although, whether the protocol will be used in PMIPv6[RFC5213] domain
or not is not clearly by far. And practice system have some their
specific methods to do that. But it is the same what should be
transferred during context transfer progress. Once that context
transfer protocol is certain, this part of work can be referred
together.
9.3. Protocol configuration variables
TBD.
ZHAO & Seite Expires May 7, 2009 [Page 18]
Internet-Draft The Solution for Pmipv6 Multicast Service November 2008
10. Security Considerations
To pmip multicast service, we should base on current pmip security
consideration and multicast security mechanism. To detail, it is
TBD.
ZHAO & Seite Expires May 7, 2009 [Page 19]
Internet-Draft The Solution for Pmipv6 Multicast Service November 2008
11. Acknowledgements
The author would like to acknowledge the assistance of Pierrick
Seite, Hitoshi Asaeda and Jinwei Xia in writing this draft, and also
the input on specific implementations from others.
ZHAO & Seite Expires May 7, 2009 [Page 20]
Internet-Draft The Solution for Pmipv6 Multicast Service November 2008
12. Normative References
[I-D.deng-multimob-pmip6-requirement]
Deng, H., Schmidt, T., Seite, P., and P. Yang, "Multicast
Support Requirements for Proxy Mobile IPv6",
draft-deng-multimob-pmip6-requirement-01 (work in
progress), October 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
ZHAO & Seite Expires May 7, 2009 [Page 21]
Internet-Draft The Solution for Pmipv6 Multicast Service November 2008
Authors' Addresses
Yuan Kui.ZHAO
Shanghai Huawei Technology
Qian Chang Building
No.450,Jin Yu Road,
Shanghai 201206
P.R.C
Phone: +86 21 28920578
Email: john.zhao@huawei.com
URI: http://www.huawei.com/
Pierrick Seite
France Telecom
4, rue du Clos Courtel
BP 91226,
Cesson-Sevigne 35512
France
Email: pierrick.seite@orange-ftgroup.com
ZHAO & Seite Expires May 7, 2009 [Page 22]
Internet-Draft The Solution for Pmipv6 Multicast Service November 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 & Seite Expires May 7, 2009 [Page 23]