[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RE: Policy based ISP selection - Redirects
There are some issues when using redirect,i believe.
The main problem that I found is that redirects must be with local scope.
This implies that the first hop must redirect the packet to the correct ISP.
Then , if there are several sub-networks in the site, all the routers must know
when to send the redirects.
This last statement means that:
- All the routers must inspect the port information in all the packets which may
arise some performance issues
- All the routers and all the hosts must know the policies, which makes
management more complex
In the case that routing headers are used, only hosts must have policies
knowledge
Best regards, marcelo
> 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
>