[multimob] Comments on draft-ietf-multimob-pmipv6-base-solution-01.txt
Behcet Sarikaya <behcetsarikaya@yahoo.com> Wed, 26 May 2010 00:34 UTC
Return-Path: <behcetsarikaya@yahoo.com>
X-Original-To: multimob@core3.amsl.com
Delivered-To: multimob@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 462513A6BA9 for <multimob@core3.amsl.com>; Tue, 25 May 2010 17:34:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.834
X-Spam-Level: ***
X-Spam-Status: No, score=3.834 tagged_above=-999 required=5 tests=[BAYES_99=3.5, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wnJpi7gFPKO for <multimob@core3.amsl.com>; Tue, 25 May 2010 17:34:50 -0700 (PDT)
Received: from web111411.mail.gq1.yahoo.com (web111411.mail.gq1.yahoo.com [67.195.15.192]) by core3.amsl.com (Postfix) with SMTP id C12C73A7791 for <multimob@ietf.org>; Tue, 25 May 2010 15:41:30 -0700 (PDT)
Received: (qmail 41113 invoked by uid 60001); 25 May 2010 22:41:19 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1274827279; bh=80Lf1Z/ZAuM2r9+dxquVAdeqXh7bhCj8+VKZulkSZmU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=f31//W2IiKV2nSPBUb4v0f03hmphDE6yWuDkugN1IqCFT2N5yaIFWrNaR8W3XJGS+ybR50exDvx1A/6dqzBXnSADZeV8Y+k/fVaNc1j6lqHU+4gwcM5OdFg9dbsRdTbNSF1IWUV/bVruxNi9cFROlScUmafXyrwz066xzzuYC5Y=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=c8EfAj5OEx7gBiUBxTLyvF5g9FEkJO9mbova6ANRauq2ieCm5hcp34BJT7MgWMYx82RP7rU2Kew7WTyeSZrk1qbe6mghCMi71IiNr3J03/aQr3rqStm3k+3AkVK6ifdlKcZ+x5zjZnaOLiz15Dm468sZBNFd/B1lKvQ4phWXzQM=;
Message-ID: <617906.39969.qm@web111411.mail.gq1.yahoo.com>
X-YMail-OSG: Hc.aUQUVM1mE5fmXsohw3myM5Psctqo8EPPfnTOgzDlwlsc skpoFI7dkr6Kgu4iTmwVANG8F_oSReJYru0qrvfLSeLbcx7JNTBGuPaA6XKW vXtB07mpnxrrreH_GdVSLEgL2xyfJnKQZchf.s7OLJ8nekQbSDuw5lgDiS0p irVpJth9ZXnp2ioYW.WufXEjUMDBoAihV6kCjAQTGgYbgLzS31WfsoE75dht vPud5g1wQlXBrcbPA8D5IQP6VJPGkEvi7it8GkQpmRbo2VyFmug68JSOEttg gypOH.PESOkhOU3gd5LxX0Mk3RlmThv8Q5lq.vdELV6IZcf3CoRXN8jRcU0b uMZvVEXJj1fLlNXE-
Received: from [206.16.17.212] by web111411.mail.gq1.yahoo.com via HTTP; Tue, 25 May 2010 15:41:19 PDT
X-Mailer: YahooMailRC/374.4 YahooMailWebService/0.8.103.269680
References: <20100525194501.E676E3A6970@core3.amsl.com>
Date: Tue, 25 May 2010 15:41:19 -0700
From: Behcet Sarikaya <behcetsarikaya@yahoo.com>
To: multimob@ietf.org
In-Reply-To: <20100525194501.E676E3A6970@core3.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: [multimob] Comments on draft-ietf-multimob-pmipv6-base-solution-01.txt
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Behcet Sarikaya <sarikaya@ieee.org>
List-Id: Multicast Mobility <multimob.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/multimob>, <mailto:multimob-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multimob>
List-Post: <mailto:multimob@ietf.org>
List-Help: <mailto:multimob-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multimob>, <mailto:multimob-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 May 2010 00:34:52 -0000
Hi Thomas, My comments below. Regards, Behcet Abstract This document describes deployment options for activating multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards. Similar to Home Agents in Mobile IPv6, PMIPv6 Local Mobility Anchors serve as multicast s/PMIPv6/Proxy Mobile IPv6 subscription anchor points, while Mobile Access Gateways provide MLD s/MLD/Multicast Listener Discovery proxy functions. In this scenario, Mobile Nodes remain agnostic of multicast mobility operations. 1. Introduction Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 [RFC3775] by network-based management functions that enable IP mobility for a host without requiring its participation in any mobility-related signaling. Additional network entities called the Local Mobility Anchor (LMA), and Mobile Access Gateways (MAGs), are responsible for managing IP mobility on behalf of the mobile node (MN). With these entities in place, the mobile node looses transparent end- to-end connectivity to the static Internet, and in the particular case of multicast communication, group membership management as signaled by the Multicast Listener Discovery protocol [RFC3810], [RFC2710] requires dedicated treatment at the network side, see [I-D.deng-multimob-pmip6-requirement]. [Behcet] Replace this ref with a more recent draft, e.g. draft-von-hugo-multimob-future-work Multicast routing functions need to be placed carefully within the PMIPv6 domain to augment unicast transmission with group s/PMIPv6/Proxy Mobile IPv6 communication services. [RFC5213] does not explicitly address multicast communication and relies on the minimal multicast support provided by MIPv6. But unfortunately bi-directional home tunneling, the minimal multicast support arranged by MIPv6, cannot be applied in network-based management scenarios, since a mobility-unaware node will not initiate such a tunnel after movement. [behcet] The above paragraph needs to be rewritten to state that PMIPv6 does not explicitly address multicast communication. It was a choice to design multicast extension for PMIPv6 similar to MIPv6 but due to the inefficiencies involved in bi-directional home tunneling a proxy based solution described in this document has instead been opted for. [behcet] please add several sentences on why proxy approach is better (as has been discussed on ML). This document describes options for deploying multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards. Similar to Home Agents in Mobile IPv6, PMIPv6 Local Mobility Anchors serve as multicast subscription anchor s/PMIPv6/Proxy Mobile IPv6 (everywhere) points, while Mobile Access Gateways provide MLD proxy functions. s/MLD/Multicast Listener Discovery (everywhere) Mobile Nodes in this scenario remain agnostic of multicast mobility operations. This document does not address specific optimizations and efficiency improvements of multicast routing for network-based mobility discussed in [RFC5757], as such solutions would require changes to the base PMIPv6 protocol [RFC5213]. s/PMIPv6/Proxy Mobile IPv6 2. Terminology This document uses the terminology as defined for the mobility protocols [RFC3775] and [RFC5213], as well as the multicast edge related protocols [RFC3810] and [RFC4605]. [behcet] add RFC 5844 and IGMP RFCs 3. Overview The reference scenario for multicast deployment in Proxy Mobile IPv6 s/scenario/network domains is illustrated in Figure 1. An MN in a PMIPv6 domain will decide on multicast group membership s/MN/mobile node (everywhere) management completely independent of its current mobility conditions. It will submit MLD Report and Done messages, based on application triggers, using its link-local source address and multicast destination addresses according to [RFC3810], or [RFC2710]. These link-local signaling messages will arrive at the currently active MAG via one of its downstream local (wireless) links. A multicast unaware MAG would simply discard these MLD messages. To facilitate multicast in a PMIPv6 domain, an MLD proxy function [RFC4605] needs to be deployed on the MAG that selects the tunnel interface corresponding to the MN's LMA for its upstream interface s/LMA/Local Mobility Anchor (everywhere) (cf., section 6 of [RFC5213]). Thereby, each MAG-to-LMA tunnel s/MAG/Mobile Access Gateway (everywhere) interface defines an MLD proxy domain at the MAG, and it contains all downstream links to MNs that share this specific LMA. According to standard proxy operations, MLD Report messages will be forwarded under aggregation up the tunnel interface to its corresponding LMA. Serving as the designated multicast router or an additional MLD proxy, the LMA will transpose any MLD message from a MAG into the multicast routing infrastructure. Correspondingly, the LMA will create appropriate multicast forwarding states at its tunnel interface. Traffic arriving for subscribed groups will arrive at the LMA, and the LMA will forward this traffic according to its group/ source states. In addition, the LMA will act as an MLD querier, seeing its downstream tunnel interfaces as multicast enabled links. At the MAG, MLD queries and multicast data will arrive on the (tunnel) interface that is assigned to a group of access links as identified by its Binding Update List (cf., section 6 of [RFC5213]). As specified for MLD proxies, the MAG will forward multicast traffic and initiate related signaling down the appropriate access links to the MNs. Hence all multicast-related signaling and the data traffic will transparently flow from the LMA to the MN on an LMA-specific tree, which is shared among the multicast sources. In case of a handover, the MN (unaware of IP mobility) will not send unsolicited MLD reports. Instead, the MAG is required to maintain group memberships in the following way. On observing a new MN on a downstream access link, the MAG sends a General MLD Query. Based on its outcome and the multicast group states previously maintained at the MAG, a corresponding Report will be sent to the LMA aggregating group membership states according to the proxy function. Additional Reports can be omitted when the previously established multicast forwarding states at the new MAG already cover the subscriptions of the MN. In summary, the following steps are executed on handover: 1. The MAG-MN link comes up and the MAG discovers the new MN. 2. Unicast address configuration and PMIPv6 binding are performed after the MAG determines the corresponding LMA. 3. Following IPv6 address configuration, the MAG SHOULD send an (early) MLD General Query to the new downstream link as part of its standard multicast-enabled router operations. 4. The MAG SHOULD determine whether the MN is admissible to multicast services, and stop here otherwise. 5. The MAG adds the new downstream link to the MLD proxy instance with up-link to the corresponding LMA. 6. The corresponding Proxy instance triggers an MLD General Query on the new downstream link. 7. The MN Membership Reports arrive at the MAG, either in response to the early Query or to that of the Proxy instance. 8. The Proxy processes the MLD Report, updates states and reports upstream if necessary. After Re-Binding, the LMA is not required to issue a General MLD Query on the tunnel link to refresh forwarding states [behcet]unless there was a change in the aggregate state. Multicast state updates SHOULD be triggered by the MAG, which aggregates subscriptions of all its MNs (see the call flow in Figure 2). These multicast deployment considerations likewise apply for mobile nodes that operate with their IPv4 stack enabled in a PMIPv6 domain. PMIPv6 can provide IPv4 home address mobility support [RFC5844]. Such mobile nodes will use IGMP [RFC2236],[RFC3376] signaling for multicast, which is handled by an IGMP proxy function at the MAG in an analogous way. Following these deployment steps, multicast management transparently inter-operates with PMIPv6. It is worth noting that multicast streams can possibly be distributed on redundant paths that lead to duplicate traffic arriving from different LMAs at one MAG, and can cause multiple data transmissions from an MAG over one wireless domain to different MNs. [behcet] This is called tunnel convergence problem, see Appendix C for further considerations. (see Appendix C for further considerations). [behcet] maybe remove 4. Deployment Details Multicast activation in a PMIPv6 domain requires to deploy general multicast functions at PMIPv6 routers and to define its interaction with the PMIPv6 protocol in the following way: 4.1. Operations of the Mobile Node A Mobile Node willing to manage multicast traffic will join, maintain and leave groups as if located in the fixed Internet. No specific mobility actions nor implementations are required at the MN. 4.2. Operations of the Mobile Access Gateway A Mobility Access Gateway is required to assist in MLD signaling and s/Mobility Access Gateway/Mobile Access Gateway data forwarding between the MNs which it serves, and the corresponding LMAs associated to each MN. It therefore needs to implement an instance of the MLD proxy function [RFC4605] for each upstream tunnel interface that has been established with an LMA. The MAG decides on the mapping of downstream links to a proxy instance (and hence an upstream link to an LMA) based on the regular Binding Update List as maintained by PMIPv6 standard operations (cf., section 6.1 of [RFC5213]). As links connecting MNs and MAGs change under mobility, MLD proxies at MAGs MUST be able to dynamically add and remove downstream interfaces in its configuration. On the reception of MLD reports from an MN, the MAG MUST identify the corresponding proxy instance from the incoming interface and perform regular MLD proxy operations: it will insert/update/remove multicast forwarding state on the incoming interface, and will merge state updates into the MLD proxy membership database. It will then send an aggregated Report to the upstream tunnel to the LMA when the membership database (cf., section 4.1 of [RFC4605]) changes. Conversely, on the reception of MLD Queries, the MAG proxy instance will answer the Queries on behalf of all active downstream receivers maintained in its membership database. Queries sent by the LMA do not force the MAG to trigger corresponding messages immediately towards MNs. Multicast traffic arriving at the MAG on an upstream interface will be forwarded according to the group/source-specific forwarding states as acquired for each downstream interface within the MLD proxy instance. At this stage, it is important to note that IGMP/MLD proxy implementations capable of multiple instances are expected to closely follow the specifications of section 4.2 in [RFC4605], i.e., treat proxy instances in isolation of each other while forwarding. After a handover, the MAG will continue to manage upstream tunnels and downstream interfaces as specified in the PMIPv6 specification. It MUST dynamically associate new access links to proxy instances that include the upstream connection to the corresponding LMA. The MAG detects the arrival of a new MN by receiving a router solicitation message and by an upcoming link. To learn about multicast groups subscribed by a newly attaching MN, the MAG SHOULD send a General Query to the MN's link. Querying an upcoming interface is a standard operation of MLD queriers (see Appendix A) and is performed immediately after address configuration. In addition, an MLD query SHOULD be initiated by the proxy instance, as soon as a new interface has been configured for downstream. In case, the access link between MN and MAG goes down, interface-specific multicast states change. Both cases may alter the composition of the membership database and this will trigger corresponding Reports towards the LMA. Note that the actual observable state depends on the access link model in use. An MN may be unable to answer MAG multicast membership queries due to handover procedures, or its report may arrive before the MAG has configured its link as proxy downstream interface. Such occurrences are equivalent to a General Query loss. To prevent erroneous query timeouts at the MAG, MLD parameters SHOULD be carefully adjusted to the mobility regime. In particular, MLD timers and the Robustness Variable (see section 9 of [RFC3810]) MUST be chosen to be compliant with the time scale of handover operations and proxy configurations in the PMIPv6 domain. In proceeding this way, the MAG is able to aggregate multicast subscriptions for each of its MLD proxy instances. However, this deployment approach does not prevent multiple identical streams arriving from different LMA upstream interfaces.Furthermore, a multipoint channel forwarding into the wireless domain is prevented by the point-to-point link model in use. 4.3. Operations of the Local Mobility Anchor 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 corresponding MAG. It implements the function of the designated multicast router or a further MLD proxy. According to MLD reports received from a MAG (on behalf of the MNs), it establishes/maintains/ removes group/source-specific multicast forwarding states at its corresponding downstream tunnel interfaces. At the same time, it procures for aggregated multicast membership maintenance at its upstream interface. Based on the multicast-transparent operations of the MAGs, the LMA treats its tunnel interfaces as multicast enabled downstream links, serving zero to many listening nodes. Multicast traffic arriving at the LMA is transparently forwarded according to its multicast forwarding information base. s/information base/database (?) After a handover, the LMA will receive Binding De-Registrations and Binding Lifetime Extensions that will cause a re-mapping of home network prefix(es) to a new Proxy-CoA in its Binding Cache (see section 5.3 of [RFC5213]). The multicast forwarding states require updating, as well, if the MN within an MLD proxy domain is the only receiver of a multicast group. Two different cases need to be considered: 1. The mobile node is the only receiver of a group behind the interface at which a De-Registration was received: The membership database of the MAG changes, which will trigger a Report/Done sent via the MAG-to-LMA interface to remove this group. The LMA thus terminates multicast forwarding. 2. The mobile node is the only receiver of a group behind the interface at which a Lifetime Extension was received: The membership database of the MAG changes, which will trigger a Report sent via the MAG-to-LMA interface to add this group. The LMA thus starts multicast distribution. In proceeding this way, each LMA will provide transparent multicast support for the group of MNs it serves. It will perform traffic aggregation at the MN-group level and will assure that multicast data streams are uniquely forwarded per individual LMA-to-MAG tunnel. 4.4. IPv4 Support An MN in a PMIPv6 domain may use an IPv4 address transparently for communication as specified in [RFC5844]. For this purpose, LMAs can register IPv4-Proxy-CoAs in its Binding Caches and MAGs can provide IPv4 support in access networks. Correspondingly, multicast membership management will be performed by the MN using IGMP. For multicast support on the network side, an IGMP proxy function needs to be deployed at MAGs in exactly the same way as for IPv6. [RFC4605] defines IGMP proxy behaviour in full agreement with IPv6/ MLD. Thus IPv4 support can be transparently provided following the obvious deployment analogy. For a dual-stack IPv4/IPv6 access network, the MAG proxy instances SHOULD choose multicast signaling according to address configurations on the link, but MAY submit IGMP and MLD queries in parallel, if needed. It should further be noted that the infrastructure cannot identify two data streams as identical when distributed via an IPv4 and IPv6 multicast group. Thus duplicate data may be forwarded on a heterogeneous network layer. [behcet] Add here one paragraph on NAT issue and a reference to RFC 5135 4.5. Multihoming Support An MN can connect to a PMIPv6 domain through multiple interfaces and experience transparent unicast handovers at all interfaces (cf., section 5.4 of [RFC5213]). In such simultaneous access scenario, it can autonomously assign multicast channel subscriptions to individual interfaces. While doing so, multicast mobility operations described in this document will transparently preserve the association of channels to interfaces in the following way. Multicast listener states are kept per interface in the MLD state table. An MN will answer to an MLD General Query received on a specific (re-attaching) interface according to the specific interface's state table. Thereafter, multicast forwarding is resumed for channels identical to those under subscription prior to handover. Consequently, an MN in a PMIPv6 domain MAY use multiple interfaces to facilitate load balancing or redundancy, but cannot follow a 'make- before-break' approach to service continuation on handovers. 4.6. Multicast Availability throughout the Access Network There may be deployment scenarios, where multicast services are available throughout the access network independent of the PMIPv6 infrastructure. Direct multicast access at MAGs may be supported through native multicast routing, within a flat access network that includes a multicast router, via dedicated (tunnel or VPN) links between MAGs and designated multicast routers, or by deploying AMT [I-D.ietf-mboned-auto-multicast]. Multicast deployment can be simplified in these scenarios. A single proxy instance at MAGs with up-link into the multicast cloud, for instance, could serve group communication purposes. MAGs could operate as general multicast routers or AMT gateways, as well. Common to these solutions is that mobility management is covered by the dynamics of multicast routing, as initially foreseen in the Remote Subscription approach sketched in [RFC3775]. Care must be taken to avoid service disruptions due to tardy multicast routing operations, and to adapt to different link-layer technologies [RFC5757]. The different possible approaches should be carefully investigated. Such work is beyond the scope of this document. 4.7. A Note on Explicit Tracking IGMPv3/MLDv2 [RFC3376], [RFC3810] may operate in combination with explicit tracking, which allows routers to monitor each multicast receiver. This mechanism is not standardized yet, but widely implemented by vendors as it supports faster leave latencies and reduced signaling. Enabling explicit tracking on downstream interfaces of the LMA and MAG would track a single MAG and MN respectively per interface. It may be used to preserve bandwidth on the MAG-MN link. 5. Message Source and Destination Address This section describes source and destination addresses of MLD messages. The interface identifier A-B denotes an interface on node A, which is connected to node B. This includes tunnel interfaces. 5.1. Query +===========+================+======================+==========+ | Interface | Source Address | Destination Address | Header | +===========+================+======================+==========+ | | LMAA | Proxy-CoA | outer | + LMA-MAG +----------------+----------------------+----------+ | | LMA-link-local | [RFC2710], [RFC3810] | inner | +-----------+----------------+----------------------+----------+ | MAG-MN | MAG-link-local | [RFC2710], [RFC3810] | -- | +-----------+----------------+----------------------+----------+ [behcet] add IGMP case as well with IPv4-LMAA, etc. s/[RFC2710], [RFC3810]/multicast group address 5.2. Report/Done +===========+================+======================+==========+ | Interface | Source Address | Destination Address | Header | +===========+================+======================+==========+ | MN-MAG | MN-link-local | [RFC2710], [RFC3810] | -- | +-----------+----------------+----------------------+----------+ | | Proxy-CoA | LMAA | outer | + MAG-LMA +----------------+----------------------+----------+ | | MAG-link-local | [RFC2710], [RFC3810] | inner | +-----------+----------------+----------------------+----------+ [behcet] add IGMP case as well with IPv4-LMAA, etc. s/[RFC2710], [RFC3810]/multicast group address 7. Security Considerations This draft does not introduce additional messages or novel protocol operations. Consequently, no new threats are introduced by this document in addition to those identified as security concerns of [RFC3810], [RFC4605], [RFC5213], and [RFC5844]. However, particular attention should be paid to implications of combining multicast and mobility management at network entities. As this specification allows mobile nodes to initiate the creation of multicast forwarding states at MAGs and LMAs while changing attachments, threats of resource exhaustion at PMIP routers and s/PMIP/Proxy Mobile IPv6 access networks arrive from rapid state changes, as well as from high volume data streams routed into access networks of limited capacities. In addition to proper authorization checks of MNs, rate controls at replicators MAY be required to protect the agents and the downstream networks. In particular, MLD proxy implementations at MAGs SHOULD carefully procure for automatic multicast state extinction on the departure of MNs, as mobile multicast listeners in the PMIPv6 domain will not actively terminate group membership prior to departure. 8. Acknowledgements This memo is the outcome of extensive previous discussions and a follow-up of several initial drafts on the subject. The authors would like to thank (in alphabetical order) Luis Contreras, Greg Daley, Gorry Fairhurst, Dirk von Hugo, Seil Jeon, Jouni Korhonen, Guang Lu, Sebastian Meiling, Liu Hui, Imed Romdhani, Behcet Sarikaya, 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 Initiative is gratefully acknowledged. Appendix C. Comparative Evaluation of Different Approaches In this section, we briefly evaluate two basic PMIP concepts for s/PMIP concepts/Proxy Mobile IPv6 scenarios multicast traffic organization at LMAs: In scenario A, multicast is provided by combined unicast/multicast LMAs as described in this document. Scenario B directs traffic via a dedicated multicast LMA as proposed in [I-D.zuniga-multimob-smspmip], for example.
- [multimob] I-D Action:draft-ietf-multimob-pmipv6-… Internet-Drafts
- Re: [multimob] I-D Action:draft-ietf-multimob-pmi… Thomas C. Schmidt
- [multimob] Comments on draft-ietf-multimob-pmipv6… Behcet Sarikaya
- Re: [multimob] I-D Action:draft-ietf-multimob-pmi… Thomas C. Schmidt
- Re: [multimob] Comments on draft-ietf-multimob-pm… Stig Venaas
- Re: [multimob] Comments on draft-ietf-multimob-pm… Thomas C. Schmidt
- Re: [multimob] I-D Action:draft-ietf-multimob-pmi… pierrick.seite
- Re: [multimob] I-D Action:draft-ietf-multimob-pmi… Thomas C. Schmidt
- Re: [multimob] I-D Action:draft-ietf-multimob-pmi… pierrick.seite
- Re: [multimob] I-D Action:draft-ietf-multimob-pmi… Thomas C. Schmidt