FQDN via DNS RRs, shifting between locators may imply directing the
packet to a different endpoint where there is no knowledge of the
active session on the original endpoint.
The syntactic properties of these two different identity realms have
obvious considerations in terms of the manner in which these
identities may be used within PDUs.
It is also an option to consider a new structured identity space that
is neither generated through the reuse of IPv6 address values nor
drawn from the FQDN. Given that the address space would need to be
structured to permit its use as a lookup key to obtain the
corresponding locator set, the obvious question is what additional or
altered characteristics would be used in such an endpoint identity
space that would distinguish it from either of the above approaches?
Instead of structured tokens that double as lookup keys to obtain
mappings from endpoint identities to locator sets, the alternative is
to use an unstructured token space, where individual token values are
drawn opportunistically for use within a multi-homed session context.
If such unstructured tokens are used in a limited context, then the
semantics of the endpoint identity are subtly changed. The endpoint
identity is not a persistent alias or reference to the identity of
the endpoint, but it is a means to allow the identity protocol
element to confirm that two locators are part of the same mapped
locator set for a remote endpoint. In this context, the unstructured
opportunistic endpoint identifier values are used in determining
locator equivalence rather than in some form of lookup function.
6.2. Persistent, Opportunistic, and Ephemeral Identities
The considerations in the previous section highlight one of the major
aspects of variance in the method of supporting a split between
identity and location information.
One form uses a persistent identity field, by which it is inferred
that the same identity value is used in all contexts in which this
form of identity is required, in support of concurrent sessions as
well as sequential sessions. This form of identity is intended to
remain constant over time and over changes in the underlying
connectivity. It may also be the case that this identity is
completely distinct from network topology, so that the same identity
is used irrespective of the current connectivity and locator
addressing used by the site and the host. In this case, the identity
is persistent, and the identity value can be used as a reference to
the endpoint stack. This supports multi-party referrals, where, if
parties A and B establish a communication, B can pass A’s identity to
a third party C, who can then use this identity value to be the
active party in establishing communication to A.
If persistent identifiers are to be used to initiate a session, then
the identity is used as a lookup key to establish a set of locators
that are associated with the identified endpoint. It is desirable
that this lookup function be deterministic, reliable, robust,
efficient, and trustable. The implication of this is that such
identities must be uniquely assigned, and experience in identity
systems points to a strong preference for a structured identity token
space that has an internal hierarchy of token components. These
identity properties have significant commonality with those of
unicast addresses and domain names. The further implication here is
that persistent structured identities also rely on the adoption of
well-ordered distribution and management mechanisms to preserve their
integrity and utility. Such mechanisms generally imply a significant
overhead in terms of administrative tasks.
As noted in the previous section, an alternative form of identity is
an unstructured identity space, where specific values are drawn from
the space opportunistically. In this case, the uniqueness of any
particular identity value is not ensured. The use of such identities
as a lookup key to establish locators is also altered, as the
unstructured nature of the space has implications relating to the
efficiency of the lookup, and the authenticity of the lookup is
weakened due to the inability to assure uniqueness of the identity
key value. A conservative approach to unstructured identities limits
their scope of utility, such as per-session identity keys. In this
scenario, the scope of the selected identity is limited to the
parties that are communicating, and the scope is limited to the
duration of the communication session. The implication of this
limitation is that the identity is a session-level binding point to
allow multiple locators to be bound to the session, and the identity
cannot be used as a reference to an endpoint beyond the context of
the session. Such opportunistic identities with explicitly limited
scope do not require the adoption of any well-ordered mechanisms of
token distribution and management.
Another form of identity is an ephemeral form, where a session
identity is a shared state between the endpoints, established without
the exchange of particular token values that take the role of
identity keys. This could take the form of a defined locator set or
the form of a session key derived from some set of shared attributes
of the session, for example. In this situation, there is no form of
reference to or use of an identifier as a means of initiating a
session. The ephemeral identity value has a very limited role in
terms of allowing each end to reliably determine the semantic
equivalence of a set of locators within the context of membership of
a particular session.
The latter two forms of identity represent an approach to identity
that minimises management overhead and provides mechanisms that are
limited in scope to supporting session integrity. This implies that
support for identity functions in other contexts and at other levels
of the protocol stack, such as within referrals, within an
application’s data payload, or as a key to initiate a communication
session with a remote endpoint, would need to be supported by some
other identity function. Such per-session limited scope identities
imply that the associated multi-homing approaches must use existing
mechanisms for session startup, and the adoption of a session-based
identity and associated locator switch agility becomes a negotiated
session capability.
On the other hand, the use of a persistent identity as a session
initiation key implies that identity is part of the established
session state, and locator agility can be an associated attribute of
the session rather than a subsequent negotiated capability. In a
heterogeneous environment where such identity capability is not
uniformly deployed, this would imply that if a session cannot be
established with a split identity/locator binding, the application
should be able to back off to a conventional session startup by
mapping the identity to a specific locator value and initiating a
session using such a value. The reason why the application may want
to be aware of this distinction is that if the application wishes to
use self-referential mechanisms within the application payload, it
would appear to be appropriate to use an identity-based self-
reference only in the context of a session where the remote party was
aware of the semantic properties of this referential tag.
In terms of functionality and semantics, opportunistic identities
form a superset of ephemeral identities, although their
implementation is significantly different. Persistent identities
support a superset of the functionality of opportunistic identities,
and again the implementations will differ.
In the context of support for multi-homing configurations, use of
ephemeral identities in the context of locator equivalence appears to
represent a viable approach that allows a negotiated use of multiple
locators within the context of communication between a pair of hosts
in most contexts of multi-homing. However, ephemeral identities
offer little more in terms of functionality. They cannot be used in
referential contexts, cannot be used to initiate communications,
provide limited means of support for various forms of mobility, and
impose some constraints on the class of multi-homed scenarios that
can be supported. Ephemeral identities are generated in the context
of an established communication state, and the implication in terms
of multi-homing is that the two end points need to have discovered
through existing mechanisms a viable pair of locators prior to
generating an ephemeral identity binding. The implication is that
there is some form of static "home" for the end points that is
discovered by conventional referential lookup.
The use of a persistent identity space that supports dynamic
translation between an equivalent set of locators and one or more
equivalent identity values offers the potential for greater
flexibility in applications. Depending on how the mapping between
identities and locators is managed, this may extend beyond
multi-homing configuration to various contexts of nomadism and
mobility as well as service-specific functions. However, it remains
an open question as to the nature of secure mapping mechanisms that
would be needed in the more general context of identity-to-locator
mapping, and it is also an open question as to how the mapping
function would relate to viable endpoint-to-endpoint connectivity.
It is a common aspect of identity realms that the most critical
aspect of the realm is the nature of the resolution of the identity
into some other attribute space.
It appears reasonable to observe that, within certain constraints,
multi-homing does not generically require the overhead of a fully
distinct persistent identity space and the associated identity
resolution functionality, and, if the nature of the multi-homing
space in this context is to use a token to allow efficient detection
of locator equivalence for session surviveability, then ephemeral
identities appear to be an adequate mechanism.
6.3. Common Issues for Multi-Homing Approaches
The above overview encompasses a very wide range of potential
approaches to multi-homing, and each particular approach necessarily
has an associated set of considerations regarding its applicability.
There is, however, a set of considerations that appear to be common
across all approaches. They are examined in further detail in this
section.
6.3.1. Triggering Locator Switches
Ultimately, regardless of the method of generation, a packet
generated from a local multi-homed host to a remote host must carry a
source locator when it is passed into the transit network. In a
multi-homed situation, the local multi-homed host has a number of
self-referential locators that are equivalent aliases in almost every
respect. The difference between locators is the inference that, at
the remote end, the choice of locator may determine the path used to
send a packet back to the local multi-homed host. The issue here is:
how does the local host make a selection of the "best" source locator
to use? Obviously, an objective is to select a locator that
represents a currently viable path from the remote host to the local
multi-homed host. Local routing information for the multi-homed host
does not include this reverse path information. Equally, the local
host does not necessarily know any additional policy constraints that
apply to the remote host and that may result in a remote host’s
preference to use one locator over another for the local host.
Considerations of unicast reverse-path forwarding filters also
indicate that the selection of a source locator should result in the
packet being passed to a site-exit router that is connected to the
associated ISP transit provider, and that the site-exit router passes
the packet to the associated ISP.
If the local multi-homed host is communicating with a remote
multi-homed host, the local host may have some discretion in the
choice of a destination locator. The considerations relating to the
selection of a destination locator include considerations of local
routing state (to ensure that the chosen destination locator reflects
a viable path to the remote endpoint) and policy constraints that may
determine a "best" path to the remote endpoint. It may also be the
case that the source address selection should be considered in
relation to the destination locator selection.
Another common issue is the point when a locator is not considered to
be viable and the consequences to the transport session state.
o Transport Layer Triggers
A change in state for a currently-used path to another path could
be triggered by indications of packet loss along the current path
by transport-level signalling or by transport session timeouts,
assuming an internal signalling mechanism between the transport
stack element and the locator pool management stack element.
o ICMP Triggers
Path failure within the network may generate an ICMP Destination
Unreachable packet being directed back to the sender. Rather than
sending this signal to the transport level as an indicator of
session failure, the IP layer should redirect the notification
identity module as a trigger for a locator switch.
o Routing Triggers
Alternatively, in the absence of local transport triggers, the
site-exit router could communicate failure of the outbound
forwarding path in the case that the remote host is multi-homed
with an associated locator set. Conventional routing would be
incapable of detecting a failure in the inbound forwarding path,
so there are some limitations in the approach of using routing
triggers to change locator bindings.
o Heartbeat Triggers
An alternative to these approaches is the use of a session
heartbeat protocol, where failure of the heartbeat would cause the
session to seek a new locator binding that would reestablish the
heartbeat.
o Link Layer Triggers
Where supported, link layer triggers could be used as a direct and
immediate signal of link availability, where a "Link Down"
indication indicates the unavailability of a particular link
[iab-link]. The limitation of this approach is that a link level
indication is not a network broadcast event, and only the link’s
immediately-connected devices receive the link transition signal.
While this approach may be relevant to the degenerate case of a
multi-homed site composed of a single host, in the case of a
multi-host site the link indication would need to be used by the
site-exit router to generate one of the above indications for the
host to be triggered for a locator change. In this case this is a
conventional form of router detection of link status.
The sensitivity of the locator switch trigger is a consideration
here. A very fine-grained sensitivity of the locator switch trigger
may generate false triggers arising from short-term transient path
congestion, while coarse-grained triggers may impose an undue
performance penalty on the session due to an extended time to detect
a path failure. The objectives for sensitivity to triggers may be
very different depending on the transport session being used. There
is no doubt that any session would need a trigger to re-home if its
path to the locator fails, but for some transports, moving, and
triggering transport-related changes, may be far less desirable than
reducing the sensitivity of the trigger and waiting to see if the
triggering stimulus achieves a threshold level.
This problem is only partly solved by models with an internal
signalling mechanism between the transport stack element and the
locator pool management stack element, because of non-failure
triggers coming from other stacks, and because of transport issues
such as use of resource reservation. As an example, consider the
case of a session with reservations established by RSVP or NSIS, when
a routing change has just caused adaptive updates to the reservation
state in a number of elements along its path. The transport protocol
using the path is likely to see some delays or timeouts, and its
reaction to these events may be a trigger for a locator change, which
is likely to mean another reservation update. This chaining of
reservation updates may represent a high overhead. The implication
here is that individual transport protocols may have to tune any
feedback they give as a locator change trigger, so that they don’t
respond to certain forms of transient routing change delays (not
knowing their cause) with a locator change trigger. It should also
be noted that different transport protocols have rather different
behaviors and hooks for management.
6.3.2. Locator Selection
The selection of a locator to use for the remote end is obviously
constrained by the current state of the topology of the network, and
the primary objective of the selection process is to choose a viable
locator that allows the packet to reach the intended destination
point. The selection of a source locator can be considered as an
indication of preference to the remote end of a preferred locator to
use for the local end. However, where there are two or more viable
locators that could be used, the selection of a particular locator
may be influenced by a set of additional considerations.
The selection of a particular locator from a viable locator set
implies a selection of one particular network path in preference to
other viable paths. An implication of this host-based locator
selection process is that path selection and, by inference, traffic
engineering functions are not constrained to a network-based
operation of path manipulation through adjustment of forwarding state
within network elements. There is a consequent interaction between
the locator selection process and traffic engineering functions. The
use of an address selection policy table, as described in RFC 3484
[RFC3484], is relevant to the selection process.
The element that performs the locator selection, either as a protocol
element within the host or as a selection undertaken at a site-exit
router, also determines traffic policy, so the choice of using remote
packet locator rewriting or host based locator selection shifts the
policy capability from one element to the other.
If hosts perform this policy determination, then a more fine-grained
outcome may be achievable, particularly if the anticipated traffic
characteristics of the application can be signalled to the locator
selection process. A further consideration appears to be that hosts
may require additional information if they are to make locator
address selection decisions based on some form of metric of relative
load currently being imposed on select components of a number of
end-to-end network paths. These considerations raise the broader
issue of traffic engineering being a network function entirely
independent of host function or an outcome of host interaction with
the network.
In the latter case, there is also the consideration of whether the
host is to interact with the network, and, if so, how this
interaction is to be signalled to hosts.
6.3.3. Layering Identity
The consideration of triggering locator switch highlights the
observation that differing information and context are present in
each layer of the protocol stack. This impacts on how
identity/locator bindings are established, maintained, and expired.
These impacts include questions of what amount of state is kept, by
which element of the protocol stack, and at what level of context
(dynamic or fixed, and per session or per host). It also includes
considerations of state maintenance, such as how stale or superfluous
state information is detected and removed. Does only one piece of
code have to be aware of this identity/locator binding, or do
multiple transport protocols have to be altered to support this
functionality? If so, are such changes common across all transport
protocols, or do different protocols require different considerations
in their treatment of this functionality?
It is noted that the approaches considered here include proposals to
place this functionality within the IP layer, with the end-to-end
transport protocol layer and as a shim between the IP and transport
protocol layers.
Placing this identity functionality at the transport protocol layer
implies that the identity function can be tightly associated with a
transport session. In this approach, session startup can trigger the
identity/locator initial binding actions and transport protocol
timeouts can be used as triggers for locator switch actions. Session
termination can trigger expiration of local identity/locator binding
state. Where per-session opportunistic identity token values are
being used, the identity information can be held within the overall
session state. In the case of persistent identity token values, the
implementation of the identity can also choose to use per-session
state, or it may choose to pool this information across multiple
sessions in order to reduce overheads of dynamic discovery of
identity/locator bindings for remote identities in the case of
multiple sessions to the same remote endpoint.
One of the potential drawbacks of placing this functionality within
the transport protocol layer is that it is possible that each
transport protocol will require a distinct implementation of identity
functionality. This is a considerable constraint in the case of UDP,
where the UDP transport protocol has no inherent notion of a session
state.
An alternative approach is to use a distinct protocol element placed
between the transport and internet layers of the protocol stack. The
advantage of this approach is that it would offer a consistent
mapping between identities and locators for all forms of transport
protocols. However this protocol element would not be explicitly
aware of sessions and would either have to discover the appropriate
identity/locator mapping for all identity-addressed packets passed
from the transport protocol later, irrespective of whether such a
mapping exists and whether this is part of a session context, or have
an additional mechanism of signalling to determine when such a
mapping is to be discovered and applied. At this level, there is
also no explicit knowledge of when identity/locator mapping state is
no longer required, as there is no explicit signalling of when all
flows to and from a particular destination have stopped and resources
consumed in supporting state can be released. Also, such a protocol
element would not be aware of transport-level timeouts, so that
additional functionality would need to be added to the transport
protocol to trigger a locator switch at the identity protocol level.
Support of per-session opportunistic identity structure is more
challenging in this environment, as the transport protocol layer is
used to store and manipulate per-session state. In constructing an
identity element at this level of the protocol stack, it would appear
necessary to ensure that an adequate amount of information is being
passed between the transport protocol, internet protocol, and
identity protocol elements, to ensure that the identity protocol
element is not forced into making possibly inaccurate assumptions
about the current state of active sessions or end-to-end network
paths.
It is also possible to embed this identity function within the
internet protocol layer of the protocol stack. As noted in the
previous section, per-session information is not readily available to
the identity module, so that opportunistic per-session identity
values would be challenging to support in this approach. It is also
challenging to determine when identity/locator state information
should be set up and released. It would also appear necessary to
signal transport-level timeouts to the identity module as a locator
switch trigger. Some attention needs to be given in this case to
synchronising locator switches and IP packet fragmentation.
Consideration of IPSec is also necessary in this case, in order to
avoid making changes to the address field in the IP packet header
that trigger a condition at the remote end where the packet is not
recognisable in the correct context.
6.3.4. Session Startup and Maintenance
The next issue is the difference between the initial session startup
mode of operation and the maintenance of the session state.
In a split endpoint identifier/locator environment, there needs to be