Subject: RE: [mobile-ip] Assumptions about L2 Address Use in Low Latency D raft

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Fri, 26 Oct 2001 11:04:44 -0500

Hello James:
 
I have some minor comment regarding the use of L2 identifier in link layer 
trigger:
 
a.MN identifier: I agree MN identifier must be the L2 identifier of mobile node. 
b.FA identifier : IMHO, we should not limit this identifier to the L2 address of the foreign agent.
Sometime it is much easier to provide IP address of the peer foreign agent. 
 
regards,
ajoy 

-----Original Message-----
From: James kempf [mailto:[email-masked]]
Sent: Thursday, October 25, 2001 5:32 PM
To: [email-masked]
Subject: [mobile-ip] Assumptions about L2 Address Use in Low Latency Draft

Hi folks,
 
In the process of implementing the low latency draft, a bunch of issues around assumptions about how L2 addresses are used came up. The draft assumes that the L2 triggers are delivering up "IP Address Identifiers", which are either IP addresses or L2 addresss that can be mapped to IP addresses  (I actually suggested this wording myself). The question is how likely will it be that a given L2 will be able to deliver up IP addresses? It seems to me that an L2 is more likely to confine itself to delivering up L2 information and let L3 take care of performing the mapping. As a consequence, I think it is probably valid to assume that most L2s will deliver up L2 addresses if they provide L2 triggers at all.
 
Given that, there are three ways that the low latency draft uses L2 addresses:
 
1) On link. This is used:
  a) in postreg, when the MN shows up at the new FA, the new FA uses the L2 address in the L2-LU trigger to determine where to send any incoming traffic for the MN. 
    It matches the L2 address in the HRqst or HRply to the home IP address to determine whether it has the MN on the link. The MN uses the L2 address of the new FA in a
    similar fashion, namely to send its traffic to the new FA as the default router, for forwarding down the tunnel back to the old FA.
  b) in postreg, when the old FA maps the L2 address delivered through the L2-ST or in the HRqst(t) to the home address of the MN, so it can send an HRqst or HRply to
     the new FA with the MN's home address.
  c) in source triggered prereg, when the old FA maps the MN's L2 address delivered through the L2 trigger to the MN's CoA for sending the 
      ProxyRouterAdvert.
 
2) Resolve cross-link to an IP address for an entity in the wired network. This is used:
  a) in target triggered postreg, the new FA must resolve the address in the L2-TT trigger to the old FA's IP address in order to send the HRqst. Similarly in source triggered postreg.
  b) in source triggered prereg, map the new FA L2 address to IP address so it can find the RouterAdvert to send to the MN.
  c) in mobile triggered prereg at the old  FA, map the L2 address of the new FA from the ProxyRouterAdvSol to the IP address of the new FA for sending the 
     ProxyRouterAdv back to the MN.
 
3) Resolve cross-link to an IP address for the MN or on the MN for an entity in the wired network. This is used:
  a) target-triggered prereg, the new FA uses the MN's L2 address from the target trigger to determine the MN's IP address (I assume the Care Of Address) 
     so it can send the FA Advert directly to the MN.
  b) mobile-triggered prereg, the MN resolves the new FA L2 address to the IP address of the new FA to determine where to send the FA Advert solicitation.
 
Of these, only 1) has currently well understood mechanisms for performing it. 2) and 3) essentially require cross-link Reverse Address Resolution (RARP). There is no general mechanism currently available for this function.
 
For 2), it is possible that static configuration or dynamic configuration via a CAR discovery protocol (see draft-ietf-seamoby-cardiscovery-issues-01.txt in the Seamoby  working group for a discussion of the issues) could  provide the needed address mapping. For 3), no such possibility exists because the MN's CoA is constantly changing.
 
The 802.11 InterAccess Point Protocol (IAPP) defines a way to do cross-link RARP using SLP. Each access point acts as an SLP SA and UA. When a MN reassociates with a new access point, the new access point acts as an SLP UA to request resolution of the old access point's Ethernet MAC address to an IP address. The old access point acts as an SLP SA to reply with the resolution. Since SLP uses multicast, the resolution works across subnets (disclaimer: though I am an enthusiastic supporter of SLP, I am not sure I agree with this mechanism architecturally. However, it does seem to have a fair amount of traction in the IEEE IAPP working group).
 
I think the draft needs to mention these points, at a minimum. I'm also wondering how practical the techniques which depend on 3) will be without the necessary mechanism, and whether a recommendation is required to an IETF working group should be made to start investigating mechanism to support 3), perhaps the IAPP mechanism, or maybe look at an RARP profile that uses multicast?
 
Comments?
 
                    jak

---

From: "James kempf" <[email-masked]>
Date: Fri, 26 Oct 2001 09:20:29 -0700

Hi Ajoy,

Sure, I wasn't trying to imply that it was not possible. Its just in most cases, I think L2 will
be more likely to return L2 information. I think we need to understand how to handle
those cases, even if they turn out not to be common.

In addition, the FA address isn't the critical one anyway. It should be fairly straightforward
to supply by static configuration or a dynamic configuration with a protocol like CAR discovery
even if it is not available from the L2 trigger.. The critical case is where cross link RARP is needed for 
resolving the MN's L2 address to an L3 address. This was case 3) in the original note. There are two specific instances
where the draft depends on this functionality, and the only solution currently that I'm
aware of is using SLP like IAPP does.

            jak