Last Modified: 2005-10-26
NETLMM BOF Monday 1850 Phil Roberts & James Kempf Moto Labs DoCoMo Labs USA Agenda Agenda Bashing 30 minute disucssion of Margaret's questions 6 drafts, 5 mins per draft Kent Leung, Cisco, "NetLMM using Porxy Mobile IPv6" Giaretta, TIM Labs, draft-giaretta-netlmm-protocol-00.txt Mohan Parthanamury Latest Charter http://www.geocities.com/kempf42/netlmm-charter-iesg-revised.txt At the end we will have a discussion on whether this charter is good. Margaret's Questions Chairs added answers that reflect discussion on the list 1. Are there any proposed solutions in this space? A: yes, see drafts cited on agenda and presentations in second half hour There are no wild differences between the proposals. 2. What is the relationship of this proposed work to similar activities in IEEE or other standards bodies? A: AFAWK, there is no work in IEEE on this problem WiMax forum and 3GPP have some ongoing work on mobility management in advanced cellular networks for which NETLMM could be a candidate solution However, neither WiMAx Forum nor 3GPP has formally requested IETF to work on this problem. Thomas: at the last BOF, 3GPP hadn't even decided what their requirements were Hasn't WiMax already settled ? WiMax forum has decided for MIP4. KentLeung: WiMAx forum has decided on MIPv6 in phase 1, but there might be scope for something else in phase 2. 3. How is this related to CAPWAP and / or the L2 mobility management schemes that CAPWAP is based on? A: CAPWAP runs between a WLAN controller and access points Solves problem of control of access points and traff managmenet between access points and controller NETLMM runs between access routers and a mobility anchor Solves problem of localized mobility management within a broader domain potentially covering several CAPWAP controllers Never sees the access points 4. Charter doesn't mention security requirements and/or have any specific deliverables related to security A: The charter says Security will be defined for the protocol based on standard IETF security protocols, but should maintain configuration flexibility for varying deployment circumstances Parviz: this immediately brings to mind different domains Kempf: once you authenticate in the network, the access router and mobility anchor would always be in the same domain. Otherwise security gets complicated. KentLeung: in the WiMax forum network working group: this is R3 interface. Even there there are 2 partitions. One is within a network domain (NETLMM) the other is inter-administrative domain which is what Parviz is talking about. Kempf: don't think it's a very common use case but if people care we can put it in the charter. Gerardo Giaretta: NETLMM is intra-domain, the inter-domain is MObile IP or something else Kempf: right, that's the model we've been working with Hesham: if you look at network-based mobility management protocol, some sort of association between access router and anchor point, it is an absolute nightmare to work it out. It's worth mentioning. It is more scalable to do it between the MS and the anchor. Kempf: I don't see how it would be harder than scaling an SA between two routers. Hesham: it's the same, it doesn't scale. You can always set up security between any 2 routers. As numbers increase, it becomes increasingly harder to manage. There is nothing on the market that can handle a nationwide deployment. Jari: security internal on the tunnels doesn't matter so much, what is important is how this is connected to AAA and authentication of the MNs. We talked about it on the list. Kempf: would be good to add to the charter. We have on the charter how the MN identifies itself to the network, we could add something on security. Parviz: Recently heard from a carrier that they have security issues within their own network. Kempf: Yeah, we have security issues we're working on them. Maybe we should put something into the charter that says we will work on how this is done securely. 5. Are there any specific drafts that are expected to become WG items? A: yes, they are draft-kempf-netlmm-nohost-ps-00.txt - problem statement draft-kempf-netlmm-nohost-req-00.txt - requirements Plan is to update drafts based on list discussion and issue WG last call as soon as the WG is chartered Hesham: question that wasn't asked: if we're looking at a BOF, proposal for WG, The first question should be: what is the problem? The problem statement I've read many times: it says this is how to solve the problem. We need something that says what the problem is without suggesting a method for solving it. Why can't someone just write the problem? It's almost irrelevant how many proposals are out there, there are a lot of reasons why someone would want to change things. Kempf: You're the only person who has this comment. We wrote the problem statement. Hesham: I remember half the room voted on not doing this. Kempf: we got comments, incorporated them in the charter. I know there are other protocols out there. Hesham: not the point, regardless of what's out there, there should be a proper problem statement of what's missing. ThomasNarten: what do you mean "what's missing" Hesham: 10 to 15 years ago, we could say IP telephony needs a solution, would be a good problem statement for SIP. When a mobile moves, it loses its IP address. Would be a good problem statement for MIP. Kempf: did you read the requirements? Hesham: even before that we need the problem statement Raj: the fact is that at the last IETF in Paris there were many people with questions Kempf: ok but nobody else said the problem statement was lacking Raj: what we are saying here is there is a way of doing localized mobility, there are ways for the IETF to address it. What we're saying is there is a better way of doing it. There is no real specific problem: air interface is limited, we don't want to signal... Kempf: the problem statement tries to outline what the problem of network localized mobility management. The requirements and gap analysis Raj: you create the problem based on your assumptions. The fact that you don't want the host to do signaling. Kempf: right, we don't want to do it. Raj: That's an assumption Kempf: let me tell you a little story about a mother who was teaching her son to cook. She cut the two ends off the roast. The kid wanted to know why. She said it was because your grandmother did it. Thomas Narten: the idea that the handset is not to be involved: yes, it defines the solution. But, it also defines the problem. If you have a network that is controlled by a single administrative entity, control over all the devices. If you have to deal with devices at the edge you need to have control over those PhilRoberts: the problem statement does constrain the solution, but not in an unreasonable way. Hesham: That would be a good problem statement, but now there is a preference for a particular solution. That's not the way we work here. PhilRoberts: this argument is off in the weeds. We've got people that want to solve this without touching the mobile. What is the solution for that? Hesham: I wanted us to highlight this point. There's no real problem here. PhilRoberts: what protocol do I use to solve that problem? Raj: I hear what you are saying, a lot of people see the need for the solution. THere are some people who would be interested in deploying this kind of network. PhilRoberts: we have a huge deployment of client=based Mobile IP. But, I can't use that to solve the porblem. WHat protocol do I use to solve the problem? Hesham: we have a client as well that solves this problem. It's doable. mic: you say you don't want to involve the mobile Margaret: we have about 20 minutes left, do people have other opinions? Alper: it would be useful to understand where that requirement of not touching the terminal is coming from. What will happen to SIP, EAP, etc, not just MIPv6 CharlesPerkins: since this WG isn't even formed yet, I'm uncomfortable with saying that documents will go to last call and be sent to the IESG right away. We should take some realistic stock of the situation. Kempf: yeah, we just want people to pay attention. Mohan: I never saw a mail from Hesham saying that the problem statement is bad. Margaret: we need to make 3 separate decisions: 1. Do we want to charter a WG with a charter like this one? 2. Does that group want to accept certain drafts as WG work items? 3. Does the WG believe that they're ready to go to the IESG? There is no specific time gap between which those have to happen. Let's focus this meeting on the 1st question. Kempf: absolutely, that's the intent. We were just trying to answer your question. Kempf: one additional item wanted to add to the charter about looking at security of mobile-to-network protocol. Raise of hands in favor of chartering the working group. About 40 in favor, 15 opposed. Protocol Presentations Gerardo Giaretta draft-giaretta-netlmm-protocol-00 NETLMM with Distributed Anchor Routers Network-based LMM protocol that fulfills the requirements of draft-kempf-netlmm-nohost-req Main requirements considered in the design Req #2: reduction in handover-related signaling volumt Req #4: Efficient use of wireless resources Req #5: reduction of signaling and packet overhead in the wired network The purpose is to use as the basic core network mobility management in 3GPP Replacement for GTP in GPRS Main features: MN keeps the same IP address while moving in the same NETLMM domain Different from other proposals: each router owns its own prefixes and advertises its own prefixe Protocol architecture similar to Mobile IPv6 MN is identified by the IP address CGAs may be used to avoid address ownership issues Flexibility in MAP/HAR allocation May be in an aggregation router May be co-located with Access Routers Optimized support for sensors or "users" with minimal movement ability AR may span a large area (similar to an MSC/SGSN area) Multiple MAPs located in a NETLMM Domain Needed to have a sclaable solution and load balance among them In the draft also Some considerations on MN-AR interface Some ideas about Route Optimization Picture showing routing of data packets Margaret: when we asked about forming the WG, 40-odd people said yea, 15 said no The comments at the mic seemed to say that they don't like the restriction about no handset signaling. I'm trying to understand the objections. Some people are of the opinion that Mobile IP already solves this problem, that we shouldn't have the restriction. Keith Vanderbing: my feeling is that we should not have the restriction that we can't touch the host. Will Atlantic: at least it should be stated why you want to restrict it in the problem statement, otherwise leave it open to multiple implementations. ThomasNarten: it is useful to understand where the objections are coming from. It might be useful to know do people think that there is new work in this space that involves touching the handset? Some people are saying that we have MIP, one thing that NETLMM can work on is a client with no MIP. Kempf: just to clarify about what we mean by not touching the handset: we're not talking about movement detection, we're not talking about network attachemnt; we are only talking about network mobility. Alper: confused, if you can put something on the terminal, then we don't have a problem to solve here. Removing that constraint means we don't need to do anything. Margaret: so the people who objected are thinking that we don't need a new solution in this space? If there's something we can do to change the charter so that it has more consensus, we could do that. Are there any people who want to form the group without the restriction? Hesham: my objection was that I don't have a problem with defining, for example, protocols to do mobility with the routing layer. As a restriction, it doesn't make technical sense. It makes business sense. Kempf: suppose I have a handset with HMIP, it has a virus, it starts handing out the IP address of the MAP. Now there is a node in my network that people can DoS attack. Hesham: I understand that some people want this, I don't understand the problem statement. Vijay Deverapalli: you need some kind of extensions to figure out how to get an address, the MN to announce itself to the access point. Margaret: so you think it is not possible to do what the charter says VD: it GregDaley: I think there is a use case for this, which is looking at Mobility management from the network side, it would be nice to give some guidance to people that want to do this in the future. It doesn't have to do away with HMIP. Margaret: so you think there's room for a different solution. Raj: kind of think there's the same idea, this is just adding on to the plethora of mobility solutions. Gabriel: think it makes sense, an analogy is IPSec, suddenly get on the WLAN link, suddenly if it is required to use it then I can't use it end-to-end. End-to-end still has a place. Kempf: close the meeting, go to an informal session. |