[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comments on draft-ietf-shim6-proto-01.txt


El 17/10/2005, a las 7:26, Shinta Sugimoto escribió:

Hmm.  I am not completely sure but I see slightly different issue with
regard to the interaction between the ULP and shim6.  Let me try to
explain that:

I think ULP (or simply application) may want to decide whether to use
shim6 or not.  In other words, whether if the application wants to have
shim6 support for its flow.


agree


 IMO, this decision is different from what
is called ULID selection.


rigth


 ULID selection is (if I understand it correctly)
a choice of which ULID to use for particular flow.  As you mentioned,
ULID selection can be made through source address selection.



right


For instance, in MIP6, ULP may choose not to take advantage of MIP6 by
specifying source address as one of the locators (CoA).  This is quite
simple.  As far as the system provides a piece of information to
distinguish HoA from the other IPv6 addresses, this would work. Although 
CoA and HoA are both in form of IPv6 address, they are distinct
IP address (as far as the mobile is away from its home).



ok


In comparison to the MIP6, situation is a bit different in shim6.


yes


Although ULID and locator are conceptually different thing, ULID is
at the same time one of locators.  This poses me following questions:

Q1: Who decides which locator to be used as ULID ? (Shim6? ULP?)


ok, now i lost it
for now, all locators are ULIDs and all ULIDs are valid locators (we are exploring the possibility of using ulids that are not valid locators, but not there yet)
So, when the ULP selects the ulid, it is actually selecting the locator to be used initially as long as no failure occurs 
through forking the ulp can change to other locator
After a failure, the shim selects the alternative locator to use, but there are also forking here and also preferences
But i feel that this is not the point here. A i understood your point above is that you think that it would be useful to allow a ULP to avoid using the shim for its traffic. As i see it, this is not performed by selecting a given ULID or locator (as it would be in MIP, selecting the CoA) 
Here as i see it we would need something else, for instance:
- an extended API (TBD) which allows ULP to indicate the shim that no shim services are required for that flow - configuration of the heuristics that trigger the shim establishment, so that the shim context is not established for those flows that use certain apps (this is somehow limited, because in case that we have two apps, one that wants the shim and other that doesn't want it, then this mechanism wouldn't work, and we would need to use the API above)
[Please note that shim protocol as currently defined supports this. I mean, because we are using the shim payload header to indicate if a packet needs to be rewritten, we can have two apps using the same locators, one of which need to be rewritten by the shim and the other that doesn't requires locators to be rewritten. 
for example, consider app1 uses A1 and B1 as ULIDs and locators.
Now consider app2, that uses A2 and B2 as ulids and locators.
Now suppose that app1 doesn't want to use the shim and that app2 does want to use the shim. so a shim context with ulids A2 and B2 is created and suppose that A1 and B1 are alternative locators for those ulids (for app2) 
Now, for any reason, app2 traffic starts using A1 and B1 as locators
At this point, both app1 and app2 traffic would be flowing using A1 and B1 as addresses in the IPv6 packets. However, packets corresponding to app1 wouldn't carry the shim header so no need to rewrite while packets corresponding to app2 would carry the shim payload header, so they will be rewritten, so no proble with supporting one app traffic that don't requires the shim. The only problem here is how the app indicates the shim that it doens't want shim services, agree?] 


  - IMHO, it would make sense to let ULP to decide.  According
    to the decision, shim6 takes care of context establishment.

Q2: Who makes the ULID selection ?
  - I agree that one choice would be to let ULP make selection
    through source address selection. It would also possible of course
that ULP has no specific preference on which ULID to use, which will result in kernel choosing the source address as defined in RFC 3484. 

To summarize, I think your comments are answers to Q2 above (actually
its more than answers to Q2 but IMHO it does not cover answers to Q1).
Taking look at Q1 from slightly different angle, I wonder how could
application decide whether to request shim6 support or not. What do you 
think?
i think that this point is important, see above for the optins that i can think of, do you have another idea of how this could be done? 

regards, marcelo