draft-ietf-multimob-pmipv6-base-solution-02.txt   draft-ietf-multimob-pmipv6-base-solution-03.txt 
MULTIMOB Group T C. Schmidt MULTIMOB Group T C. Schmidt
Internet-Draft HAW Hamburg Internet-Draft HAW Hamburg
Intended status: BCP M. Waehlisch Intended status: BCP M. Waehlisch
Expires: December 2, 2010 link-lab & FU Berlin Expires: December 16, 2010 link-lab & FU Berlin
S. Krishnan S. Krishnan
Ericsson Ericsson
May 31, 2010 June 14, 2010
Base Deployment for Multicast Listener Support in PMIPv6 Domains Base Deployment for Multicast Listener Support in PMIPv6 Domains
draft-ietf-multimob-pmipv6-base-solution-02 draft-ietf-multimob-pmipv6-base-solution-03
Abstract Abstract
This document describes deployment options for activating multicast This document describes deployment options for activating multicast
listener functions in Proxy Mobile IPv6 domains without modifying listener functions in Proxy Mobile IPv6 domains without modifying
mobility and multicast protocol standards. Similar to Home Agents in mobility and multicast protocol standards. Similar to Home Agents in
Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as
multicast subscription anchor points, while Mobile Access Gateways multicast subscription anchor points, while Mobile Access Gateways
provide MLD proxy functions. In this scenario, Mobile Nodes remain provide MLD proxy functions. In this scenario, Mobile Nodes remain
agnostic of multicast mobility operations. agnostic of multicast mobility operations.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 2, 2010. This Internet-Draft will expire on December 16, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 7 skipping to change at page 3, line 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Initial MLD Queries on Upcoming Links . . . . . . . . 15 Appendix A. Initial MLD Queries on Upcoming Links . . . . . . . . 15
Appendix B. State of IGMP/MLD Proxy Implementations . . . . . . . 15 Appendix B. State of IGMP/MLD Proxy Implementations . . . . . . . 15
Appendix C. Comparative Evaluation of Different Approaches . . . 16 Appendix C. Comparative Evaluation of Different Approaches . . . 16
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 18 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 [RFC3775] by Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 (MIPv6)
network-based management functions that enable IP mobility for a host [RFC3775] by network-based management functions that enable IP
without requiring its participation in any mobility-related mobility for a host without requiring its participation in any
signaling. Additional network entities called the Local Mobility mobility-related signaling. Additional network entities called the
Anchor (LMA), and Mobile Access Gateways (MAGs), are responsible for Local Mobility Anchor (LMA), and Mobile Access Gateways (MAGs), are
managing IP mobility on behalf of the mobile node (MN). responsible for managing IP mobility on behalf of the mobile node
(MN).
With these entities in place, the mobile node looses transparent end- With these entities in place, the mobile node loses transparent end-
to-end connectivity to the static Internet, and in the particular to-end connectivity to the static Internet, and in the particular
case of multicast communication, group membership management as case of multicast communication, group membership management as
signaled by the Multicast Listener Discovery protocol [RFC3810], signaled by the Multicast Listener Discovery protocol (MLD)
[RFC2710] requires dedicated treatment at the network side, see [RFC3810], [RFC2710] requires dedicated treatment at the network
[I-D.deng-multimob-pmip6-requirement]. side, see [I-D.deng-multimob-pmip6-requirement].
Multicast routing functions need to be placed carefully within the Multicast routing functions need to be placed carefully within the
PMIPv6 domain to augment unicast transmission with group PMIPv6 domain to augment unicast transmission with group
communication services. [RFC5213] does not explicitly address communication services. [RFC5213] does not explicitly address
multicast communication and thus relies on the minimal multicast multicast communication. Bi-directional home tunneling, the minimal
support provided by MIPv6. But unfortunately, bi-directional home multicast support arranged by MIPv6, cannot be directly transferred
tunneling, the minimal multicast support arranged by MIPv6, cannot be to network-based management scenarios, since a mobility-unaware node
applied in network-based management scenarios, since a mobility- will not initiate such a tunnel after movement. Consequently, even a
unaware node will not initiate such a tunnel after movement. minimal multicast listener support in PMIPv6 domains requires an
Consequently, even a minimal multicast listener support in PMIPv6 explicit deployment of additional functions.
domains requires an explicit deployment of additional functions, as
is the subject of this document.
This document describes options for deploying multicast listener This document describes options for deploying multicast listener
functions in Proxy Mobile IPv6 domains without modifying mobility and functions in Proxy Mobile IPv6 domains without modifying mobility and
multicast protocol standards. Similar to Home Agents in Mobile IPv6, multicast protocol standards. Similar to Home Agents in Mobile IPv6,
PMIPv6 Local Mobility Anchors serve as multicast subscription anchor PMIPv6 Local Mobility Anchors serve as multicast subscription anchor
points, while Mobile Access Gateways provide MLD proxy functions. points, while Mobile Access Gateways provide MLD proxy functions.
Mobile Nodes in this scenario remain agnostic of multicast mobility Mobile Nodes in this scenario remain agnostic of multicast mobility
operations. This document does not address specific optimizations operations. This document does not address specific optimizations
and efficiency improvements of multicast routing for network-based and efficiency improvements of multicast routing for network-based
mobility discussed in [RFC5757], as such solutions would require mobility discussed in [RFC5757], as such solutions would require
changes to the base PMIPv6 protocol [RFC5213]. changes to the base PMIPv6 protocol [RFC5213].
2. Terminology 2. Terminology
This document uses the terminology as defined for the mobility This document uses the terminology as defined for the mobility
protocols [RFC3775], [RFC5213] and [RFC5844], as well as the protocols [RFC3775], [RFC5213] and [RFC5844], as well as the
multicast edge related protocols[RFC3376], [RFC3810] and [RFC4605]. multicast edge related protocols [RFC3376], [RFC3810] and [RFC4605].
3. Overview 3. Overview
The reference scenario for multicast deployment in Proxy Mobile IPv6 The reference scenario for multicast deployment in Proxy Mobile IPv6
domains is illustrated in Figure 1. domains is illustrated in Figure 1.
+-------------+ +-------------+
| Content | | Content |
| Source | | Source |
+-------------+ +-------------+
| |
skipping to change at page 7, line 21 skipping to change at page 7, line 21
| | | | | | | | | |
| | Aggregated Join(G) | | | | Aggregated Join(G) | |
| +================================================>| | +================================================>|
| | | | | | | | | |
| | Mcast Data | | | | | Mcast Data | | |
| |<================================================+ | |<================================================+
| | | | | | | | | |
| Mcast Data | Mcast Data | | | | Mcast Data | Mcast Data | | |
|<---------------+--------------->| | | |<---------------+--------------->| | |
| | | | | | | | | |
| | < Movement to MAG2 & PMIP Binding Update > | | < Movement to MAG2 & PMIP Binding Update > |
| | | | | | | | | |
| | |--- Rtr Sol -->| | | | |--- Rtr Sol -->| |
| | |<-- Rtr Adv ---| |
| | | | | | | | | |
| | | MLD Query | | | | | MLD Query | |
| | |<--------------+ | | | |<--------------+ |
| | | | | | | | | |
| | | Join(G) | | | | | Join(G) | |
| | +-------------->| | | | +-------------->| |
| | | Aggregated Join(G) | | | Aggregated Join(G)
| | | +===============>| | | | +===============>|
| | | | | | | | | |
| | Mcast Data | | | | | Mcast Data | | |
skipping to change at page 8, line 9 skipping to change at page 8, line 11
Such mobile nodes will use IGMP [RFC2236],[RFC3376] signaling for Such mobile nodes will use IGMP [RFC2236],[RFC3376] signaling for
multicast, which is handled by an IGMP proxy function at the MAG in multicast, which is handled by an IGMP proxy function at the MAG in
an analogous way. an analogous way.
Following these deployment steps, multicast management transparently Following these deployment steps, multicast management transparently
inter-operates with PMIPv6. It is worth noting that MNs - while inter-operates with PMIPv6. It is worth noting that MNs - while
being attached to the same MAG, but associated with different LMAs - being attached to the same MAG, but associated with different LMAs -
can subscribe to the same multicast group. Thereby data could be can subscribe to the same multicast group. Thereby data could be
distributed redundantly in the network and duplicate traffic could distributed redundantly in the network and duplicate traffic could
arrive at a MAG. Additionally in a point-to-point wireless link arrive at a MAG. Additionally in a point-to-point wireless link
model, an MAG might be forced to transmit the same data over one model, a MAG might be forced to transmit the same data over one
wireless domain to different MNs. However, multicast traffic to one wireless domain to different MNs. However, multicast traffic to one
MN will always remain unique, i.e., the mobile multicast distribution MN will always remain unique, i.e., the mobile multicast distribution
system will never cause duplicate packets arriving at an MN (see system will never cause duplicate packets arriving at an MN (see
Appendix C for further considerations). Appendix C for further considerations).
4. Deployment Details 4. Deployment Details
Multicast activation in a PMIPv6 domain requires to deploy general Multicast activation in a PMIPv6 domain requires to deploy general
multicast functions at PMIPv6 routers and to define its interaction multicast functions at PMIPv6 routers and to define their interaction
with the PMIPv6 protocol in the following way: with the PMIPv6 protocol in the following way:
4.1. Operations of the Mobile Node 4.1. Operations of the Mobile Node
A Mobile Node willing to manage multicast traffic will join, maintain A Mobile Node willing to manage multicast traffic will join, maintain
and leave groups as if located in the fixed Internet. No specific and leave groups as if located in the fixed Internet. No specific
mobility actions nor implementations are required at the MN. mobility actions nor implementations are required at the MN.
4.2. Operations of the Mobile Access Gateway 4.2. Operations of the Mobile Access Gateway
skipping to change at page 9, line 12 skipping to change at page 9, line 13
will answer the Queries on behalf of all active downstream receivers will answer the Queries on behalf of all active downstream receivers
maintained in its membership database. Queries sent by the LMA do maintained in its membership database. Queries sent by the LMA do
not force the MAG to trigger corresponding messages immediately not force the MAG to trigger corresponding messages immediately
towards MNs. Multicast traffic arriving at the MAG on an upstream towards MNs. Multicast traffic arriving at the MAG on an upstream
interface will be forwarded according to the group/source-specific interface will be forwarded according to the group/source-specific
forwarding states as acquired for each downstream interface within forwarding states as acquired for each downstream interface within
the MLD proxy instance. At this stage, it is important to note that the MLD proxy instance. At this stage, it is important to note that
IGMP/MLD proxy implementations capable of multiple instances are IGMP/MLD proxy implementations capable of multiple instances are
expected to closely follow the specifications of section 4.2 in expected to closely follow the specifications of section 4.2 in
[RFC4605], i.e., treat proxy instances in isolation of each other [RFC4605], i.e., treat proxy instances in isolation of each other
while forwarding. while forwarding. In providing isolated proxy instances, the MAG
will uniquely serve its downstream links with exactly the data that
belong to whatever group is subscribed on the particular interface.
After a handover, the MAG will continue to manage upstream tunnels After a handover, the MAG will continue to manage upstream tunnels
and downstream interfaces as specified in the PMIPv6 specification. and downstream interfaces as specified in the PMIPv6 specification.
It MUST dynamically associate new access links to proxy instances It MUST dynamically associate new access links to proxy instances
that include the upstream connection to the corresponding LMA. The that include the upstream connection to the corresponding LMA. The
MAG detects the arrival of a new MN by receiving a router MAG detects the arrival of a new MN by receiving a router
solicitation message and by an upcoming link. To learn about solicitation message and by an upcoming link. To learn about
multicast groups subscribed by a newly attaching MN, the MAG SHOULD multicast groups subscribed by a newly attaching MN, the MAG SHOULD
send a General Query to the MN's link. Querying an upcoming send a General Query to the MN's link. Querying an upcoming
interface is a standard operation of MLD queriers (see Appendix A) interface is a standard operation of MLD queriers (see Appendix A)
skipping to change at page 9, line 45 skipping to change at page 9, line 48
are equivalent to a General Query loss. To prevent erroneous query are equivalent to a General Query loss. To prevent erroneous query
timeouts at the MAG, MLD parameters SHOULD be carefully adjusted to timeouts at the MAG, MLD parameters SHOULD be carefully adjusted to
the mobility regime. In particular, MLD timers and the Robustness the mobility regime. In particular, MLD timers and the Robustness
Variable (see section 9 of [RFC3810]) MUST be chosen to be compliant Variable (see section 9 of [RFC3810]) MUST be chosen to be compliant
with the time scale of handover operations and proxy configurations with the time scale of handover operations and proxy configurations
in the PMIPv6 domain. in the PMIPv6 domain.
In proceeding this way, the MAG is able to aggregate multicast In proceeding this way, the MAG is able to aggregate multicast
subscriptions for each of its MLD proxy instances. However, this subscriptions for each of its MLD proxy instances. However, this
deployment approach does not prevent multiple identical streams deployment approach does not prevent multiple identical streams
arriving from different LMA upstream interfaces.Furthermore, a arriving from different LMA upstream interfaces. Furthermore, a
multipoint channel forwarding into the wireless domain is prevented multipoint channel forwarding into the wireless domain is prevented
by the point-to-point link model in use. by the point-to-point link model in use.
4.3. Operations of the Local Mobility Anchor 4.3. Operations of the Local Mobility Anchor
For any MN, the Local Mobility Anchor acts as the persistent Home For any MN, the Local Mobility Anchor acts as the persistent Home
Agent and at the same time as the default multicast querier for the Agent and at the same time as the default multicast querier for the
corresponding MAG. It implements the function of the designated corresponding MAG. It implements the function of the designated
multicast router or a further MLD proxy. According to MLD reports multicast router or a further MLD proxy. According to MLD reports
received from a MAG (on behalf of the MNs), it establishes/maintains/ received from a MAG (on behalf of the MNs), it establishes/maintains/
skipping to change at page 11, line 24 skipping to change at page 11, line 24
identify two data streams as identical when distributed via an IPv4 identify two data streams as identical when distributed via an IPv4
and IPv6 multicast group. Thus duplicate data may be forwarded on a and IPv6 multicast group. Thus duplicate data may be forwarded on a
heterogeneous network layer. heterogeneous network layer.
4.5. Multihoming Support 4.5. Multihoming Support
An MN can connect to a PMIPv6 domain through multiple interfaces and An MN can connect to a PMIPv6 domain through multiple interfaces and
experience transparent unicast handovers at all interfaces (cf., experience transparent unicast handovers at all interfaces (cf.,
section 5.4 of [RFC5213]). In such simultaneous access scenario, it section 5.4 of [RFC5213]). In such simultaneous access scenario, it
can autonomously assign multicast channel subscriptions to individual can autonomously assign multicast channel subscriptions to individual
interfaces. While doing so, multicast mobility operations described interfaces (see [RFC5757] for additional details). While doing so,
in this document will transparently preserve the association of multicast mobility operations described in this document will
channels to interfaces in the following way. transparently preserve the association of channels to interfaces in
the following way.
Multicast listener states are kept per interface in the MLD state Multicast listener states are kept per interface in the MLD state
table. An MN will answer to an MLD General Query received on a table. An MN will answer to an MLD General Query received on a
specific (re-attaching) interface according to the specific specific (re-attaching) interface according to the specific
interface's state table. Thereafter, multicast forwarding is resumed interface's state table. Thereafter, multicast forwarding is resumed
for channels identical to those under subscription prior to handover. for channels identical to those under subscription prior to handover.
Consequently, an MN in a PMIPv6 domain MAY use multiple interfaces to Consequently, an MN in a PMIPv6 domain MAY use multiple interfaces to
facilitate load balancing or redundancy, but cannot follow a 'make- facilitate load balancing or redundancy, but cannot follow a 'make-
before-break' approach to service continuation on handovers. before-break' approach to service continuation on handovers.
skipping to change at page 12, line 29 skipping to change at page 12, line 29
implemented by vendors as it supports faster leave latencies and implemented by vendors as it supports faster leave latencies and
reduced signaling. reduced signaling.
Enabling explicit tracking on downstream interfaces of the LMA and Enabling explicit tracking on downstream interfaces of the LMA and
MAG would track a single MAG and MN respectively per interface. It MAG would track a single MAG and MN respectively per interface. It
may be used to preserve bandwidth on the MAG-MN link. may be used to preserve bandwidth on the MAG-MN link.
5. Message Source and Destination Address 5. Message Source and Destination Address
This section describes source and destination addresses of MLD This section describes source and destination addresses of MLD
messages. The interface identifier A-B denotes an interface on node messages and encapsulating outer headers when deployed in the PMIPv6
A, which is connected to node B. This includes tunnel interfaces. domain. This overview is for clarification purposes, only, and does
not define a behavior different from referenced standards in any way.
The interface identifier A-B denotes an interface on node A, which is
connected to node B. This includes tunnel interfaces.
5.1. Query 5.1. Query
+===========+================+======================+==========+ +===========+================+======================+==========+
| Interface | Source Address | Destination Address | Header | | Interface | Source Address | Destination Address | Header |
+===========+================+======================+==========+ +===========+================+======================+==========+
| | LMAA | Proxy-CoA | outer | | | LMAA | Proxy-CoA | outer |
+ LMA-MAG +----------------+----------------------+----------+ + LMA-MAG +----------------+----------------------+----------+
| | LMA-link-local | [RFC2710], [RFC3810] | inner | | | LMA-link-local | [RFC2710], [RFC3810] | inner |
+-----------+----------------+----------------------+----------+ +-----------+----------------+----------------------+----------+
| MAG-MN | MAG-link-local | [RFC2710], [RFC3810] | -- | | MAG-MN | MAG-link-local | [RFC2710], [RFC3810] | -- |
skipping to change at page 14, line 5 skipping to change at page 14, line 5
extinction on the departure of MNs, as mobile multicast listeners in extinction on the departure of MNs, as mobile multicast listeners in
the PMIPv6 domain will not actively terminate group membership prior the PMIPv6 domain will not actively terminate group membership prior
to departure. to departure.
8. Acknowledgements 8. Acknowledgements
This memo is the outcome of extensive previous discussions and a This memo is the outcome of extensive previous discussions and a
follow-up of several initial drafts on the subject. The authors follow-up of several initial drafts on the subject. The authors
would like to thank (in alphabetical order) Luis Contreras, Greg would like to thank (in alphabetical order) Luis Contreras, Greg
Daley, Gorry Fairhurst, Dirk von Hugo, Seil Jeon, Jouni Korhonen, Daley, Gorry Fairhurst, Dirk von Hugo, Seil Jeon, Jouni Korhonen,
Guang Lu, Sebastian Meiling, Liu Hui, Imed Romdhani, Behcet Sarikaya, Guang Lu, Sebastian Meiling, Liu Hui, Akbar Rahman, Imed Romdhani,
Stig Venaas, and Juan Carlos Zuniga for advice, help and reviews of Behcet Sarikaya, Pierrick Seite, Stig Venaas, and Juan Carlos Zuniga
the document. Funding by the German Federal Ministry of Education for advice, help and reviews of the document. Funding by the German
and Research within the G-LAB Initiative is gratefully acknowledged. Federal Ministry of Education and Research within the G-LAB
Initiative is gratefully acknowledged.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, Listener Discovery (MLD) for IPv6", RFC 2710,
skipping to change at page 15, line 12 skipping to change at page 15, line 14
[I-D.ietf-mboned-auto-multicast] [I-D.ietf-mboned-auto-multicast]
Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T. Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T.
Pusateri, "Automatic IP Multicast Without Explicit Tunnels Pusateri, "Automatic IP Multicast Without Explicit Tunnels
(AMT)", draft-ietf-mboned-auto-multicast-10 (work in (AMT)", draft-ietf-mboned-auto-multicast-10 (work in
progress), March 2010. progress), March 2010.
[I-D.zuniga-multimob-smspmip] [I-D.zuniga-multimob-smspmip]
Zuniga, J., Lu, G., and A. Rahman, "Support Multicast Zuniga, J., Lu, G., and A. Rahman, "Support Multicast
Services Using Proxy Mobile IPv6", Services Using Proxy Mobile IPv6",
draft-zuniga-multimob-smspmip-02 (work in progress), draft-zuniga-multimob-smspmip-03 (work in progress),
February 2010. May 2010.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version [RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, November 1997. 2", RFC 2236, November 1997.
[RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast [RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast
Mobility in Mobile IP Version 6 (MIPv6): Problem Statement Mobility in Mobile IP Version 6 (MIPv6): Problem Statement
and Brief Survey", RFC 5757, February 2010. and Brief Survey", RFC 5757, February 2010.
Appendix A. Initial MLD Queries on Upcoming Links Appendix A. Initial MLD Queries on Upcoming Links
skipping to change at page 18, line 32 skipping to change at page 18, line 32
smaller problems in scalability than the stream replication at LMAs smaller problems in scalability than the stream replication at LMAs
(avalanche problem). For scenario A it should be also noted that the (avalanche problem). For scenario A it should be also noted that the
high stream replication requirements at LMAs in setting 1 can be high stream replication requirements at LMAs in setting 1 can be
attenuated by deploying additional LMAs in a PMIP domain, while attenuated by deploying additional LMAs in a PMIP domain, while
scenario B does not allow for distributing the LMA-M, as no handover scenario B does not allow for distributing the LMA-M, as no handover
management is available at LMA-M. management is available at LMA-M.
Appendix D. Change Log Appendix D. Change Log
The following changes have been made from version The following changes have been made from version
draft-ietf-multimob-pmipv6-base-solution-02.
1. Clarifications and editorial improvements in response to WG
feedback.
The following changes have been made from version
draft-ietf-multimob-pmipv6-base-solution-01. draft-ietf-multimob-pmipv6-base-solution-01.
1. Editorial improvements in response to WG feedback. 1. Editorial improvements in response to WG feedback.
The following changes have been made from version The following changes have been made from version
draft-ietf-multimob-pmipv6-base-solution-00. draft-ietf-multimob-pmipv6-base-solution-00.
1. Added section on multihoming. 1. Added section on multihoming.
2. Updated security section. 2. Updated security section.
 End of changes. 20 change blocks. 
39 lines changed or deleted 53 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/