Mobility for IPv4 WG (mip4)
Mobility for IPv4 WG (mip4)
THURSDAY, November 10, 2005, 1300-1500
-
CHAIRS:
-
Henrik Levkowetz <henrik@levkowetz.com>
Pete McCann <mccap@lucent.com>
AGENDA:
draft-ietf-mip4-rfc3344bis
New revision submitted right before the meeting. Next: Chair writeup and
publication request
-
Comments:
-
-
Henrik:
-
Charlie submitted a new version before the meeting. One request for a new
error number was done.
-
Charlie:
-
submitted the weekend before the deadline but it has been on the website for
a month and there has been no change.
-
Vijay:
-
the target is draft standard?
-
Pete:
-
we had some subsequent technical changes therfore we need to recycle to
proposed.
-
Henrik: Yes, we had indicated draft standard but people need to be
-
aware that we have done changes.
Vijay: not exactly sure what changes were made?
-
draft-ietf-mip4-vpn-problem-solution
-
Ready for WG last call
-
draft-ietf-mip4-dynamic-assignment
-
Waiting for AD Go-Ahead::AD Followup
-
draft-ietf-mip4-faerr
-
Waiting for AD Writeup
-
draft-ietf-mip4-reg-tunnel
-
AD Evaluation::Revised ID Needed
This draft has an Appendix which the authors don't agree on how to handle.
We've had an independent review of the Appendix too, and need to decide what to
do with it.
-
Comments:
-
-
Henrik:
-
Had a long and painful story. We may be splitting up the draft into an
appendix and the main part and then do the appendix as informational.
-
draft-ietf-mip4-rfc3012bis
-
Waiting for AD Writeup
Several reviews done for AD, Need to decide whether to fork off the Generalized
Mobile IP Authentication Extension as a separate draft.
-
Comments:
-
Henrik: Jayshree is doing the few changes..
-
draft-ietf-mobileip-lowlatency-handoffs-v4
-
IESG Evaluation::AD Followup
(Just re-submitted by Karim, ready to go to RFC Editor)
-
Comments:
-
Henrik: has been approved.
-
draft-ietf-mip4-rfc2006bis
-
MIP-centric review done, new revision needed
-
Comments:
-
-
Henrik:
-
Kent is going to do the review alone or with help. Hopefully ready for MIB
doctor.
draft-ietf-mip4-experimental-messages RFC 4064
draft-ietf-mip4-vpn-problem-statement RFC 4093
-
Comments:
-
Henrik: that is nice.
http://mip4.org/charter/mip4-charter-2005-09-08.html
Comments:
-
Henrik:
-
Did not get to the IESG slate. No indication of negative results. If you have
comments, this is your last chance. We have a new work items that will make
into charters. Until that is cleared, we will not take new work items. There
are some presentation are here for addition to the charter but that is the
bottomline at this point.
Status summary, open issues:
draft-bharatia-mip4-gen-ext 5 min Kent
-
Presentation:
-
http://www3.ietf.org/proceedings/05nov/slides/mip4-2.pdf
Presentation by Kuntal.
The draft aims to send conf info from HA to the mobile during the initial
exchange.
Changes from -00 to -01 is formatting of configuration parameter based on DHCP
options, no longer MIP-specific
Also allows the MN to request config info from the home or visited network and
that at the same time if needed.
Here we reuse DHCP codes so you don't have to define new subtypes. Adopted the
DHCP option code structure and formatting.
received some comments on the mailing list and updated the draft based on that.
A generic extension to be used for the method was shown, including type, length,
entity-type (distinguishing between FA ad HA), and config data (conf parameters
are packed here).
an exampel of config parameters were shown.
open issues:only DHCP based parameters are considered. Do we have to define
non-DHCP parameters?
-
Comments:
-
-
Sri:
-
You may also need a default realm for DNS queries.
-
Pres:
-
You can basically piggyback DHCP info with this.
-
Henrik:
-
Can we define this as DHCP-only information and if we need non-DHCP we define
a different extension for that later.
-
Kuntal:
-
good idea
-
Yoshi:
-
DHCP option length
-
Kuntal:
-
If all the option are going to fit in one or multiple NVSE.
-
Kent:
-
We have talked among ourself on what to do with the DHCP versus non-DHCP, we
think we should built that at subtype level rather at type level.
Henrik: either way works for me.
draft-devarapalli-mip4-mobike-connectivity 5 min ???
Presentation:
http://www3.ietf.org/proceedings/05nov/slides/mip4-3.pdf
Presented by Vijay:
Brief update from 00 to 01:
01 has been submitted with not many changes, some based on Jari and TJ's
reviews.the target is going to a BCP doc. some additions on when this mechanism
is used. the idea is use this for IKEV2. and IKEv1 reference was removed.
draft-sastry-mip4-string-extension 5 min Kent
Presentation:
http://www3.ietf.org/proceedings/05nov/slides/mip4-0.pdf
Presented by Kent:
Update since version 00:
update to 02 some changes regarding the revocation messages. Changes on the use
of message string extension, correction to security considerations. Some changes
based on TJ's comment and addressed most of the issues.
Can we have some comments? it seems to be pretty straight forward and should go
to last call.
draft-nakhjiri-radius-mip4 5 min Madjid
Presentation:
http://www3.ietf.org/proceedings/05nov/slides/mip4-1.pdf
Presented by Madjid:
Update since version 01:
Clean up of the attribute section.
Review from Jari Arkko. There was a question on why the registration request was
being hashed. this was to avoid the attribute size issue in the future if the
reg. req gets too big.
Diameter can tell whether you are dealing with a HA or a FA. for RADIUS you can
do this only by some information in the attributes. Something new is needed. A
new MIP-Agent type
Some work remaining. More details on Diameter AVP-RADIUS attribute translations
Issue with MN-AAA authenticator and MFCE. please fix 3012bis.
Comments:
-
Vijay:
-
Don't agree with CCoA mode calculation in 3012bis draft
-
Kent:
-
Discusses already on WG. Folks agree there are 2 solutions in RFC 3012.
-
Henrik:
-
Take it to the WG alias.
-
Henrik:
-
We've had quite a bit of discussion with RADEXT chair and need to make clear
what we are doing here and how we separate that from what it is done in
Diameter. There should be a doc on this.
draft-koodli-fmipv4 5 min ???
Nothing to go over here.
Taking on some work in this area has been discussed earlier, during IETF-62. The
question has been raised by some people again, in view of the work on MIPv6 over
IPv4 and IPv4 over MIPv6 which is being done in the MIP6 working group.
Comments:
-
Henrik:
-
Authors have asked to reconsider this again. He likes to ask for a HUMMM on
which way to go. No decision is to be done here.
-
Hesham:
-
The aim is to allow the operator to do IPv6 over MIPv4 and a similar work is
done in MIPv6.
Kent agrees.
-
Vijay:
-
I like to discourage these sort of things in general. It is better to move on
to IPv6 rather to do run things this way.
-
Henrik:
-
Not everybody agrees plus there are specific cases that you simply cannot do
it.
-
Hesham:
-
Philosophically is better not to force people on these things.
-
Rajeev K:
-
questions what is the relation between this and the traversal work in MIPv6.
-
Henrik:
-
this only deals with MIpv4 and not MIPv6 and that is why.
-
Kent:
-
the goal is to use one signaling protocol.
-
Pete:
-
chair hat off, I submitted this draft a while ago. It makes sense IPv6 over
MIPv4.
-
Vijay:
-
personal experience. Operators are willing and want to move to IPv6.
-
Henrik:
-
we are not proposing people to not move to IPv6 here. for information only how
many people want to take this or not to take this on. The HUMM for for is
stronger than the HUMM against.
-
Mohan:
-
Scope of work?
-
Chairs:
-
Both drafts.
-
Related drafts:
-
draft-tsirtsis-v4v6-mipv4
draft-larsson-v6ops-mip-scenarios
-
-
GRE Key Extension for Mobile IPv4 10 min Parviz
-
draft-yegani-gre-key-extension
GRE (Generic Routing Encapsulation) [ RFC 2784 ] is one of the encapsulation
formats permitted by RFC 3344. GRE may use keys to distinguish different tunnels
from each other. [RFC 2890]. This draft proposes a MIPv4 extension to communicate
GRE keys between MIPv4 tunnel endpoints when requesting GRE tunnelling for MIPv4
traffic.
Parviz presented.
3344 optionally supports GRE tunneling. The proposal is to allow this
tunneling.
there is a need for subscribers who are home in 3GPP. YOu cannot really
distinguish between traffic streams based on HoA, CoA. So we need a new
extension.
The idea is to allow both HA and FA to assign different keys (assymetric).
There are situations that these keys can be available to HA and FA.
But in 3344 the MN can set the G bit. Here we should be able to based on policy
overwrite the G-bit setting and request a GRE tunneling.
Henrik: clarification, we are talking about GRE key, not encryption key.
Mohan: is it for FA CoA or colocated mode
-
Parviz: no for both.
-
This is for FA CoA mode only.
Parviz: the HA can assign two addresses to the same subscriber because it is
private addresses.
back to presentation: GRE key assgnment is outside of the scope. The behavior
of FA is new, the G-bit overwriting is not the in RFC. The impact is that key
allocated by the FA can be used for FA-to-HA use.
No changes to the MN behaviour.
Questions/ comments/ working group item?
-
Comments:
-
-
Kent:
-
good idea. When HA is wholesale, this is a good idea. Today the only
solution is to have different instances of HAs.
-
Pete:
-
I like the idea, it is done 3GPP2. But not comfortable with G-bit
overwrite.
-
Parviz:
-
the final decision is by the HA and the HA can reject and finally have a
different tunneling.
-
Henrik:
-
what happens to MN-HA-AE if you can the G-bit?
-
Parviz:
-
G-bit in the GRE extension is not changed.
-
Kuntal:
-
why would the MN care whether you are GRE or not? why does have to be
based on MN request.
-
Kent:
-
when the tunnel is between FA and HA, what is the role of MN? this is
breaking the paradigm of the 3344.
-
Sri:
-
consistent. The extension is added by the FA.
-
Parviz:
-
which entity should assign those keys, FA or HA or both.
-
Kuntal:
-
both. the key that FA wants to receive should be specified by the FA and
the one HA wants should be assigned by HA.
-
Kent:
-
Unidirectional and bidirectional should be supported. HA should be able
to assign the keys for both sides.
-
Kuntal:
-
can't see a use case for when we want the HA to allocate both.
-
Pete:
-
receiver should allocate the key.
-
Kent:
-
agree, it is ok for the HA to allocate the key, technically.
-
Henrik:
-
may simplify what FA wants to do, but does not simplify the FA code.
-
Kent:
-
don't think implementation pov either way is harder.
-
Kuntal:
-
should we really have to have both optoins in the draft.
-
Henrik:
-
proposing to have the receiver assign the keys.
-
Kent:
-
Agree with everything but it does not hurt to add it and make it
optional.
-
Kuntal:
-
how does the FA know what sort HA is it talking to.
-
Henrik:
-
Kent to propose some text and take it to the list.
draft-deng-mip4-generic-notification-message-00.txt
This document proposes a protocol enhancement that allows Mobile IPv4 entities to
asynchronously send and receive explicit notification messages. The Registration
Revocation mechanism of RFC 3543 could have been specified using a message such as
the one proposed here, had it been available at the time.
Presented by Hui
Presentation:
in some cases, there is a need for MIPv4 entities to send and rx asynch
notification events during a session. 3344 does not provide specification for
this.
This doc defines generic message and notification model for this process.
does not define specific notification extensions.
some examples are presented.
HA initiates a notfication to MN, FA initiates a notification to MN, another
case.
Generic notification msg send by mobility agent to inform another mobility agent
or a MN.
3 flags were defined
flag A, bit identifies if ack to the notification msg is need. other fields of
the message were defined.
issues: to discuss whether a notification MUST be acked and whether the use of
flag is good or not.
issue 2: R bit in Agent advertisement
usage examples were presented:
registration revocation, asynch. user notification (out of credit, coming service
interruption), asynch MN or agent notification, may be necessary for high
availability scenarios with long reg. life times.
-
Comments:
-
-
Henrik:
-
comments on the issues and the general idea
-
Kuntal:
-
similar in MIP6 regarding HA switch. I think this is a good idea, but I am
struggling with the use cases and who will be doing this. Why would you
notify the HA when the system is going down, and create more traffic.
-
Hui:
-
Just one BS with access channel in cellular won't cause that much traffic.
-
Henrik:
-
you are not sending 1 Million notification, it is good idea to cover in the
draft for planned maintenance, when you notify that you want to take the HA
down in so and so hour.
-
Kuntal:
-
still you may have thousands of MNs maintained by HA, still that is a lot of
messages.
-
Henrik:
-
This a small subpercentage of the overall traffic.
-
Kuntal:
-
why not use reg. revoke. why this one?
-
Henrik:
-
Are you supposing that we should do this using another message? don't agree.
-
Kuntal:
-
reg. revoke is done today.
-
Kent:
-
make this optional, not mandatory.
-
Henrik:
-
We should put our foot down and say no if we think something is causing a lot
of problem (personal opinion).
-
Hui:
-
3GPPX wants to use SIP SDP for this.
-
Parviz:
-
not sure I can see the use case scenario for this.
-
Hui:
-
the real scenario is HA switch.
-
Sri:
-
don't focus on where it is used, but focus on whether this is useful or not.
example is prepaid.
-
Kuntal:
-
last comment on prepaid and people use text messages for that purpose. HA has
no business sending notification to the MN when account is up. for MN-FA
notifications you would need specific bootstrapping methods. If something is
already solved in the industry we don't try to go and design a new solution.
-
Kent:
-
right now the revocation only goes to FA, but not to the MN, so it may not be
the right way to do it but we do have a MN-HA association. In deployments
people don't completely shut doewn the HA anyway, but if you want to do that
more power to you.
draft-jee-mip4-fh80216e
IEEE 802.16e is an amendment of 802.16 ("WiMAX") which extends it from fixed
terminals only to fixed and mobile operation. This document describes how Mobile
IPv4 Fast Handover can be used IEEE 802.16e link layers.
Presented by Junghoon.
-
Presentation:
-
rfc 4068 is a work item (FMIPv4), so he proposes fmipv4 over 16. some of
related work is done in MIPshop, so he is mentioning. some mobility is done in
layer 2. predictive and reactive (??) modes were discussed.
Is there interest in this work? is this a topic for this working group?
-
Comments:
-
-
Pete:
-
the problem is that FMIPv6 over X is supported in MIPSHOP, but they have
strict charter on v6. Should we get into FMIP stuff here?
-
Rajeev:
-
True, may be it should be here.
-
Parviz:
-
why just 16e? should be FMIPv4 over anything?
-
Pete:
-
you need to take the specifics of the link to make it working.
-
Hannes:
-
it is good stuff.
-
Kent:
-
it is interesting.
-
Henrik:
-
I can predict problems down the line when we want to go for publication.
draft-srinivasa-mip4-mir-00.txt
This document defines enhancements that allow a MN, when away from home, to
simultaneously use multiple connected network interfaces so as to obtain higher
aggregated bandwidth.
-
Henrik:
-
Author is not here. it is interesting work. uses multiple interfaces to stream
videos to remote villages in India because the existing cellular systems and it
is actual deployment. It is mature for adoptions. As an example of what you can
do in a multiple interface scenarios.
|