Subject: [Pana] Issue 136: Clarify network selection relationship with EAP (take 2)

From: Alper Yegin <[email-masked]>
Date: Tue, 21 Dec 2004 16:25:48 -0800

Incorporating the latest discussions.....

5.11  Network Selection

PANA discovery and handshake phase allows PaC to learn identity of the
NAP and a list of ISPs that are available through the NAP. PaC can not
only learn the ISPs but also convey the selected ISP explicitly during
the handshake phase. PAA is assumed to be pre-configured with the
information of ISPs that are served by the NAP.

PANA-Start-Request message sent from the PAA MAY contain zero or one
NAP-Information AVP, and zero or more ISP-Information AVPs. The PaC MAY
indicate its choice of ISP by including an ISP-Information AVP in the
PANA-Start-Answer message. PaC MAY convey its ISP even when there is no
ISP-Information AVP contained in the PANA-Start-Request message. PaC can
do that when it is pre-configured with ISP information.

In the absence of an ISP explicitly selected and conveyed by the PaC,
ISP selection is typically performed based on the client identifier
(e.g., using the realm portion of an NAI carried in EAP method). Backend
AAA protocol (e.g., RADIUS) will run between the AAA client on PAA and a
AAA server in the selected ISP domain.

If PaC includes an ISP-Information AVP in PANA-Start-Answer, this is
taken as the client's selected ISP, whereas the realm extracted from the
NAI suggests the client's home AAA domain. In other words, backend AAA
protocol will run between AAA client on PAA and a AAA server suggested
by the client NAI realm through a AAA agent in selected ISP domain. In
case NAI realm and selected ISP domain are the same, there would be not
be a separate AAA agent between the AAA client and server. This approach
prevents overloading NAI mechanism for ISP selection. PaC client can
select an ISP independent of the NAI it presents to the access network. 

The PANA-based ISP selection mechanism dictates the next-hop AAA proxy
on the PAA. If NAP requires all AAA traffic to go through its local AAA
proxy, it may have to rely on a mechanism to relay the selected ISP
information from PAA (AAA client) to the local AAA proxy. Local AAA
proxy can forward the AAA traffic to the selected ISP domain upon
processing. Further details, including how AAA client relays AAA routing
information to AAA proxy, are outside the scope of PANA.

An alternative ISP discovery mechanism is outlined in
[I-D.adrangi-eap-network-discovery] which suggests advertising ISP
information in-band with the ongoing EAP method execution. Deployments
using the PANA's built-in ISP discovery mechanism need not use the other
mechanism.

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 21 Dec 2004 18:13:15 -0800

Alper,

The text looks good. One clarification below.

> information to AAA proxy, are outside the scope of PANA.
Do we know why someone would require this i.e., going via a local AAA proxy ?
Is it because the routing information can be kept in one place when you have
multiple PAAs in the network ? 

> using the PANA's built-in ISP discovery mechanism need not use the other
-mohan

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 23 Dec 2004 05:39:31 -0500

Hi Mohan,

> multiple PAAs in the network ? 

I think that can be one reason.  There may be other reasons.  But I
don't think we need to explain the reason(s) in the specification.

Yoshihiro Ohba