9/26/06 ------- Morning ------- Attending: Henrik Levkowetz, Pete McCann, Jari Arkko, Aaron Silverman, Marco Liebsch, Vidya Naryanan, Katsutoshi Nishida, Hiditoshi Yokota, James Kempf, Kent Leung, Hongseok Jeong Kent does presentation on draft-giaretta-netlmm-protocol-01.txt. Discussion on issue tracking: Henrik and Kent JAK: run issue tracking on WG draft, after consensus Vidya: Issue tracker messages confusing Henrik: Will try to fix Vidya: Why not use mobility header? Kent: More reusability with transport as a transport layer Vidya: Dual stack could be reused with mobility header. Henrik: Different dual stack reuse in this case than for MIPv6. Possible cases to reuse, but enough differences that you might not be able to do it. Tweak. JAK: IPv4 for signaling Vidya: Is this really of interest? Kent: Not clear, but using transport makes it possible. Kent: Overlap with MIP? Vidya: Different views, not clear where lack of overlap. Can strip out keepalives, configure IPsec with PSK, Henrik: MIP case, traffic goes from host through IP stack no application involvement in HA and out. Mobility header not talking to an application to communicate changes in mobility state, just between mobile node and HA. Netlmm traffic goes from MN to another node, but netlmm is altering routing. Other reason is to reuse established communication protocol, don't want to turn mobility header into another transport. Vidya: Don't see transforming into another transport. Jari: What can we resuse? Binding update, but what else? Vidya: Interworking IPv4 and IPv6, options to carry v4 home addresses, work in monami, can reuse some functionality. v4 signaling would require transport based. Phil: Bulk registration and deregistration and SCTP, won't work with mobility header. Marco: Wimax, PMIPv4 and PMIPv6, might use netlmm for both too. Vidya: 3GPP and 3GPP2, PMIPv6 want to reuse some of options. Will people want to use this protocol? Henrik: PMIPv6, something that they can point to Pete: Reuse home agents primary reason for PMIPv6 Kent: Rational was reuse of home agents, but also because no network based protocol available, so adapted MIP. First release of Wimax, what to do with IPv6, postponed to next release, but is open for debate, people wanted PMIP because are comfortable with concept. Understanding of MIP has achieved. From IETF perspective, do we want a long term solution or a band aid to get it to work? Short term or long term, end of Dec. this year, no PMIPv6 or NETLMM, PMIPv6 is like MIP. Henrik: From equipment vendor, this is short development cycle. Pete:3GPP2, LMA is an extra hop that isn't needed, Vidya: They are trying to do multiple hierarchies for LMA. PMIP is no changes to home agent. Lots of things, reuse of as much of possible what has been defined. Convuluted SA fetching from SA, won't work. Marco: Reuse important, what do we need? Reuse implementation, equipment, interesting from vendor viewpoint. Switch from CMIP to nework mobility? Not. MN still has same equipment, not same. Vidya: Not realistic scenario, easy to shoot down, messy scalability. AR and HA are not elements of same administrative domain. Local mobility, trust relationship between entities, why PMIP to make efficient is any different from netlmm. Kent: Network based mobiltity management, use mpls, won't apply in client model, reusing fuzzy area, define new mobility header, negotiate data transport, shar options, how reusable is it. Vidya: List of reasons why this should be transport-protocol based. Phil: Move on to other issues. Kent: Initialization message between MAG and LMA has benefits Vidya: Makes sense in terms of general Internet usage. Kent: Must to implement, optional to use. Kent: Too many messages comment, now condensed. Two way handshake, removed route setup & MN address setup, now single message. Prefix addeded optionally. James: Why LMA Allocation? Henrik: Centralized decision point for authorizing mobility Jari: What does it do? Henrik: Preauthorization Jari: Is it just about choosing LMA or about setting config params Henrik: LMA may provide service to MN Jari: PDP tells LMA, provide services to MN, getting MN in and talking to which LMA is out of scope. Henrik: Should be addressed, disconnect between LMA has been selected, problem if you don't use message, how does MAG decide which LMA to use. Jari: Needs to be preconfigured on all APs. James: How does MAG know to go to LMA that was authorized? Kent: Implementation dependent. Pete: PP2 uses hash of MN id to decide LMA. Marco: MAG gets first contact, would use MN id to decide which LMA to contact Jari: LMA asks local AAA if OK to provide service, info on prefix, no info in LMA, something that isn't a routable NAI, no transaction id, Henrik: Assumes different ids used for auth and network access Vidya: EAP, support pseudonyms, celluar, IMSI isn't transmitted. Jari: Use AAA, must CDY attribute, opaque id from home network Vidya: How would you know? Jari: Two problems, tracking user is possible, user id coming back from home network. Henrik: Get to MAG and LMA Jari: Can't use for a AAA transaction and wouldn't make sense to redo. State at local network, could be OK. Practical case, don't need to worry about whether to provide service or not. Henrik: Gateway to service is MAG, not LMA. Jari: Typical deployment is that gateway is MAG. Might be special cases where might want special case. Kent: Download attributes on per user basis, repository on AAA, not sure if it makes sense for authz Vidya: Authz for network use allows lmm Jari: Roaming, knowledge of which MAG to contact or something might require LMA, might say for now not specified, but might be issues with AAA stateful, Marco: MAG makes decision? Vidya: Mobile might contact router Jari: Details, security of AAA might have to have MAC filter or something to make sure can't hijack someone else's addresses. Don't address separation of EAP and AR Vidya: EAP auth triggered Kent: Protocol perspective, external Jari: Black box, packet comes, know where it comes from, assumptions hold. Yokoto-san: Black box secure. Kent: Yes. ***Kent: Resolved to remove LMA Allocation/Acknowledgement message from draft*** Kent: Comment is MN id option not needed. But it is needed to identify signaling betwene MAG and LMA Kent: Needed. Come MAG, do DHCP or SLAAC, not need to wait to learn IP address, MN id could trigger signal to set up routing before IP address config. Henrik: Can use address as id after address is assigned. Nothing distinguishes first from other accesses. Second is like first. Vidya: NAI is not available because of privacy in access network. Link layer address, may work, but in some environments it won't work like cross technology. Many deployments, network actually realizes first attachment, context transfer across edge entities. Henrik: Context transfer need to know MN identity. Jari: Network decides that move this guy, context transfer is done. Vidya: Temporary id could be transferred, like IP address could be used as temporary id. Henrik: How do you know that this is the node that corresponds to the address? I'm arguing that you know that there is an id, cross tech would need some mapping, need some kind of id, all wirelesss technologies will provide some kind of id. Vidya: What kind of id are we exposing the LMA to? Access agnostic or access specific. Kent: Trying to be agnostic, what makes sense, binding Henrik: Good point is that we haven't considered, case where different ids used on different technologies, SEND key or other access independent key works, but otherwise need to tie togther two or more ids Vidya: Nontrivial to tie these. Do you want to expose home network to tie these two together? Probably not. Henrik: Just within netlmm domain. Visited network isn't there. Jari: Practical issue, how to get the identity, technology currently prevents you from seeing the identity. Henrik: Assumes home network identity is same as for netlmm Jari: EAP local layer 2 mobility, could refer to this. Marco: Mutliple interfaces, tried to discuss anchor one or multiple address to MN id, decided that the LMA anchors one or multiple IP addresses to the MN id even if id is interface specific. Agree that we need MN id to anchor IP addresses. Something is needed, might be assigned by network. Jari: Different deployments have different requirements. Identifiers, dig down on how to use, complicated issues, JAK: complicated issues, 3GPP applicability document Kent: What is the action item? ***Jari: Discussion of complexity of MN id question, warn about using EAP identity*** Issue 119 Security for signalling should be mandated. This version requires implementation of IPSEC (MUST) and SHOULD be used. Minimal to protect the NETLMM port #. Henrik: it would be good to have an alternative signature on the messages themselves instead of IPSEC. An option to do that. Jim: why is that? Vidya: with certs you could do DTLS on the messages. Henrik: not necessarily a good logic, but a gut feeling. Would like something that doesn't mean we need to have IPSEC implemented and used. Maybe what we want is signing rather than encryption. Jim: ESP-AUTH Henrik: more gut feeling than being able to logically explain what is better Jim: not IPSEC pixie dust; is that the case? Henrik: no Jim: clear technical ground and the DT seems to understand the implications Henrik: Jari's comments on more text being needed is correct, but not this Vidya: CAPWAP went with the DTLS route; but pick one and mandate it Jari: and preferably one that is in use, not something that needs to be needed. Some more depth is going to be needed. Maybe DTLS would be good. DTLS on TCP is much better for TCP. At that case the application needs it. Vidya: was an alternative for protecting RTP traffic; would prefer IPSEC. Jari: much easier than some other Jim: routing area hasn't figured out what they are going to do; might make sense to align with them Jari: missing some text about who is authorized to do various things. (Not just protecting the messages) Some application level smarts should be documented in the security considerations section. Henrik: we have tentatively put in MUST implement, SHOULD use. Not a clear firm stand from the DT. Maybe we should consider having MUST implement, and MUST use. Jim: IESG won't approve that. Sam says that we don't mandate security use. Jari: no, we have examples of this in protocols. Vidya: if we say that it's optional will people not deployment Jim: if the WG feels that we can put it in. Nishida: wants operator to have room to choose. Henrik: IPSEC rather than authentication signing room: stick with IPSEC Jim: on the security considerations section, there is duplicated text from the threats draft. Security considerations need to be rewritten including these residual issues, such as authorization for deleting a route. Kent: delete the existing text (it's in the threats doc)? Jim: right, plus residual issues and deployment issues for security Issue 120 MAG not mandated to be DHCP relay agent If not, then we need to describe how DHCP messages are processed by the MAG to get to the DHCP server changed wording to say the MAG SHOULD be. Not sure this actually made it into the draft. Actually there is no DHCP text in the draft. Action: fold in a DHCP section about how it works. Kent: is the resolution satisfactory? Jim: this is the borderline, but it has to go in here. Vidya: have problems if the MAG is not the DHCP relay agent Kent: MN/AR interface issue Vidya: if we don't have the MAG as the DHCP relay agent, there could be problems. It is a router in that it's running a routing protocol. DHCP relay agents are on the first hop IP router. Otherwise we'll redefine a DHCP relay agent to a DHCP relay agent. Henrik: MUST rather than SHOULD? Vidya: yes Jim: depends on whether the MAG is a router, and whether the network is using DHCP Vidya: right conditioned on whether DCHP is being used Marco: re the LMA being the relay. MAG is the first physical interface about LLAs so at least the request should be associated with the MAG, so SHOULD for the MAG being the RELAY Henrik: when we moved the AAA away from the LMA, then it implied that this is going toward the MAG Kent: but you need to have these decoupled, good for the LMA to know the DHCP transactions Henrik: why don't we rely on the MAG doing this in all cases Kent: only if it is doing some specific DHCP snooping Henrik: how does it help to make the LMA a DHCP relay Kent: not relay, but proxy, but not standard Vidya: DCHP proxies are not well specified Vidya: shouldn't worry about it, if they need to know, they could be colocated, don't specify it Issue 121 Description of IP Multicast seems confusing Jim: agree with this resolution, could be simplified by considering the multicast routing over the tunnel overlay, don't need to consider native mode; in some cases there might be less efficiency Kent: default mode is native mode Jim: does anything need to be said about that? is it any different? Kent: there's only about a page Vidya: there needs to be a policy based decision on whether it's native mode or... Kent: default Jim: who is going to be the agent PMR, what about MLD state? Only the first MAG is going to have MLD state in it. maybe not, that isn't considered here, you could context transfer it, not covered by the protocol; there needs to be more consideration of how MLD state is handled here. Action: cover MLD Issue 122 MAG should not be mandated to be the default gateway Not resolved Jim: what is the functional definition of the MAG, the MAG is a functional element that can be located in an access router; the only place where there is any real protocol impact is whether or not the TTL gets decremented, and whether to use link local; link local multicast won't work the same in a regular ethernet as they do in a NETLMM domain Kent: link local mcast apps have the assumption that there are multiple hosts on the link; if we assign a per host prefix, then it's a little funny, but it's working the way it's supposed to James: if the prefix doesn't change and the global prefix doesn't change, then the same collection of link local addresses are available; it's a corner point, but I'm concerned Jari: why is it violated? James: each individual MN has a separate routing prefix at the global routing level you have a p2p link, but if you don't say that the MAG is performing an IP bridging function, then all the MNs that are on the same MAG they will share the link local addresses (when it's shared). So if you have an app that uses link local addresses and it assumes that you will continue to do so (because the local subnet prefix hasn't changed) Phil: is it any different than the case of a local node becoming unreachable? James: maybe not Henrik: protocols that use link locals will verify reachability Kent: wireless? James: no Jari: all the printers in Tokyo? James: don't see a whole lot of use for link local in these networks Henrik: the better model is to restrict the link locals to the MN/MAG link, but am not convinced we can see all possible deployment scenarios and restrict it that you can make a use James: that is the point Fred is trying to make Henrik: it could make sense to describe the problem and it might make since to say Link Local addresses should be handled as on point-to-point James: confine the link to being pt-to-pt, using VLANs Phil: huh? James: the MAG has routing functionality, TTL gets decremented, in pt-to-pt, there is no shared link local, you don't decrement, you use an L2 tunnel Henrik: don't see those as coupled James: if MAG is a router it will decrement the TTL; if there is an L2 tunnel between the MAG and the LMA (Confusion) Vidya: MAG could be a router, but LMA is the default gateway Jari: had an issue with the default gateway; what happens when your prefix stays the same, but the default router changes when you move from one router to another, how does that work? what is the practical implication for the signalling James: in DNA it should work (James wrote the text) - when you get the RAs from the routers on the link, you should make the old routers conditional. Jari: is there delay involved? James: before you do the RS you put all the old routers in a state of .... Jari: what when you have MNs that don't do DNA James: they'll be listening for beacon RAs and will be listening for a long time; probably required for MNs to run DNA Jari: in pp, it would be possible for the phone and a laptop connected to the phone, the laptop is actually what you are talking to henrik: does that assume the phone is bridging rather than routing James: so laptop doesn't have dna Henrik: if you have per MN prefix, then the MN could delegate addresses jari: current phones open connections between the phone and the laptop James: what happens with RA beacons? what happens with routing table and default router selection for a 2461 node that doesn't do dna? beaconing is problematic with wirless. Jari: I want to see the big picture about how the whole things work, and it's not a dramatic failure if a non mobile node happens to be in the network; maybe we say what happens with classic ND Henrik: even if the main text is in MN/AR we need to have some text and a pointer to the right stuff in the MN/AR; don't want reader to be left hanging James: we have to talk about some of this context in the main doc Vidya: why do we have this issue? It works using 2461, it's just a question of how much delay. In some of the deployments that sort of delay would be unacceptable. When the MN moves, there is value in not waiting for the RA. ... Kent: virtual shared mac address, key is that when a mobile moves to the new MAG then it's a requirement to detect that it has moved to a new MAG, and then it's couple to the virtual MAC, when the traffic is using the old MAG is still flowing; need to decouple the problems that we are trying to solve Jari: it's quite clear that you need info about movements, but less clear where the information should come from James: some of this is intended to be in an air interface no conclusion, we need to talk about it more ------------------ Afternoon --------- Implementation ML Phil Roberts Julian Lanier is the DoCoMo point of contact Kent Leung is a Cisco Henrik will provide a point of contact (Zoltan?) for Ericsson Marco will provide a point of contact for NEC Phil will contact MK about a Nortel implementation Phil will set up a mailing list for this. James proposed that maybe we could do an interop in Munich right after the Prague IETF. Ericsson thinks we might be able to do this in Budapest. Henrik will have the folks in Budapest to start working on import/export rules. We also need volunteers to come up with a list of tests to be done. Required to implement, optional to implement, what the LMA and MAG are doing and what the intended correct result is. Then we'll have a testing matrix. Test everyone's LMA against everyone's MAG. Also need an environment to show how MN's interact with this environment. This can be complex. We should also figure out how to illustrate some of the solutions we offer. Marco is interested in starting on a testing matrix. (Identify MUST, SHOULD, and MAYs in the doc). James will see if he can find an example. Phil will post something to the NETLMM mailing list. --------------------- Need to come back to mobility header, role of MAG. --------------------- Other issues: Bulk registrations and deregistrations. Jari: you have to make it so that you can't send a new message before receiving the ack from the old one Henrik: no, we don't have to wait for them Jari: yes, so you can send multiple requests Jari: be careful about adding complexity Kent: LMA redundancy/failure is one case; the other case is batching up requests; need to get a better understanding of the reliable mechanism. Should it be part of the base or not? Don't necessarily have to do that later. Kent: would tend to think this is more of a bulk mechanism Jari: not sure that you can actually handover more than a single mobile at the same time Jari: do you tend to address issues such as LMA rebooting Vidya: LMA failover might be the better failover case illustrating this Jari: in failover, what might be needed is flow control on registrations coming from lots of MAGs rather than batching things up Henrik: current mechanism in heartbeats will detect this situation, it could be used then to regulate registrations going to an LMA Maybe the thing to do is rate limiting this. Marco: not a lot of complexity to support bulk deregistration, but the complexity to support bulk registration then we get that. So the bulk to get rid of all the mobiles on a MAG is easy. Henrik: we need to figure out whether we have cases that can't be covered simply by disassociation Let's talk about this a little bit more tomorrow. Doesn't seem to be support for bulk registrations. LMA Announce multicast message? James: many service providers don't turn multicast on. Not sure this is needed. Henrik: good to have bootstrapping in from the beginning James: agreed Not sure we're going to do this. Message format modifications? Henrik: let's not change what we have today. Kent has a proposal for message types. Kent: two schemes of message formats, what we have now; vanilla format which all the messages use. Other would be to have a base format for each format, then message specific fields pertaining to the message for each. Then each message has mandatory fields for each message rather than generic message formatting that you pull stuff out of. James: slight easier with options, but it's not a big deal; if you have options it let's you write the parser a little more cleanly. Kent: for decoding, as long as you know what the message format is, it's easy to decode. New messages with new options, the decoder will need to decode the message and the option. James: why are the MAG and MN are identified by an ID rather than an IP address Kent: need to get this worked out Henrik: it permits you to have an identifier/locator split James: these needs to be clearly and precisely explained and the benefits of using it Marco: support in the future for perhaps multihoming, multiple id addresses for a single entity James: this may raise a lot of issues, maybe raise a DISCUSS, so you need to be very clear about why you are doing this and what the benefits are Kent: split them into two separate id options- one for the MAG/LMA, the other for the MN James: yes, and a lot of explanation is needed Marco: doesn't need a specific header for each message, but let's have an ack, rather than a status code Leave it as it is. Review of 3GPP and WiFi as application examples: Nishida is working on a 3gpp doc, Julian might do a WiFi app. James went over schedule of getting from where we are to standard. 2nd afternoon session --------------------- Gathering up other outstanding issues - When would the MAG get the prefix rather than from the LMA? Henrik: in the DHCP case. Jari: router advertisements? James: you have to do RAs regardless Jari: in DHCP case, the LMA needs to be aware of which MN this came from Henrik: DCHP response goes through MAG, the MAG is a proxy, looks at it, sees the address, assigns it, gathers it off to the LMA Jari: but the LMA needs to know, you need to go through this in DHCP, to get the options right Henrik: host id option Henrik: this case the MAG gets the prefix first, and then informs the LMA James: when LMA is DHCP server also, it knows Vidya: standalone DHCP server James: this text needs to be clarified Vidya: there may be other things to specify; if the MAG is the relay agent, the server will assign a prefix on the relay agent's subnet; in this case we want to assign it from the LMAs subnet; I think we need to use a subnet selection option James: text still needs to be clarified; MN-AR needs to describe this also Jari: this document needs to describe what the MAG does James: yes, you're right Phil volunteers to do the legwork to figure it out - How can the MAG tell the difference between when a MN has gone away, or moved? Jari: something more is needed. Henrik: never let the old MAG deregister is one approach, always wait until you have an appearance at the new MAG Jari: you ought to be aware at the LMA who is still connected and what their resource profile Marco: the standard situation is a handover where the LMA knows and deletes the previous MAGs context; but there ought to be situations when the MAG knows Phil: thinks this is a layer 2 interface issue James: this doesn't accommodate predictive handover very well, packet forwarding change is happening at the same time James: we need to make this work, and we need to figure out what to say? Phil: who could look at it? Henrik: not let the normal case be that the old MAG does the dereg; if we do that we need to say something about state cleanup James: Henrik will update that way, and James will think about the predictive handover thing - IPSEC Jari: need more details about IPSEC, draft-bellovin-useipsec-05.txt, section 8 Phil, will ask Mohan whether he can address this - ID types Is there already a registry we can use here Is it possible to use SEND here, and if so, what do we supply as the MN id when we are using SEND between the MN and AR. James thinks the MN/AR interface already says something about this. Jari: we need to know better than we'll use something James: yes, we need something specific Vidya will look into how one might generate a default AAA identifier - clarify the distinction between prefix delegation and advertising the prefix James: DHCP has the option to delegate a prefix and router advertisements are advertising; some folks think if you advertise the prefix then you can delegate it further, which is wrong Henrik: the option has two, either for delegation or advertising, the option will provide the information Jari: confirm the thinking is that the normal case is allocating the prefix, and delegating the prefix is an extension Jari: question then is why are we doing anything with the delegation? Maybe there are needs for delegation in certain cases, but if so, why does that need to be important to NETLMM Henrik: so NETLMM never needs to know about this Jari: should be a requirement that the existing DHCP delegation messages work Henrik: the LMA can route only based on the allocated prefix; it doesn't need to know James: the MAG needs to know the distinction Jari: remember the case of two different prefixes in the prefix delegation case, the prefix allocated for the link itself, and the prefix allocated to the MN to use on other stuff; when you move, you need to let the new MAG which of the prefixes are allocated and which have been delegated James: we need to set the bar at not breaking the current Kent: we need a flag per prefix, or two suboptions on what kind of address - timestamps Jari: if it affects more than one mobile node, we need it not to be out of sequence What if you have bulk events mixed with individual events vidya: sequencing per mobile makes it a little complicated; if you protect the signalling with IPSEC, then the IPSEC sequencing might kick you out Jari: if you have a huge reorder then you will start losing, but it doesn't reorder for you; if it gets so bad then IPSEC gets confused Henrik: similarity with SCTP, using the same mechanism won't get us into trouble if we do Vidya: make it lockstep for a given mobile node on a particular MAG Jari: not too happy about this, but don't have anything better to suggest; SHOULD might be better Vidya: it could be complicated, what if the MAGs belong to different timezones Henrik: doesn't matter James: what's the action? Henrik: decide on reordering handling: 1) per MN lockstop 2) use the SCTP and never forward to the state machine any packet when there is a gap before it Henrik: and also what do we do with timestamps James: if they are there, let's clarify Marco: there is a problem with gaps and heartbeats James: lockstepping per MN might be easier Vidya: lockstep makes it simpler, you don't have to detect out of order, don't like sequence number per MN, signalling is between MAG and LMA Henrik: if you always throw away the one out of order, it might be resent, and if it is, then we are resending Vidya: retransmissions are done per msg, it's likely that whatever when you send it will continue to be an old message Kent: ACK it but don't act on it Henrik: if the messages are for different mobile nodes conclusion: Henrik has a summary of this discussion - in order to handle possible reordering, the sender always makes sure that a message to a particular MN, you have received an ack for all previous messages relating to the MN before sending another Jari: back to timestamps, this isn't optimal, but don't have an alternate proposal James: need to clarify and it will be a MUST - link local multicast James: if we use a prefix per MN model, then you don't need proxy DAD, and it's a red flag for multilink subnets Henrik: remove or rewrite? James: It's true provided a MAG is a router, get rid of the DAD text, keep the first sentence in 8.2.1 - is transport and sequence number, per LMA or per address Marco: it's pre LMA address/id, not per IP address, and we should be more specific in the draft Marco will provide an update as it pertains to the cds - role of the MAG Need to take this on today Jari: happy with the doc, and just wants to see how it fits in with the other doc - what about the case where the MN is still attached to the pMAG as well as the nMAG? Jari: will the LMA send a dereg? yes, Jari: ok, that's fine - back to the lockstep issue Kent: something is bugging me about the sender; if the sender has to detect whether it has the previous state or not; then the sender will have to keep track of all the previous ones? it has to look through all the unacknowledged messages 1) you send something that hasn't been acknowledged, and then you have to hang on to your new events. For a new event you have to look through and send something. - adding a prefix after starting (Nishida-san) Kent: could you add a prefix Vidya: if you have multiple prefixes, then they should be handled together Henrik: within a particular MN ID Vidya: right, from a tunnel mgmt perspective, unlike MIP where the MIP can use the HA and the mobile can use multiple coas, here you have multiple prefixes and addresses with the prefixes, that tunnel has no correlation between packets sent and received Henrik: question is how do you add and delete prefixes Vidya: depending on whether the prefix has a lifetime the behavior is different; we can't mandate the mobile to tell the MAG whether it owns the prefix summary: if we don't have to do this from the LMA we don't need to worry about it, but if we do we could add a new message, some overloading, add a new subtype James: DHCP confirm may solve our problems for us Nishida: this is a 3gpp case James: we need more info about the use case then - is the RA a unicast message? (Hongseok) Depends somewhat on whether the MAG is a router or a bridge, if it's a router it has to unicast it, if it's a bridge, then it's bridging between the LMA and the MN ******************************** 9/27/2006 --------- Attending: Marco Leibsch, Hongseok Jeong, Phil Roberts, James Kempf, Katsutoshi Nishida, Vidya Narayanan, Henrik Levkowetz, Kent Leung, Pete McCann (later: Jari Arko) Morning ------- Nishida-san presents 3GPP Applicability slides Discussion on whether to use TIMSI or IMSI as MN id Vidya: Privacy concerns with using TIMSI? Kent: Not sent over Internet Vidya: Does MME have mapping between TIMSI and IMSI? Nishida: Yes Marco: TIMSI is only used in access between SGSN and mobile Kent: IMSI would be OK, would be nice to have "visited" IMSI in case of compromise Nishida: Makes sense in multiple access sceneros, LMA might be far away from access networks topologically Vidya: If 3GPP adopts EAP, would have other options. UMTS-AKA uses IMSI then you would need to use IMSI. Henrik: Privacy concerns if subcontractor MAGs might mean that IMSI or TIMSI should not be used but use something else, domain specific identifier. Discussion of location for LMA in 3GPP SAE network Henrik: Does it go at IASA? Nishida: Yes. Henrik: Isn't that a problem if MME/UPE is in another operator's domain? Kent: Only applicable to multiple access technologies in one operator's network. Discussion on when to do NETLMM signaling (slide 8) Kent: Signaling in 11 could be done earlier, prior to MN handover after new MME/UPE has confirmed handover. Henrik: Can't actually switch bearer path, that's where their is 7 for optimizing handover and reducing data loss Kent: If 8 & 9 fail, does it start at 3 again or what? Henrik: Don't know, depends on radio ocnditions. Kent: Step 7 data path comes in at MME1, but network is assuming that it will handover to MME2, will get traffic coming in to MME2 from mobile, need to deal with these packets because routing isn't set up with IASA Nishda: Bicasting is one possibility, mobile intended to move recovering time is better to keep connection on old bicast path, can recover Kent: Until step 10 is complete, still anchored and going through MME1 for both directions? Nishida: Yes. Kent: Dath path must be consistent, so this should be fine. Nishida: No bicasting, failover to stop procedure to stop handover is considered important, keeping old path until radio bearer is up, needs to be maintained. Kent: Doesn't require NTELMM dereg from IASA, right? Nishida: Yes Kent: 3GPP has its own message for that? Nishida: Yes. Kent: Do we have optional bit, how does LMA know if it should dereg at previous MAG or not? Nishida: We don't have that currently. Henrik: At some point, it is a config matter. Only reason to configure on MAG is that if there is some MAG that need it and others that don't. Kent: Wifi might need it. Henrik: Capability that is established during attachment. Marco: 3GPP sepcific stuff on S1 that in NETLMM are left undefined for particular implementation. Henrik: Might use context transfer. Henrik: Not a catastrphe if there is a dereg message. Marco: If IASA is in home domain, then it would be a problem. Henrik: IASA and MAG are in same domain. Kent: We should add something at associate phase or during loc reg to indicate dereg to previous MAG needed. Henrik: Probably better in extension. Kent: Would be simple indication, not too much ocmplexity, romaing in Wifi might help with different MAGs, 3GPP doesn't need it though. ***Action item for Kent: File issue when WG draft approved on location dereg indicdation for previous MAG*** Correction to Slide 9: 4 or 6 should have APN, IASA address, and MN prefix Henrik: Should we use location update or routing update? James; I don't think it matters. Henrik: Might make it easier in this context. Nishida: Yes. James: Idle mode not getting packets. Henrik: Still switching routing. James: OK. Pete: Are other deployments possible, like on S1? Henrik: Possible. Is location update better than forwarding update? Forwaring update seems a better approximation, get rid of collision with 3GPP terminology. ***Action item: Henrik will change location update to forwarding update in next version. People who don't like that should file an issue when WG draft status is approved.*** Slide 9 Kent: DHCP interaction, how does DHCP from host interact with this? Nishida: Basic signaling doesn't include DHCP, will change. But possible that mobile will get IP address through DHCP. James: 3GPP networks don't use DHCP, other ocnfiguration Jari: DNS addresses come in various ways, not DHCP. Henrik: Laptop tries to use DHCP via a phone, won't get an address. Jari: Laptop will see RA and act accordingly, autoconfigure. Kent: Who sends router advert? James: GGSN in GPRS. Kent: In UPE? James: Probably MME/UPE is what 3GPP would want. Marco: Slide 8, delay introduced by PCRF indirection might cause timeouts to expire on NETLMM signaling. Henrik: There are timeers defined that would make this less than 1 second. *** Action item for Kent: After we get WG draft, Issues after version 2, introduce retransmission parameters during associate if necessary during initial MAG association. Nishida: MAG requries parameters. Second last slide: Kent: One IP addres per context? Nishida: If you need to connect to differnt PDNs, need separate context. Kent: Voice can use same IP address. Henrik: If secondary context, uses same address, if primary it's a different address. Kent: Not one to one of IP address to PDP context. Henrik: No, but it is close. Henrik: Only affects us that we need to cover the case that there are multiple prefixes. Marco: No problem since tunnel is same. All prefixes with MN id. Henrik: Yes. Last slide: Kent: Both mobile and anchor side may need to add or delete prefix. Henrik: Not clearly so from what was said. Action item. Kent: GGSN does this, GPRS working does this today. Don't want to remove features. Might need this. Marco: Difference is multiple prefixes exist but each through a different MAG, right? Henrik: No, using NETLMM tunnel on the slides mean prefix not the actual tunnel, means prefix. Marco: Each prefix is associated with a different MAG. Pete: Different LMA Kent: But same MAG. Nishida: Just capture what is discussed in 3GPP. Mobile only requests one prefix to access this PDN from this IASA. Maybe connect to different IASA, but this is a different NETLMM domain. But NETLMM doesn't have to manage different prefixes. Kent: One LMA to different PDN, or one PDN per LMA. Nishida: Yes. Kent: Need to add or delete prefixes from MAG. LMA informing MAG is TBD. *** Action item: Nishida-san will look into whether LMA needs to inform MAG to add or delete prefix and so, file an issue when WG draft is approved.*** Afternoon --------- Discussion of the MAG as a router or not ---------------------------------------- concerns, "link local" means "subnet local" (in address autoconfiguration) "link local" addresses can't be assumed to be unique across a NETLMM domain In 16ng, the IP CS is pt-to-pt, the Ethernet CS is still under discussion Global addr uniqueness is confirmed through link local multicast reachability (2461). Applications may assume global reachability implies link local reachability, it might use NS for addr resolution to establish link local address reachability of a corresponding global address on a single NETLMM link if a MN moves to a new NETLMM link, the global addr is still reachable and hasn't change but the link local address is no longer reachable The assumption that the application may assume global reachability implies link local reachability is false Subnet with 10.1.2/24 and 10.1.3/24 with two nodes, one on each subnet may communicate directly only if the router sends an ICMP redirect will make it known to the sending node that the other prefix is also on the same link (we need to verify this behavior in documentation, but believe it is true). Our behavior is different because each attached node has a unique global prefix and the router should not tell other nodes about the same prefix being on that link. Implies the router can tell each mobile that it has a unique prefix, and the other nodes can't communicate the presence of their unique prefix. Re: the MAG as an IP layer bridge implies not decrementing the hopcount, there is a question about if you have interMAG connectivity (for handover optimization for example) and transient states that might accidentally create routing loops which not decrementing the hopcount would not mitigate Not sure GPRS is exactly like this, the MN is identified in the GTP tunnel. GPRS has a per MN id within the tunnel. Re: multicast. In addition to MLD state on the LMA you need state on the MAG to know which mobile to send traffic to. Could be done with context transfer or if the MAG has MLD state it could trigger the mobile to reregister. Multicast traffic could be either standard multicast routing, or routing through the tunnel overlay. Implementation issues: use an L2 tunnel between the MN and MAG and confine link local multicast to the MAG and MN (virtual pt-to-pt link) OR MN is on a point-to-point link with the LMA (this last bit belongs in the MN/AR interface document) We must separate the decision about whether the MAG is a router, and whether the last hop is a shared link. The last is the issue we've been talking about, and will NETLMM function ok in a case where the link south of the MAG is a shared link. Action: someone needs to file an issue on the MN/AR interface doc to say this is for pt-to-pt links Proposal: the MAG is a router (decrements hop count), with the qualification that the MAG behaves as a "proxy default gateway" (with the actual default gateway being the LMA) this is a little bit hand waving Action: (Phil) Jari sees issues in both alternatives. Phil will figure this out and propose text, actually write a document about the tradeoffs. Marco: we need to be specific about the TTL decrement. Two issues: neighbor discovery and forwarding behavior MAG as a default router, as proxy for LMA, as transparent IP bridging issue ---------------------------- Regarding using the mobility header Phil asserted that there doesn't seem to be a lot of support to using the mobility header to implement NETLMM functionality. ----------------------------- DT is finished, ML archives will be made public James and Phil will get the minutes of today out We'll call to have this document as the WG protocol document ----------------------------- Presence of the feature of bulk registration and deregistration Better mobility, faster, more reliable mobility and that needs to be applied to the complete life-cycle of operations. One of the areas where a feature like this will be useful is in the case of graceful shutdown. It would be nice to have a MAG send a request to an LMA that the prefixes that it is caring for over to something else. Rate limiting is still useful, having bulk doesn't obviate that. The request is at least to have the option of a MAG and an LMA negotiate whether they support it and then allow it. Two ways of doing that, not setting up anything new, but running until we no longer have mobiles; or no new ones; encouraging moves of the existing mobiles. From the NETLMM viewpoint, the movement has to be managed elsewhere, which is true, to support with a message that says not accepting new connections. MAG-LMA not accepting new messages. Because the MAG originates it the operation can all be handled around the MAGs, going quiescent. Need to handle both the network and the radio. Should try to develop a protocol that fits the need. Need to understand the constraints or the requirements for handling multiple mobiles around. The local case is different than the case of having to move global routes. In the failure case you expect the space of one to be repopulated or prepopulated in the LMA cluster. Can be done through replication, etc. Two failure cases: MAG failure, LMA failure, or administrative action. In the two boards close to each other, with current HA technology with VRRP for example (not VRRP really), would the standby board come up on the same interface addresses as the board that went down? Yes, they are sharing virtual addresses. As long as you are using L3 you can assume that. Then state replication without any protocol support would be okay. Kent, it's not so much speed as distance. When a lot of information needs to be transferred. When you get into that situation then the ability to get as much information in as few a number of packets is a good goal. The more messages the more likely to trigger rate limiting and then the latency of the update grows. So what would you consider more reliable than VRRP? No, there is a whole lot that happens after the interface swap that still need to happen. Bulk deregistration with our mechanism. The other is the multiple case of messages being bundled. One of the thing is whether we have made high availability harder to do. Thinking about it now would be good. How would you do state replication? Share state over the link. Typically you have a platform with a high availability middleware the provides at a minimum for example check point services. Write the LMA to use those checkpointing APIs - whether it's message or memory based. Out of scope, but need to make sure you don't do anything that makes it more difficult. Is heartbeating mandatory? Would be better to have a heartbeat that was independent of one provided by for example SCTP. So if we do an SCTP version, it would be good to have the application layer heartbeat stay there. No change.