draft-ietf-multimob-pmipv6-base-solution-03.txt   draft-ietf-multimob-pmipv6-base-solution-04.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 16, 2010 link-lab & FU Berlin Expires: January 13, 2011 link-lab & FU Berlin
S. Krishnan S. Krishnan
Ericsson Ericsson
June 14, 2010 July 12, 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-03 draft-ietf-multimob-pmipv6-base-solution-04
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. A support for mobile
multicast senders is outside the scope of this document.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 45 skipping to change at page 1, line 46
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 16, 2010. This Internet-Draft will expire on January 13, 2011.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 27 skipping to change at page 2, line 28
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Deployment Details . . . . . . . . . . . . . . . . . . . . . . 8 4. Deployment Details . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Operations of the Mobile Node . . . . . . . . . . . . . . 8 4.1. Operations of the Mobile Node . . . . . . . . . . . . . . 8
4.2. Operations of the Mobile Access Gateway . . . . . . . . . 8 4.2. Operations of the Mobile Access Gateway . . . . . . . . . 8
4.3. Operations of the Local Mobility Anchor . . . . . . . . . 10 4.3. Operations of the Local Mobility Anchor . . . . . . . . . 10
4.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . 10 4.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Multihoming Support . . . . . . . . . . . . . . . . . . . 11 4.5. Multihoming Support . . . . . . . . . . . . . . . . . . . 11
4.6. Multicast Availability throughout the Access Network . . . 11 4.6. Multicast Availability throughout the Access Network . . . 12
4.7. A Note on Explicit Tracking . . . . . . . . . . . . . . . 12 4.7. A Note on Explicit Tracking . . . . . . . . . . . . . . . 12
5. Message Source and Destination Address . . . . . . . . . . . . 12 5. Message Source and Destination Address . . . . . . . . . . . . 13
5.1. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Report/Done . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Report/Done . . . . . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
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 . . . . . . . 16
Appendix C. Comparative Evaluation of Different Approaches . . . 16 Appendix C. Comparative Evaluation of Different Approaches . . . 17
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 18 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 (MIPv6) Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 (MIPv6)
[RFC3775] by network-based management functions that enable IP [RFC3775] by network-based management functions that enable IP
mobility for a host without requiring its participation in any mobility for a host without requiring its participation in any
mobility-related signaling. Additional network entities called the mobility-related signaling. Additional network entities called the
Local Mobility Anchor (LMA), and Mobile Access Gateways (MAGs), are Local Mobility Anchor (LMA), and Mobile Access Gateways (MAGs), are
responsible for managing IP mobility on behalf of the mobile node responsible for managing IP mobility on behalf of the mobile node
(MN). (MN).
With these entities in place, the mobile node loses transparent end- With these entities in place, the mobile node experiences an
to-end connectivity to the static Internet, and in the particular exceptional access topology towards the static Internet in the sense
case of multicast communication, group membership management as that the MAG introduces a routing hop also in situations, were the
signaled by the Multicast Listener Discovery protocol (MLD) LMA architecturally acts as the next hop (or designated) router for
[RFC3810], [RFC2710] requires dedicated treatment at the network the MN. In the particular case of multicast communication, group
side, see [I-D.deng-multimob-pmip6-requirement]. membership management as signaled by the Multicast Listener Discovery
protocol (MLD) [RFC3810], [RFC2710] requires dedicated treatment at
the network side .
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. Bi-directional home tunneling, the minimal multicast communication. Bi-directional home tunneling, the minimal
multicast support arranged by MIPv6, cannot be directly transferred multicast support arranged by MIPv6, cannot be directly transferred
to network-based management scenarios, since a mobility-unaware node to network-based management scenarios, since a mobility-unaware node
will not initiate such a tunnel after movement. Consequently, even a will not initiate such a tunnel after movement. Consequently, even a
minimal multicast listener support in PMIPv6 domains requires an minimal multicast listener support in PMIPv6 domains requires an
explicit deployment of additional functions. explicit deployment of additional functions.
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]. A support for mobile
multicast senders is outside the scope of this document, as well.
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
skipping to change at page 11, line 18 skipping to change at page 11, line 18
obvious deployment analogy. obvious deployment analogy.
For a dual-stack IPv4/IPv6 access network, the MAG proxy instances For a dual-stack IPv4/IPv6 access network, the MAG proxy instances
SHOULD choose multicast signaling according to address configurations SHOULD choose multicast signaling according to address configurations
on the link, but MAY submit IGMP and MLD queries in parallel, if on the link, but MAY submit IGMP and MLD queries in parallel, if
needed. It should further be noted that the infrastructure cannot needed. It should further be noted that the infrastructure cannot
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.
A particular note is worth giving the scenario of [RFC5845] in which
overlapping private address spaces of different operators can be
hosted in a PMIP domain by using GRE encapsulation with key
identification. This scenario implies that unicast communication in
the MAG-LMA tunnel can be individually identified per MN by the GRE
keys. This scenario still does not impose any special treatment of
multicast communication for the following reasons.
MLD/IGMP signaling between MNs and the MAG is on point-to-point links
(identical to unicast). Aggregated MLD/IGMP signaling between the
MAG proxy instance and the LMA remains link-local between the routers
and independent of any individual MN. So the MAG-proxy and the LMA
SHOULD not use GRE key identifiers, but plain GRE encapsulation to
exchange MLD queries and reports. Similarly, multicast traffic sent
from an LMA to MAGs proceeds as router-to-router forwarding according
to the MFIB of the LMA and independent of MN's unicast addresses,
while the MAG proxy instance distributes multicast data down the
point-to-point links (interfaces) according to its MFIB, independent
of MN's IP addresses.
It remains an open issue how communication proceeds in a multi-
operator scenario, i.e., from which network the LMA pulls multicast
traffic from. This could be any mobility Operator itself, or a third
party. However, this backbone routing in general is out of scope of
the document, and most likely a matter of contracts.
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 (see [RFC5757] for additional details). While doing so, interfaces (see [RFC5757] for additional details). While doing so,
multicast mobility operations described in this document will multicast mobility operations described in this document will
transparently preserve the association of channels to interfaces in transparently preserve the association of channels to interfaces in
the following way. the following way.
skipping to change at page 12, line 16 skipping to change at page 12, line 42
the dynamics of multicast routing, as initially foreseen in the the dynamics of multicast routing, as initially foreseen in the
Remote Subscription approach sketched in [RFC3775]. Care must be Remote Subscription approach sketched in [RFC3775]. Care must be
taken to avoid avalanche problems or service disruptions due to tardy taken to avoid avalanche problems or service disruptions due to tardy
multicast routing operations, and to adapt to different link-layer multicast routing operations, and to adapt to different link-layer
technologies [RFC5757]. The different possible approaches should be technologies [RFC5757]. The different possible approaches should be
carefully investigated beyond the initial sketch in Appendix C. Such carefully investigated beyond the initial sketch in Appendix C. Such
work is beyond the scope of this document. work is beyond the scope of this document.
4.7. A Note on Explicit Tracking 4.7. A Note on Explicit Tracking
IGMPv3/MLDv2 [RFC3376], [RFC3810] may operate in combination with An IGMPv3/MLDv2 Querier may operate in combination with explicit
explicit tracking, which allows routers to monitor each multicast tracking as described in Appendix 2 of [RFC3376], or Appendix 2
receiver. This mechanism is not standardized yet, but widely of[RFC3810]. This mechanism allows routers to monitor each multicast
implemented by vendors as it supports faster leave latencies and receiver individually. Even though this procedure is not
reduced signaling. standardized yet, it is widely implemented by vendors as it supports
faster leave latencies and 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 and encapsulating outer headers when deployed in the PMIPv6 messages and encapsulating outer headers when deployed in the PMIPv6
domain. This overview is for clarification purposes, only, and does domain. This overview is for clarification purposes, only, and does
skipping to change at page 13, line 47 skipping to change at page 14, line 22
capacities. In addition to proper authorization checks of MNs, rate capacities. In addition to proper authorization checks of MNs, rate
controls at replicators MAY be required to protect the agents and the controls at replicators MAY be required to protect the agents and the
downstream networks. In particular, MLD proxy implementations at downstream networks. In particular, MLD proxy implementations at
MAGs SHOULD carefully procure for automatic multicast state MAGs SHOULD carefully procure for automatic multicast state
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 follows initial requirements work presented in
follow-up of several initial drafts on the subject. The authors draft-deng-multimob-pmip6-requirement, and is the outcome of
would like to thank (in alphabetical order) Luis Contreras, Greg extensive previous discussions and a follow-up of several initial
Daley, Gorry Fairhurst, Dirk von Hugo, Seil Jeon, Jouni Korhonen, drafts on the subject. The authors would like to thank (in
Guang Lu, Sebastian Meiling, Liu Hui, Akbar Rahman, Imed Romdhani, alphabetical order) Jari Arkko, Luis Contreras, Greg Daley, Gorry
Behcet Sarikaya, Pierrick Seite, Stig Venaas, and Juan Carlos Zuniga Fairhurst, Dirk von Hugo, Seil Jeon, Jouni Korhonen, Guang Lu,
for advice, help and reviews of the document. Funding by the German Sebastian Meiling, Liu Hui, Akbar Rahman, Imed Romdhani, Behcet
Sarikaya, Pierrick Seite, Stig Venaas, and Juan Carlos Zuniga for
advice, help and reviews of the document. Funding by the German
Federal Ministry of Education and Research within the G-LAB Federal Ministry of Education and Research within the G-LAB
Initiative is gratefully acknowledged. 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.
skipping to change at page 14, line 45 skipping to change at page 15, line 21
("IGMP/MLD Proxying")", RFC 4605, August 2006. ("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", RFC 5844, May 2010. Mobile IPv6", RFC 5844, May 2010.
9.2. Informative References 9.2. Informative References
[I-D.deng-multimob-pmip6-requirement]
Deng, H., Chen, G., Schmidt, T., Seite, P., and P. Yang,
"Multicast Support Requirements for Proxy Mobile IPv6",
draft-deng-multimob-pmip6-requirement-02 (work in
progress), July 2009.
[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-03 (work in progress), draft-zuniga-multimob-smspmip-03 (work in progress),
May 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.
[RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung,
"Generic Routing Encapsulation (GRE) Key Option for Proxy
Mobile IPv6", RFC 5845, June 2010.
Appendix A. Initial MLD Queries on Upcoming Links Appendix A. Initial MLD Queries on Upcoming Links
According to [RFC3810] and [RFC2710] when an IGMP/MLD-enabled According to [RFC3810] and [RFC2710] when an IGMP/MLD-enabled
multicast router starts operating on a subnet, by default it multicast router starts operating on a subnet, by default it
considers itself as Querier and sends several General Queries. Such considers itself as Querier and sends several General Queries. Such
initial query should be sent by the router immediately, but could be initial query should be sent by the router immediately, but could be
delayed by a (tunable) Startup Query Interval (see Sections 7.6.2. delayed by a (tunable) Startup Query Interval (see Sections 7.6.2.
and 9.6. of [RFC3810]). and 9.6. of [RFC3810]).
Experimental tests on Linux and Cisco systems have revealed immediate Experimental tests on Linux and Cisco systems have revealed immediate
skipping to change at page 18, line 32 skipping to change at page 18, line 47
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-03.
1. Clarifications and editorial improvements in response to WG
feedback.
2. Added pointers and explanations to Explicit Tracking and GRE
tunneling in the IPv4 scenario (RFC 5845).
The following changes have been made from version
draft-ietf-multimob-pmipv6-base-solution-02. draft-ietf-multimob-pmipv6-base-solution-02.
1. Clarifications and editorial improvements in response to WG 1. Clarifications and editorial improvements in response to WG
feedback. feedback.
The following changes have been made from version 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.
 End of changes. 20 change blocks. 
39 lines changed or deleted 78 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/