[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Policy based ISP selection
While I would agree there is some value in adding ports to the selection
rules table, I don't believe the routing header is necessary. If host A were
to send a packet to RB that the site policy wants routed through RA, a
redirect will straighten it out. Using redirect would also prevent the case
where the proposed policy entry points at a dead router, while the routing
system knows of an alternative. Basically there is no reason to add the
routing header complexity to achieve the policy goal.
-----Original Message-----
From: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]On Behalf
Of marcelo
Sent: Tuesday, July 03, 2001 12:43 PM
To: multi6@ops.ietf.org
Cc: alberto@it.uc3m.es; azcorra@it.uc3m.es
Subject: Policy based ISP selection
Hi,
We have been working in the following idea to provide ISP selection based on
internal policies:
Enabling Policy based ISP selection in multi-homed sites through address
selection mechanism.
The mechanism presented performs ISP selection in multi-homed sites. The
selection is based on previously defined policies and it is done on a per
application basis.
Topology
The following configuration is considered:
___________________________________________
| Internet |
| hostB |
|___________________________________________|
| |
| |
+----+ +----+
|ISPA| |ISPB|
|BRA | |BRB |
+----+ +----+
| |
link1 | | link2
__|____________________________|___
| RA RB |
| | | |
| ------------------------------- |
| | |
| hostA |
| PrefA:Prefsite:hostA |
| PrefB:Prefsite:hostA |
| |
|___________________________________|
In the configuration above, the multi-homed site is connected to the
Internet through 2 ISPs (ISPA and ISPB) using link1 and link2 respectively.
Link 1 is established between site exit router RA and ISP border router BRA.
Similarly, Link 2 is established between site exit router RB and ISP border
router BRB. Each of the ISP has delegated an address space to the site: ISPA
has delegated PRefA:Prefsite::/nA+n and ISPB has delegated
PrefB:Prefsite::/nB+n. Host A belongs to the multi-homed site and it has one
interface with the following unicast addresses assigned: two global
addresses, one form each ISP, PrefA:Prefsite:hostA and PrefB:Prefsite:hostA,
a site-local address and a link-local address. Host B does not belong to the
multi-homed site and is has only one global address, hostB.
The presented mechanism allows ISP selection for outbound and inbound
packets of internally generated communications (i.e. the first packet of the
communication is generated by a host that belongs to the site) and for
outbound packets of externally initiated communications. Note that ISP
selection of inbound packets of externally generated connections is the
result of the destination address selection algorithm after evaluation of
DNS response.
ISP selection tools:
It is relevant to note that current ISP based address aggregation imposes
that ISP selection for inbound packets of an internally generated
communication is determined by the source address of the first packet.
Consequently, if no intermediate devices performs any changes in the
packets, the source address selection mechanism of the host that initiates
the communication is naturally involved in the ISP selection mechanism. In
order to provide a coherent path for outbound and inbound packets of the
same communication, the source address selection mechanism and outbound
packets ISP selection mechanism must work in coordinated manner.
Internally initiated communications:
Outbound packets: the ISP selection is performed using routing headers that
include site exit routers connecting to the selected ISP.
Inbound packets: the ISP is selected when selecting the source address of
the communication initiator packet. If an address with PrefA::/nA prefix is
used, inbound packets will be routed through ISPA. Similarly, if an address
with PrefB::/nB prefix is used, inbound packets will be routed through ISPB.
Externally initiated communications:
Inbound packets: ISP selection is the result of the destination address
selection algorithm after evaluation of DNS response at the initiating host.
The tool available to the site for ISP selection is appropriate definition
of DNS responses. This is out of the scope of the presented mechanism.
Outbound packets: the ISP selection is performed using routing headers that
include site exit routers connecting to the selected ISP.
Source address selection algorithm.
The mechanism presented is a modification of the source address selection
algorithm presented in draft-ietf-ipng-default-addr-select-04. Basically a
modified Policy table is proposed. If the source address selection algorithm
or the policy table are not familiar to the reader, a summary of the
algorithm is presented.
Source Address selection algorithm
The source address selection mechanism relies on a set of rules to obtain
the most appropriate source address from a destination address and a given
policy.
The policy table is a longest prefix match table that takes an address
(source or destination) as input, and returns two values: a label value and
a precedence value. The label value is used to match destination addresses
with source addresses. The precedence value is used to select destination
address among a set of available destination addresses, and it is not needed
for source address selection, so it will not be introduced.
The process of source address selection is as follows: Once a packet is to
be sent to a destination address, the host routing mechanisms will select
the interface used for delivering the packet. After this, source address
selection is started. Source address selection algorithm has as inputs a
destination address (D) and first two source addresses (SA and SB) from a
proposed candidate set (all the possible source addresses of the outgoing
interface), and it returns the source address that fits best with the
destination address. Successive pair-wise comparisons are performed
throughout all candidate set to obtain the best address. The algorithm is
implemented as an ordered set of rules; if a rule selects one of the two
addresses no further rules are processed. Here we list the proposed rules
(Sx refers to any SA and SB)
- Rule 1: Prefer same address: If Sx=D then prefer Sx
- Rule 2: Prefer appropriate scope: If SB has a larger scope than SA
(i.e.
SA is a site local address and SB is a global address) and D has a larger
scope than SA then prefer SB; Otherwise, prefer SA.
- Rule 3: Avoid deprecated addresses.
- Rule 4: Prefer home address: This applies to mobile IP environments
so it
will not be discussed here.
- Rule 5: Prefer outgoing interface: If SA is assigned to the
interface that
will be used to send the packet towards D, and SB is not, then prefer SA.
Note that the previous rules can be responsible for selecting addresses that
were not assigned to the outgoing interface.
- Rule 6: Prefer matching label. Obtain label for SA, SB and D from
policy
table and compute the following condition: if label(SA)=label(D) and
label(SB)<>label(D) then prefer SA.
- Rule 7: Prefer public address: if SA is a public address and SB is a
temporary address, then prefer SA (public and temporary addresses are
discussed elsewhere [14])
- Rule 8: Use longest matched prefix.
Proposed mechanism:
In order to enable ISP selection through the source address selection
mechanism the following changes are introduced:
Policy table modifications. Port information must be included in order to be
able to make application based source address selection. Besides, another
entry is included in order to associate intermediate address needed to ISP
selection with source addresses used, with the intention to match exit path
with return path. The new policy table will then have the following aspect:
Port Prefix Precedence
Label Intermediate addr.
P1 ::/0 60
100
::1/128 50 0
::/0 40 1
2002::/16 30 2
::/96 20 3
::ffff:0:0/96 10 4
PrefA:Prefsite::hostA/128 5 100
RA
Example of policy table
To perform lookup in the table, an address and optionally a port are
required as inputs, and the outputs are a label value, a precedence value
and optionally an intermediate routing address. The lookup algorithm first
searches for matching port, and performs longest prefix match among the
prefixes of all the port matching policy table entries. If no matching port
is found, longest prefix match is performed with entries that do not have a
specified port.
Resulting behavior.
In the considered multi-homing configuration, suppose that internal policies
of the considered site are defined as follows: traffic with destination port
P1 to several destination addresses through ISPA, and the rest of the
traffic through ISPB.
The host A policy table could be configured as follows to accomplish the
desired behavior:
Applying the defined policy table, when an application needs to communicate
with a remote host D at port P1, the policy table will return the following
values:
For destination address D and port P1, it will return label value equal to
100 because destination and entry ports match.
For source address PrefA:Prefsite::hostA, it will return label value equal
to 100 and RA as an intermediate address for the routing header.
For source address PrefB:Prefste::hostA, it will return label value equal to
1, because longest prefix match is applied.
Final label matching leads to a resulting packet with PrefA:Prefsite::hostA
as source address; RA as destination address and PA as destination port, and
a routing header containing address D. This packet will then exit through
ISPA, and response packets will also be routed through ISPA because their
destination address will be PrefA:Prefsite::hostA.
Note that all the previously described process is carried out only if the
first five rules specified in the source address selection algorithm do not
apply. We will next justify that rule 6, where the ISP selection mechanism
resides, is reached when it is needed.
Rule 1: Same address only applies when the target host is the local host,
so no ISP selection is needed.
Rule 2: assures that ISP selection is aimed only to traffic addressed to
destinations outside the site; therefore no ISP selection is performed with
site local or link-local connections. Mechanism will only work for global
addresses, which is the intended behavior. To avoid being routed through
exit routers when systems of the same site use ports that have been included
in the policy table, site-local addressing should be deployed.
Rule 3: allows the mechanism to be compatible with fault tolerance features
provided by multi-homing through the Router Renumbering mechanism. So when
there is a failure in an ISP, address deprecation through Router Renumbering
and Router Advertising precludes the selection of addresses delegated by
crashed ISP, without need to modify existing policy tables on hosts.
Rule 4: does not applies,
Rule 5: The interface selection in the host routing mechanism for a given
destination could force selection in rule 5 if the chosen interface has not
been assigned at least one address from all ISPs. Then, if one interface has
an address with prefix PrefA, it also must have an address with prefix PrefB
to ensure proper functioning.
Contact information:
marcelo@it.uc3m.es
alberto@it.uc3m.es
azcorra@it.uc3m.es