Re: [DNA] Model: how to treat "link down" events

[Soohong Daniel Park <soohong.park@samsung.com>]

It seems a bit crossover of IEEE 802.21 stuff called MIHS (Media
Independent Handover Services). It defines three kinds of services 
like below;

-Media Independent Event Services
-Media Independent Command Services
-Media Independent Information Services

and, especially your mention belongs to the first category.

For further details, you can refer to the related link below,
http://www1.ietf.org/mail-archive/web/mipshop/current/msg02410.html



Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.

----- Original Message ----- 
From: "Thomas Narten" <narten@us.ibm.com>
To: <dna@eng.monash.edu.au>
Sent: Wednesday, February 01, 2006 1:38 AM
Subject: [DNA] Model: how to treat "link down" events


> In thinking through this, one thing that is not clear to me is what
> the model is for what to do when a "link down" event takes place. This
> is actually important to understand as it plays into how to handle
> "link up" events.
> 
> RFC 2461/2462 defines the IPv6 behavior for configuring a link with
> IPv6 information such as addresses, MTU, on-link prefixes, etc.  When
> a link goes down, conceptually one disables the interface and discards
> all associated config info. However, this has the negative side-effect
> of causing upper-layer protocols using those addresses to possibly get
> "hard errors" and terminate connections when sending
> traffic. [Actually, is this true, or are things more nuanced, i.e.,
> does one get errors when sending but here is no route, or when sending
> but using an invalid source address, or???] In the common case where a
> link goes away for a few seconds and then comes back up connected to
> the same link (with the same associated config information) this is
> obviously undesirable.
> 
> Q: what is a good model for what to do with the config information
> assocated with an interface that is going down? In some cases (e.g.,
> administrative shutdown of an interface) returning hard errors to
> upper-layer protocols is probably OK. But for wireless hiccups, it may
> not be.  And if I unplug a wired ethernet from the jack, should that
> automatically cause all connections using the address on that
> interface to fail? Not clear. There are certainly times when I wish
> that didn't happen...
> 
> One possible model:
> 
>   - some types of "link down" events are absolute (like an
>     administrative shutdown)
> 
>   - some "link down" down events should be treated suspiciously (e.g.,
>     wireless) and should not result in (immediate) error to
>     upper-layer protocols.
> 
>   - by default, one should not return hard errors immediately (in
>     anticipation of the link coming back up) but one can do so after
>     some timeout. So, should we say after N minutes, an interface is
>     really dead?
> 
>   - can we provide guidelines for what to do in general?
>     
> 
> Proposal:
> 
> There are two types of errors that can be returned upon sending a
> packet:
> 
> hard error: means a failure of a type for which retrying is likely to
>             result in the same error, and upper layer protocols are OK
>             giving up.
> 
> soft error: a temporary failure occured, but retrying a short time
>             later may result in a different result. I would put "ICMP
>             dest unreachables" into this category.
> 
> 
> When a link goes down (i.e., via a "link down" event), soft errors
> should be returned when a) sending through the interface, or b) if
> using addresses associated with that interface. Soft errors should be
> returned from some short time. After (say) 2 minutes, hard errors can
> be returned.
> 
> Does this make sense?
> 
> Note: in terms of DNA, when a "link up" event takes place, I would
> imagine that we could distinguish between a "link up" event that
> happens within (say) 2 minutes of a "link down" or after a much longer
> time period, possibly treating the behavior somewhat differently.
>     
> Thomas
> 
>