MIPSHOP
WG documents review:
- HMIPv6 document: Jari indicated that IESG has cleared the
document after the changes that IESG had suggested, just waiting for WG to
confirm it
- Basic MIH framework is completed.
- For DNS extensions for MIH, it completed the WG last call,
waiting for DNS directorate review still.
- For DHCP extensions we’ll go in WG last call soon, with a
current open issue.
Rechartering status: new charter
text is available. Work includes:
- At least one document on setting up FMIP security
associations using AAA
- PMIPv6 handover optimizations, without referring to any
solutions. Open for discussion in this meeting and in few weeks. Two solutions
currently on the table
one work item coming from MEXT
during their chartering (IP tunneling optimizations)
Presentations:
MIH Discussion
draft-ietf-mipshop-mstp-solution-05
draft-ietf-mipshop-mos-dhcp-options-03
draft-ietf-mipshop-mos-dns-discovery-01
Subir Das
Subir Das presented the slide set
- Proposed
solution
- Alper: this is more generic than MSTP, it should be
done by DHC group
- Chair:
is there a document? If not then we can keep this for the time being
- Jari
Arkko: if we do nothing, the implications vary depending on the data that
are carried
- Roaming
MoS scenario: integrated scenario
- Very
similar to MIPv6 integrated scenario
- Two
approaches presented
- Alper: regarding use of TLS, are the end points of
the protocol in the same admin domain or is there a roaming scenario?
- Subir: yes, there is roaming case and scenario where
server is provided by a 3rd party
- Alper: need then to make sure certificates have a
common root, it’s a large scale deployment issue
- Subir: draft does not go into that detail
- Alper: it can be an issue
- Vijay
Devarapalli: integrated scenario is useful to pass the information to the
mobile node from the home network. A number of protocols can be used to
send the MIH information in access-specific information. Perhaps we can
leave the access-specific mechanism can be left to the specific accesses,
and include only the framework
- Jari
Arkko: bad idea, remove mechanism from appendixes and companion
documents. Whenever we have a new service that needs to be run between
the mobile node and the home network, we cannot expect to have the
visited network changed every time. Issue is mainly with the DHCP part.
- Jari:
to apply this in 3GPP, there is a protocol that can be used for
provisioning (OMA). Why do we need to go through all this trouble?
- Vijay:
OMA being considered in 3GPP not only for bootstrapping MIH, but to
replace MIH.
- Subir: the real question is whether we should support
a bootstrapping integrated scenario
- Jari:
requirement is ok, but there are various ways of doing it and the
proposed way here seems to be causing problems. Other ways may have
issues as well. Reluctant to twist DHCP every time we invent a new
feature
- Subir: similar feature used in other scenarios, e.g.
3GPP2, WiMAX, and WiFi/DSL
- Alper: OMA is designed for provisioning the terminal
for longer lived information, not for configuring this type of
information
- Jari:
here we are not talking about OMA replacing MIH, but to bootstrapping MIH
- Vijay:
MIH information is too short-lived, also the server information
- Subir: listed all scenarios, not clear which
scenarios will be used. This specific scenario is the only one where the
mobile node needs to discover the server. Is this scenario important and
should it be supported?
- Jari:
there is no customer for this, 3GPP has indicated there is a solution for
this
- Alper: if all the attributes could be all bundled
together, the solution could be scalable
- Vijay:
AAA servers are the only ones that will take a look at the options
- Jari:
if info is delivered directly to the mobile node but not the NAS, then it
may work. Need to work on this separately and find out how 802.21 and MIH
are used in the real world, i.e. how it is used
- Subir: where is this done?
- Jari:
probably not in MIPSHOP
- Vijay:
effort in DIME
- Subir: draft submitted, DIME indicated that they can
do it if MIPSHOP needs it
- Jari:
better to indicate there are AAA mechanisms, without indicating where it
is done
Use of FMIPv6 signaling for PMIPv6 handover Optimization
Rajeev Koodli
- Alper: how does the system ensure it is the same
mobile that is connected to the new MAG before forwarding the packets to
the MN?
- Hidetoshi:
when MN gets on new link, authentication takes place
- Rajeev:
rely on access network authentication to do that, not different from
regular FMIP
- Alper: only home network knows it is the home
subscriber. Access network does not know it is the same user, since it can
use a different identity
- Vijay:
when the MN does L2 with the MAG, MAG does authentication with the home
network
- Alper: home network needs to indicate to the new MAG
that this is the MN for which data is cached at the old access
- To be
discussed offline, considering different scenarios
- Vijay:
in PMIPv6 the MAG cannot be IPv4 only. So if the MAG don’t
support IPv6 they are not PMIPv6 MAGs. Better to
indicate that messages are tunneled over IPv4 if there is no IPv6
connectivity
- Rajeev:
ok, also wondering whether IPv4 only processing needed, there seem to be a
need
- Ahmad:
Why not supporting IPv4 HoA?
- Rajeev:
IPv4 HoA can be supported, but signaling must be
IPv6
- Rajeev:
draft used by 3GPP2 for eHRPD-LTE handover
- Vijay:
consensus in the room for WG document? 16 in favor, nobody against it.
This will be confirmed on the mailing list
Use of Transient BCE for PMIPv6 handover optimization
Marco Liebsch
o Rajeev: it
seems that the LMA needs to be able to receive packets from both the previous
MAG and the new MAG. Is it a protocol issue?
o Marco: yes,
it depends on how the protocol is defined
o Rajeev: for
uplink, PMIP is clear on how to updated BCE. If there is an exception, when it
is defined it should be defined how to use it and how to behave. If it is a
deployment aspect, it should be either defined in such framework or done in
implementation
o Ahmad:
issue inherent to all Mobile IP protocols
o Vijay: this
can be achieved without any protocol extensions, just write this document
describing the scenario. When the LMA receives the HI, the LMA may decide to
receive packets from both MAGs, and DL is switched
only when the new MAG is done. Just specify the LMA behavior, without modifying
the protocol
o Ahmad:
seems protocol needs to still be modified
o Vijay: no,
only LMA behavior
o Ahmad: how
does the LMA know how to address the different type of scenarios/traffic?
o Suresh
Krishnan: need indicator on the wire, otherwise how does the LMA differentiate?
This also allows the MAG to indicate whether they indicate the new behavior or
not
o Vijay: why
not buffering in new MAG?
o Marco: does
not mean to modify the underlying architecture (e.g. 3GPP)
o Ahmad: even
if SDO specific, why not accepting it?
o Hidetoshi:
if buffering is possible, there is no need for transient BCE
o Taken
offline
o Alper: timeline for L2 attach, during that period traffic
is forwarded to new target
o Vijay:
consensus in the room for WG document? 10 in favor, 2 against
it. This will be confirmed on the mailing list.