Internet DRAFT - draft-liu-multimob-pmipv6-multicast-ro
draft-liu-multimob-pmipv6-multicast-ro
MULTIMOB Working Group J. Liu
Internet-Draft W. Luo
Intended status: Standards Track ZTE Corporation
Expires: January 31, 2013 July 30, 2012
Routes Optimization for Multicast Sender in Proxy Mobile IPv6 Domain
draft-liu-multimob-pmipv6-multicast-ro-02
Abstract
To support IP multicasting in PMIPv6 domain, MULTIMOB WG has issued
several proposals including the base solution, dedicated schemes and
direct routing which requires all communications to go through the
local mobility anchor(LMA), the dedicated server and the native
multicasting infrastructure, respectively. As this can be
suboptimal, this document describes multicast routes optimazition
mechanisms for multicast sender. Multicast sender attached to the
same or different mobile access gateways(MAG) with multicast listener
sends multicast data via the tunnel between the gateways without any
dedicated devices or dependence of the native multicasting
infrastructure. The MAG and the LMA are the mobility entities
defined in the PMIPv6 protocol and act as PIM-SM routers.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 31, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Liu & Luo Expires January 31, 2013 [Page 1]
Internet-Draft RO for Multicast Sender July 2012
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Add Route to MRIB . . . . . . . . . . . . . . . . . . . . 6
4.2. Optimized Multicast Route Establishment . . . . . . . . . 6
4.3. Multicast Route Deletion . . . . . . . . . . . . . . . . . 8
4.4. Multicast sender handover . . . . . . . . . . . . . . . . 10
4.5. Multicast listener handover . . . . . . . . . . . . . . . 10
4.6. ASM Scecario . . . . . . . . . . . . . . . . . . . . . . . 10
5. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 10
6. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 11
6.1. MN1 and MN2 attach to the same MAG . . . . . . . . . . . . 11
6.2. MN1 and MN2 attach to different MAG . . . . . . . . . . . 11
7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 12
8. Message Format Extension . . . . . . . . . . . . . . . . . . . 12
8.1. Proxy Binding Update with Source Address Query
Extension . . . . . . . . . . . . . . . . . . . . . . . . 12
8.2. Proxy Binding Acknowledgement Message with Source
Address Query Extension . . . . . . . . . . . . . . . . . 13
8.3. Care-of Address Option . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. Normative References . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Liu & Luo Expires January 31, 2013 [Page 2]
Internet-Draft RO for Multicast Sender July 2012
1. Introduction
Proxy Mobile IPv6 (PMIPv6) [RFC5213] enables network-based mobility
for IPv6 mobile nodes (MNs) that do not implement any mobility
protocols. The Local Mobility Anchor (LMA) is the topological anchor
point to manages the mobile node's binding state. The Mobile Access
Gateway (MAG) is an access router or gateway that manages the
mobility-related signaling for an MN. An MN is attached to the Proxy
Mobile IPv6 Domain (PMIPv6-Domain) that includes LMA and MAG(s), and
is able to receive data coming from outside of the PMIPv6-Domain
through LMA and MAG.
Network-based mobility support for unicast is addressed in [RFC5213],
while multicast support in PMIPv6 is not discussed in it. In order
to deploy the multicast service in the PMIPv6 domain, many schemes
have been proposed:
The base solution described in [RFC6224] provides options for
deploying multicast listener functions in PMIPv6-Domains without
modifying mobility and multicast protocol standards. However, in
this specification, MAG MUST act as an MLD proxy [RFC4605] and hence
MUST dedicate a tunnel link between LMA and MAG to an upstream
interface for all multicast traffic. It requires all the LMA to
forward multicast packets to MAG via PMIPv6 tunnel which can be
suboptimal.
[draft-ietf-multimob-pmipv6-ropt-00]uses a multicast tree mobility
anchor(MTMA) as the topological anchor point for multicast traffic,
as well as a direct routing option where the MAG can provide access
to multicast content in the local network. All the multicast traffic
has to go through the MAG-MTMA tunnel which result in suboptimal
multicast routing path like the base solution. And the direct
routing solution needs native multicasting infrastructure as a
requirement.
[draft-ietf-multimob-pmipv6-source-01]describes the support of
multicast senders in Proxy Mobile IPv6 domains. MLD proxy functions
are deployed at the MAG. Multicast traffic MUST be tunneled up to
the LMA of the multicast sender, transferred to the LMA of the
multicast listener and then tunneled downwards to the MAG of the
multicast listener. The problem is especially manifested when
multicast listener and sender attach to the same MAG but different
LMAs, the traffic has to go up to one LMA, cross over to the other
LMA, and then be tunneled back to the same MAG, causing non-optimal
multicast routes and redundant flows at the MAG.In the direct routing
scenario when PIM-SM and PIM-SSM are deployed in MAGs, Source-
specific shortest path trees(SPT) have to follow LMA-MAG tunnels
towards the multicast sender which can be suboptimal.
Liu & Luo Expires January 31, 2013 [Page 3]
Internet-Draft RO for Multicast Sender July 2012
This document describes multicast routes optimazition mechanisms for
multicast sender. Figure 1 shows the Architecture of Multicast
Deployment with listener and sender in the same PMIPv6 domain.
Internet
:
|
|
+-----+
| LMA | Multicast Anchor
+-----+
||
//\\
// \\
// \\
// \\
// \\
// \\
|| ||
+----+ +----+
|MAG1| |MAG2|
+----+ +----+
| |
| |
+----+ +----+
| MN1| | MN2|
+----+ +----+
Multicast Listener(s) Multicast Sender(s)
Figure1 Architecture of Multicast Deployment with listener and source
in the same PMIPv6 domain
The proposed protocol assumes that both LMA and MAG enable the
Protocol- Independent Multicast - Sparse Mode (PIM-SM) multicast
routing protocol [RFC4601], and further MAG MUST operate as an "SSM-
aware" router [RFC4604].
2. Terminology
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 [RFC2119].
The following terms used in this document are to be interpreted as
defined in [RFC5213]; Home Address(HoA), Mobile Access Gateway (MAG),
Local Mobility Anchor (LMA), Mobile Node (MN), Proxy Mobile IPv6
Domain (PMIPv6-Domain), LMA Address (LMAA), Proxy Care-of Address
Liu & Luo Expires January 31, 2013 [Page 4]
Internet-Draft RO for Multicast Sender July 2012
(Proxy-CoA), Proxy Binding Update (PBU), and Proxy Binding
Acknowledgement (PBA).
Terms DR(Designated Router), MRIB(Multicast Routing Information
Base), RPF(Reverse Path Forwarding), RPF Neighbor, SPT(shortest-path
tree), PIM Join, Pim Prune, iif(incoming interface),oiflist(outgoing
interface list), Source-Specific Multicast(SSM) are to be interpreted
as defined in[RFC4601]
3. Overview
In the SSM scenario, the multicast Listeners actively send the (S,G)
subscribe message, S is the multicast sender's Home Address (HoA) .
Internet
:
|
|
+-----+
| LMA | Unicast Anchor
+-----+
||
// \\
// \\
// \\ Unicast Tunnel
// \\
// \\
// \\
|| ||
+----+ +----+
|MAG1|=O=O=O=O=O=O=O=O=O=O|MAG2|
+----+ +----+
| Multicast Tunnel |
| |
+----+ +----+
| MN1| | MN2|
+----+ +----+
Multicast Listener(s) Multicast Sender(s)
Figure2 Architecture of Optimized Multicast Routing
As shown in Figure 2, MN1(the multicast Listener) and MN2(the
multicast sender) are both mobile nodes in the same PMIPv6 domain,
they both have binding cache entry in the LMA. MN1 sends (S,G)
subscribe message(MLD Report messages) to the access link to
establish the SPT, MN1 has to operate as an "SSM-aware" host
[RFC4604]. On receiving the (S,G) subscribe message from MN1, the
Liu & Luo Expires January 31, 2013 [Page 5]
Internet-Draft RO for Multicast Sender July 2012
attached MAG1 sends a PBU-Q message to LMA to query the CoA (i. e.,
IP address of MAG2) of MN2. On the reception of PBU-Q, the LMA
responds with a PBA-Q message including the CoA of MN2 to MAG1.
After acquiring the CoA of MN2, MAG1 establishes bi-directional
tunnel with MAG2, and sends PIM Join message to MAG2 through this
tunnel, MAG1 and MAG2 establish the ralated muticast state. So the
MAG-based SPT is established successfully and the subsequent
multicast data flow will be transmitted through the MAG-based SPT
which is represented by "=O" in Figure 2. Unicast data flow will be
transmitted through base PMIPv6 tunnel which is represented by "||"
in Figure 2.
The tunnel between MAG1 and MAG2 is used for multicast
packets(including signaling and data flow) transmission only.
As described in [RFC4601], on receipt of data from S to G on
interface iif (incoming interface of the packet), the DR will firstly
check whether the source is directly connected and the iif is
identical to the Reverse Path Forwarding (RPF) interface. As shown
in Figure 2, MAG2 is the DR of MN2, MAG1 is the DR of MN1. After
tunnel establishment between MAG1 and MAG2, MAG1 add the tunnel route
to the MRIB, the RPF check will be successful.
This draft assumes that every MN supporting multicast service is
previously registered in the PMIPv6 unicast domain to get a unicast
IP address(HoA).
4. Protocol Operation
4.1. Add Route to MRIB
In PIM-SM, the MRIB is used to decide where to send Join/Prune
messages. on receiving the MLD Report message from MN,the MAG of MN
has to choose a RPF Neighbor that the MRIB indicates should be used
to forward packets to, and then send the Join/Prune message to the
RPF Neighbor.
After tunnel establishment between MAG1 and MAG2, MAG1 add the tunnel
route to the MRIB, so that the RPF Neighbor of MAG1 is MAG2, MAG1
send PIM Join/Prune message through this tunnel.
4.2. Optimized Multicast Route Establishment
This section provides the multicast routes optimization procedure.The
procedures are described as follows and illustrated in Figure 3.
Liu & Luo Expires January 31, 2013 [Page 6]
Internet-Draft RO for Multicast Sender July 2012
MN1 MAG1 LMA MN2 MAG2
| 1. | | | |
|--MLD Report->| | | |
| (S,G) join | 2. | | |
| |------PBU-Q------->| | |
| | 3. | | |
| |<------PBA-Q-------| | |
| |Acquire CoA of MN2 | | |
| | | | |
| | | | |
| | 4. | |
| |<=====================================>|
| | Establish multicast Bi-dir tunnel |
| | | | |
| 5. | | |
| Add route to MRIB | | |
| | | | |
| | | | |
| 6. | | |
| Update (S,G) state | | |
| Set iif | | |
| | | | |
| | 7. | |
| | PIM (S,G) join | |
| |=============Bi-dir tunnel============>|
| | | | |
| | | | 8.
| | | |Update (S,G) state
| | | | Set oiflist
| | | | |
| | | Multicast data
| | 9. |--------->|
| | Multicast data | |
|Multicast data|<============Bi-dir tunnel=============|
|<-------------| | | |
Figure3 Procedure of establishing multicast Route
1.MN1 sends (S,G) subscribe message to the access link, S is the HoA
of MN2.
2.On receiving the (S,G) subscribe message from MN1, the attached
MAG1 sends a PBU-Q message to LMA to query the CoA (i. e., IP address
of MAG2) of MN2.
3.On the reception of PBU-Q, the LMA responds with a PBA-Q message
including the CoA of MN2.
Liu & Luo Expires January 31, 2013 [Page 7]
Internet-Draft RO for Multicast Sender July 2012
4.After acquire the CoA of MN2, MAG1 establish bi-directional tunnel
with MAG2.
5.After tunnel establishment, MAG1 add the tunnel route to the MRIB,
so that the RPF Neighbor of MAG1 is MAG2.
6.If there are multicast channels the MN1 has subscribed but MAG1 has
not yet subscribed, MAG1 establishes multicast state for the channel,
and sets the iif of the multicast state as MAG1-MAG2 tunnel
interface. if MAG1 already subscribed the channel, MAG1 updates the
iif of the multicast state as MAG1-MAG2 tunnel interface.
7.MAG1 joins the corresponding multicast channels by sending the PIM
Join message to the RPF Neighbor MAG2 through the MAG1-MAG2 tunnel.
8.On the reception of PIM Join message from MAG1, If MAG2 has not yet
subscribed the multicast channel, MAG2 establishes multicast state
for the channel, and adds the MAG2-MAG1 tunnel interface to the
oiflist of the multicast state. if MAG2 already subscribed the
channel, MAG2 updates the oiflist of the multicast state by adding
the MAG2-MAG1 tunnel interface to the oiflist.
9.The subsequent multicast data flow will be transmitted through the
optimized multicast route(MAG1-MAG2 bi-directional tunnel).
4.3. Multicast Route Deletion
Liu & Luo Expires January 31, 2013 [Page 8]
Internet-Draft RO for Multicast Sender July 2012
MN1 MAG1 MAG2
| 1. | |
|--MLD Report->| |
| leave (S,G) | |
| | |
| 2. |
|With regard to MN2,MN1 is the |
|last multicast listener on MAG1 |
| | |
| | |
| 3. |
| delete all the (S,G) state |
| ralating to MN2 on MAG1 |
| | |
| | |
| | |
| | 4. |
| | PIM (S,G) prune |
| |=============Bi-dir tunnel============>|
| | |
| | |
| | 5.
| | update (S,G) state
| | update oiflist
| | 6. |
| | Remove multicast Bi-dir tunnel |
| |<======================================|
| | |
Figure4 Procedure of deleting multicast Route
1.MN1 sends (S,G) leave message(MLD Report messages) to the access
link, S is the HoA of MN2.
2.On receiving the (S,G) leave message from the MN1, if MAG1 figures
that MN1 is the last multicast listener subscribed to the MN2, MAG1
perform the following steps, otherwise, MAG1 simply delete the
multicast state of MN1 as normal, which is removing MAG1-MN1
interface from the oiflist of the multicast state.
3.MAG1 delete all the multicast state related to MN2.
4.MAG1 remove the tunnel route from the MRIB and leave the
corresponding multicast channels by sending the PIM Prune message to
the RPF Neighbor MAG2 through the MAG1-MAG2 tunnel.
5.On the reception of PIM Prune message from MAG1, MAG2 updates the
oiflist of the multicast state by removing the MAG2-MAG1 tunnel
Liu & Luo Expires January 31, 2013 [Page 9]
Internet-Draft RO for Multicast Sender July 2012
interface from the oiflist.
6.Remove bi-directional tunnel between MAG1 and MAG2.
4.4. Multicast sender handover
When the multicast sender handover from the old MAG to a new MAG.
From the old MAG, the new MAG gets the addresses of all the distant
MAGs(MAGs attached by the multicast listeners that have subscribed to
the multicast sender) according to the multicast states that match
the moving multicast sender. The new MAG establishes tunnels with
the distant MAGs and notify these distant MAGs to update their
multicast states so the multicast listeners could receive traffic
through the new tunnel between the new MAG and the distant MAGs.
TODO details.
4.5. Multicast listener handover
When the multicast listener handover from the old MAG to a new MAG.
From the old MAG, the new MAG gets all the active multicast
subscriptions that match the moving multicast listener and then
reestablishes the multicast route the same way as describe in section
4.2.
TODO details.
4.6. ASM Scecario
In this scenario,PIM-SM first establishes as usual RP-based
distribution tree(RPT) and SPT in phase one and phase two. In phase
three,the DR(MAG) on the multicast listener's side will choose to
initiate a transfer from the shared tree to a source-specific
shortest-path tree (SPT).
At this point the DR knows the HoA of the multicast sender,it then
gets the CoA of the multicast sender from LMA and establishes the
shortest path tree the way as described in section 4.2.
TODO details.
5. Local Mobility Anchor Operation
On receiving a PBU-Q message from MAG1, the LMA must perform the
following operations.
1.Check if the PBU-Q message contains the Q flag set to 1.
Liu & Luo Expires January 31, 2013 [Page 10]
Internet-Draft RO for Multicast Sender July 2012
2.Query the CoA of MN2 by looking up the binding cache of LMA.
3.If the corresponding HoA-CoA entry is found in the binding cache,
LMA will respond PBA-Q message containing a success indication.
Otherwise, if not found, LMA will respond PBA-Q message containing a
failure indication.
The responding PBA-Q message from LMA to MAG1 is constructed as
follows.
1.Source address field in the IP header must be set to IP address of
LMA.
2.Destination address filed in the IP header must be set to IP
address of the MAG1.
3.The PBA-Q message MUST include the CoA of MN2.
6. Mobile Access Gateway Operation
The MAG MUST operate as an "SSM-aware" router. [RFC4604] provide the
behavior of an "SSM-aware" router.
6.1. MN1 and MN2 attach to the same MAG
On receiving the (S,G) subscribe message from the MN1, MAG1 could
decide whether MN2 attachs to itself according to MN2's HoA which is
included in the (S,G) subscribe message. If MAG1 figures that MN1
and MN2 both attach to it. MAG1 operates as below:
If there are multicast channels the MN1 has subscribed but MAG1 has
not yet subscribed, MAG1 establishes multicast state for the
channel,and adds the MAG1-MN1 interface to the oiflist of the
multicast state.
If MAG1 already subscribed the channel, MAG1 updates the oiflist of
the multicast state by adding the MAG1-MN1 interface to the oiflist.
MAG1 will send the multicast data flow from MN2 to MN1 locally.
6.2. MN1 and MN2 attach to different MAG
The PBU-Q message from MAG1 to LMA MUST be constructed, as specified
below.
1.Source address field in the IP header must contain the IP address
of MAG1.
Liu & Luo Expires January 31, 2013 [Page 11]
Internet-Draft RO for Multicast Sender July 2012
2.Destination address filed in the IP header must contain the IP
address of LMA.
3.The PBU-Q message must include the HoA of MN2.
On receiving a PBA-Q message from LMA, MAG1 MUST perform the
following operations.
1.Check if the PBA-Q message contains the Q flag set to 1.
2.MAG1 MUST establish a tunnel with MAG2 for muticast data delivery.
3.MAG1 MUST add route to Multicast Routing Information Base (MRIB)
and send PIM Join/Prune messages through MAG1-MAG2 tunnel interface.
4.MAG1 MUST create/update multicast state for the channel, the iif of
the multicast state MUST be set to MAG1-MAG2 tunnel interface.
On receiving a PIM Join/Prune messages from MAG2-MAG1 tunnel
interface, MAG2 MUST create/update multicast state for the channel.
1.Add MAG2-MAG1 tunnel interface to the oiflist of the multicast
state on receiving a PIM Join message from MAG2-MAG1 tunnel
interface.
2.Delete MAG2-MAG1 tunnel interface from the oiflist of the multicast
state on receiving a PIM Prune message from MAG2-MAG1 tunnel
interface.
7. Mobile Node Operation
The MN MUST operate as an "SSM-aware" host . [RFC4604] provide the
behavior of an "SSM-aware" host.
8. Message Format Extension
8.1. Proxy Binding Update with Source Address Query Extension
Liu & Luo Expires January 31, 2013 [Page 12]
Internet-Draft RO for Multicast Sender July 2012
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|Q| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure5 Proxy Binding Update with Source Address Query Extension
A Binding Update message that is sent by MAG to LMA is referred to as
the "Proxy Binding Source Address Query" message. A new flag (Q) is
included in the Proxy Binding Update message with Source Address
Query extension (PBU-Q). The rest of the Binding Update message
format remains the same as defined in[RFC3775] and with the
additional (R), (M), and (P) flags, as specified in [RFC3963],
[RFC4140], and [RFC5213], respectively.
Source Address Query Flag
A new flag (Q) is included in the Binding Update message to indicate
to LMA that the Binding Update message is a Source Address Query
message. In the normal PMIP operation, the flag must be set to 0.
The PBU-Q message is transfered for quering the MN2's CoA. The rest
of the PBU message remains unchanged.
8.2. Proxy Binding Acknowledgement Message with Source Address Query
Extension
Liu & Luo Expires January 31, 2013 [Page 13]
Internet-Draft RO for Multicast Sender July 2012
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|Q|Reserve|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure6 Proxy Binding Update with Source Address Query Extension
A "Proxy Binding Acknowledgement" message is sent from LMA to MAG in
response to a Proxy Binding Update message. A new flag (Q) is
included in the Proxy Binding Acknowledgement message with Source
Address Query extension (PBA-Q). The rest of the Binding
Acknowledgement message format remains the same as defined in
[RFC3775] and with the additional (R) flag, as specified in [RFC3963]
and [RFC5213], respectively.
Source Address Query Flag
A new flag (Q) is included in the Binding Acknowledgement message to
indicate to MAG that the Binding Acknowledgement message is a Source
Address Query message. In the normal PMIP operation, the flag must
be set to 0.
When (Q) flag is specified in PBA-Q message, the mobility options
field includes "MN2's CoA"(Section 8.3).
8.3. Care-of Address Option
Liu & Luo Expires January 31, 2013 [Page 14]
Internet-Draft RO for Multicast Sender July 2012
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Care-of Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure7 Care-of Address Option
The Care-of Address field contains the care-of address of MN2.
This option is valid only in PBA-Q message. On the reception of
PBU-Q, the LMA responds with a PBA-Q message including the Care-of
Address Option.
9. Security Considerations
TBD
10. IANA Considerations
11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
January 2005.
[RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L.
Bellier, "Hierarchical Mobile IPv6 Mobility Management
(HMIPv6)", August 2005.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
Liu & Luo Expires January 31, 2013 [Page 15]
Internet-Draft RO for Multicast Sender July 2012
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", August 2006.
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", August 2006.
[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")", August 2006.
[RFC5213] Gundavelli, S, Ed., Leung, K., Devarapalli, V., Chowdhury,
K., and B. Patil, "Proxy Mobile IPv6", RFC 5213,
August 2008.
[RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
Deployment for Multicast Listener Support in Proxy Mobile
IPv6 (PMIPv6) Domains", April 2011.
[draft-ietf-multimob-pmipv6-ropt-00]
Zuniga, JC., Contreras, LM., Bernardos, CJ., and S. Jeon,
"Multicast Mobility Routing Optimizations for Proxy Mobile
IPv6", March 2012.
[draft-ietf-multimob-pmipv6-source-01]
Schmidt, TC., Gao, S., Zhang, H., and M. Waehlisch,
"Mobile Multicast Sender Support in Proxy Mobile IPv6
(PMIPv6) Domains", July 2012.
Authors' Addresses
Juan Liu
ZTE Corporation
RD Building 1,Zijinghua Road No.68
Yuhuatai District,Nanjing 210012
P.R.China
Email: liu.juan45@zte.com.cn
Liu & Luo Expires January 31, 2013 [Page 16]
Internet-Draft RO for Multicast Sender July 2012
Wen Luo
ZTE Corporation
RD Building 1,Zijinghua Road No.68
Yuhuatai District,Nanjing 210012
P.R.China
Email: luo.wen@zte.com.cn
Liu & Luo Expires January 31, 2013 [Page 17]
