Subject: [netlmm] Local routing at the MAG

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 7 Jul 2008 17:16:24 -0400

Hi Rajeev, Kuntal,

I looked at draft-koodli-netlmm-local-forwarding. I think it is a good
idea.

The PMIPv6 base specification already allows a MAG to optimize the
traffic when it figures out that both mobile nodes are attached to it.
See section 6.10.3 of draft-ietf-netlmm-proxymip6-18.txt. However, this
decision is based on local policy on the MAG. The base PMIPv6 document
also says 

   This decision of path optimization SHOULD be based on the policy
   configured on the mobile access gateway, but enforced by the mobile
   node's local mobility anchor.  The specific details on how this is
   achieved are beyond of the scope of this document.

I think draft-koodli-netlmm-local-forwarding could be the out-of-scope
mechanism referred to in the base document. Also,
draft-koodli-netlmm-local-forwarding should refer to section 6.10.3 of
the base spec. 

I have a few questions on the draft.

Why does the LMA have to authorize local routing per-pair of mobile
nodes? Can't it tell the MAG to apply local routing whenever possible?

Would it make sense to also allow the MAG to request the LMA for local
routing authorization when it detects a flow between two mobile nodes
attached to it? Does the local forwarding have to be triggered by the
LMA always?

Section 5.1 says

      MAY contain
      the remote MAG IPv6 address option, which is identical to the HNP
      option except for Prefix Length equal to 128 bits.

What indicates the presence of the remote (or peer) MAG IP address in
the LFRQ message? You might need a flag in the reserved field.

Finally, have you guys considered using the Generic Signaling message
(or the generic notification message as it was called before) instead of
defining a new mobility header message?

Vijay
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Mon, 7 Jul 2008 21:13:17 -0400

Hi Vijay,

> I looked at draft-koodli-netlmm-local-forwarding. I think it is a good

[RKo:>] Thanks.

> decision is based on local policy on the MAG. 

[RKo:>] Yes.
 
>The base PMIPv6 document

[RKo:>] Okay.

> nodes? Can't it tell the MAG to apply local routing whenever possible?

[RKo:>] Because all routing, by default, is through the LMA. The
scenario you refer to is a local policy issue, which may be captured by
setting a special field in LFRQ (something like wildcard auth for a pair
mobiles). On the other hand, we would like to have as much fine-grained
control as possible in enabling this - for instance, it should be
possible to allow local forwarding on a per application session basis.
Usually, such a control rests at the LMA (which has hooks to policy
servers).

> attached to it? Does the local forwarding have to be triggered by the

[RKo:>] I guess this depends on where the flow detection for local
forwarding is implemented. MAG could request it (i.e., LFRQ could
originate from the MAG) when deployments allow such a scenario. Since,
as a default, all routing goes through the LMA, that's the natural place
to have this control.

> the LFRQ message? You might need a flag in the reserved field.

[RKo:>] You keep parsing until the Total Length matches your current
pointer value :-)

> defining a new mobility header message?

[RKo:>] It might be a possibility, but the semantics has to work. We are
asking for one Type assignment.

Thanks again.

-Rajeev

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 7 Jul 2008 21:31:49 -0700 (PDT)

Hi Vijay,
  This is the simplest case of PMIP6 RO. We identified it as Case #1 (also Case #2 which is a very similar case) in draft-qin-netlmm-pmipro-00. The solution is as you said in the base draft.

Regards,

Behcet

----- Original Message ----
From: Vijay Devarapalli <[email-masked]>
To: "Koodli, Rajeev" <[email-masked]>; [email-masked]
Cc: [email-masked]
Sent: Monday, July 7, 2008 4:16:24 PM
Subject: [netlmm] Local routing at the MAG

Hi Rajeev, Kuntal,

Section 5.1 says

      MAY contain

Vijay