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

Re: survivability, rewriting

On 31 okt 2003, at 14:38, marcelo bagnulo wrote:

One thing we haven't discussed so far: if upper layers provide us with
a hint, what exactly does the multihoming layer do after receiving such
a hint? 

I thought this was what we were discussing with Erik in the Preserving
established sessiones thread :-)

We may want to do some extra checking before immediately failing over. For real time stuff, transport protocols are usually implemented inside applications. This means the mh layer may receive far too many hints from the transport layer to actually act on each one of them. Also, it might be beneficial to find out which alternatives still work before selecting them to continue the session over.

I'm thinking along the lines of sending out packets with all possible source/dest locator combinations and then see what comes back and how fast. Obviously we don't want to set off such a "ping bomb" too often. And we very likely don't want to use actual ICMP echos for this, but what do we want to use?

IMHO, i would like to explore alternative approaches first.
What about when recieving a ULP hint that there is a problem, change both
source and destiantion locators and send the packet with rewrite ok bit not
set?
A more aggresive option would be to send multiple packets in paralel, each
one with a different combination of source and destiantion address, and see
which reply comes first.

Yes. But I don't think we want to do this with actual data packets. In fact, there may not be any data packets available when this is triggered by a hint.

However, this doesn't solve what we should do when rewriting isn't
permitted. Obviously we could come up with a multihoming mechanism
where rewriting is always allowed,

I don't see how.

If we put a 64 bit identifier in the low order bits of the 128 bit address and then either make transport work on these 64 bit ids (a la 8+8) or we expand the 64 bit id into a 128 bit one as explained in my http://www.muada.com/drafts/cryptoid.txt non-draft. Then there is no problem with arbitrarily changing source locators. (Except some minor security points.)

I mean, we are going to have two mechanisms, one based on bgp + rewriting
and the other one is based on ULP hints.

BGP is a non-starter as there can always be failures that don't show up in BGP because of aggregation.

Now it is expected that the ULP hints mechanism will be have a better
response time i.e. it will detect problems faster, right?

That's the idea.

However, the ULP hints mechanism works in the host itself and the
bgp+rewrite mechanism is in the routers. This means that even if the ULP
hint mechanism has detected a problem and changed the locator, if the final
word about this belongs to the routing system, the bgp+rewriting mechanism
will overrule the decisions made by the ULP hint mechanism which is exaclty
what we don?t want

Indeed.

So we need a mechanism to force the routing system to accept choices made by
the host, since the host is better detecting problems in the path.
Such a mechanism seems to require the capability to express that rewriting
is not permited.

Or useful.

But "legacy" IPv6 also doesn't permit
rewriting, so we must be prepared to handle this. The obvious solution
is source address based routing, but it doesn't seem like everyone is
convinced.

Well, we could use a routing header.

You mean a routing header indicates permission to rewrite? That seems rather extreme. I'd use a different link layer encapsulation (= ethertype) or even IP version number first.

Even we could define a routing headers
that is elimated by the exit routers, in order to addresss the MTU reduction
problem.

That would only work if the first hop has a higher MTU than the rest of the path... Also removing some data in the middle of a packet is an extremely expensive operation in software.

An obvious comment about source address based routing is that source address
based routing only has to be implemented within the multihomed site.

Yes. It is not unthinkable that a host or even a small site has connections to two or more ISPs and/or larger sites. For instance, a laptop may be connected to the multihomed enterprise network while at the same time connecting to a GPRS ISP, or a home user could have an ISP connection and a VPN back to the multihomed enterprise network. But I think source address based routing or rewriting doesn't have to be arbitrarily stackable without the layers knowing about eachother.