Subject: [netlmm] PMIPv6 support in RFC5213

From: Guo Wei <[email-masked]>
Date: Sat, 29 Nov 2008 08:29:54 +0800

Hi, Sri

  After reading through 5.4.1 very carefully, some questions came to my mind
as follows:

In 5.4.1.1-the fifth paragraph, it states :

 1) If there exists a Binding Cache entry ...the request MUST be considered
as a request
       for updating that Binding Cache entry.

       *  If there is a Mobile Node Link-layer Identifier option present
          in the request and if the link-layer identifier in the option
          matches the link-layer identifier of the Binding Cache entry
          and the access technology type in the Access Technology Type
          option present in the request matches the access technology
          type in the Binding Cache entry.

         Why access technology type is necessary? IMHO, if NHP and MN-id are
all matched, it is enough to find which BCE exactly is.(Unless the same
link-layer identifier is possible with different ATT?) (I think two
link-layer identifiers (like MAC address )can not be the same) Or it is just
for LMA to ensure the ATT is right?

 2)      *  If the Proxy-CoA in the Binding Cache entry matches the source
          address of the request (or the address in the Alternate
          Care-of Address option, if the option is present) and if the
          access technology type field in the Access Technology Type
          option present in the request matches the access technology
          type in the Binding Cache entry.

         why this condition is required? I wonder that PBU from the same MAG
is not a Binding Update if ATT is different.

3) For all other cases, the message MUST be considered as a request
       for creating a new mobility session....

      What are the other cases? I think it MUST be a Binding Update message
if there exists a BCE with matched HNP(s). i.e. NHP(s) in PBU associated
with given interface has already existed so that NO new session/BCE should
be created.

     Some other questions that I get confused.

  4)   what the link-layer identifier really is? Is it the same with
link-layer address? Or MAC address?

   5)   Is it possible for MAG to enable two different access technology
now? (that is, MN could use two interfaces with different ATT to get access
to one MAG)   

   6)   Why we only take per-MN-prefix model into consideration but not
shared-prefix(es) between interfaces?

    I am looking forward to getting your back. Thank you.

B.R.

James

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

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 28 Nov 2008 18:42:50 -0800 (PST)

Hi Guo,

> for LMA to ensure the ATT is right?

ATT provides the name space for the link-layer id. It ensures there is not
link-layer id collision across different link-layer technolgies. Based on
this feedback, we had to carry the ATT along with the link-layer id.

> is not a Binding Update if ATT is different.

For a simple re-registration from the same MAG, CoA and the ATT match
uniquely identifies the created BCE for that MN.

>       for creating a new mobility session....

When we dont have enough data to associate the request with an existing
BCE, just create a new session. Thats the last fall back option.

> with given interface has already existed so that NO new session/BCE should

If the prefixes are present in the request and match the prefixes in BCE,
that session can be updated.

> link-layer address? Or MAC address?

It identifies the physical interface of the attached device. It is a MAC
address in case Ethernet. There is none in LTE. We added this entire
link-layer id option to ensure a multi-homed mobile node can operate in
a PMIP domain.

> now? (that is, MN could use two interfaces with different ATT to get access

Al though we did not go discuss the scenario of a single MAG supporting
multiple access technologies, it should be possible with the current 
rules.

> shared-prefix(es) between interfaces?

General IETF direction on IPv6 addressing, such as recommendation to
3GPP to allocate a IPV6 prefix to each mobile.

Also, shared prefix model comes with its own complexity, which the WG
did not wanted to solve in this spec.

Sri