Subject: RE: [mobile-ip] RRn Last Call Resolution Issue #2 - DISAGREE

From: "Alan O'Neill" <[email-masked]>
Date: Thu, 16 May 2002 03:12:02 -0400

Hi Annika,

The reason I DISAGREE here is with the 'I' bit representing regional tunnel
management, whereas I think we actually need separate bits for indicating
support for the signalling extensions and for the associated forwarding
model in the data plane. The 'I' bit should mean regional signalling in my
book. My reasons are obvious because Nested/Concat would like to share the
regional signalling model, extensions, backwards compatibility, security and
message flows. If these are tied in with GFA then I will have to do it all
again myself and interoperability will be horrendous, and we all have more
standards work etc (assuming people understand the benefits of layered -
Nested/Concat - MIP). It also makes the support of GFA forwrding under the
layered model pretty messy.

So then we can make an additional request to have an FAA bit for Nested, one
for Concat and another for GFA type forwarding, which is clean and
efficient, with each bit being justified by deployment demands. This is very
clean IMO but flag inefficient.

We could instead just use and all share the 'I' bit which is flag efficient
but opens up the potential for confusion. Now I don't expect this request to
be blindly accepted because it will only be reasonable if GFA is not overly
affected by it.

So here is the potential (zero?) effect as justification..

If the I bit means regional signalling and that the second FAA address is a
regional address then it can be interpreted a number of ways clearly by a
MN. Only Layered (Nested/Concat) MNs can see the regional information in the
FA-NAI. So a MN that only knows GFA will correctly interpret the I bit with
no side effects. A mobile that reads the FA-NAI and sees the regional
information will know that layered is supported.

The FA knows whether GFA or Layered has been requested because for GFA
forwarding, the advertised GFA address in the FAA is optionally used in the
home registration, inserted into the CoA field or that field is zero.

In Layered MIP, the RMA address in the FAA is first used in the regional
registration to the RMA as the HA address, or that address is zero, whilst
the CoA field contains the FA CoA from the FAA. 

Essentially GFA does home then regional reg whilst Layered MIP does regional
then home reg, and hence can be clearly differentiated even without using a
new extension into the MIP Reg. Of course this can also be made easy with
new MIP message types or extensions but I am ignoring that for now to
shorted the discussion

A final alternative would be for Layered MIP to have its own bits to
distinguish forwarding and signalling plane capabilities
and we then bite the bullet of having competing regional signalling planes.
Certainly less to argue about in the short term. This might also then be
helped if the RegTun docs can be structured so that Layered with
Nested/Concat/GFA type forwarding can still re-use as much as possible from
those docs...

(Oh and I forgot that other unmentionable option of Layered MIP not being
addressed by the wg.. :-)   

Feedback greatly appreciated,

Regards,  Alan.

-----Original Message-----
From: Annika Jonsson [mailto:[email-masked]]
Sent: 14 May 2002 19:17
To: Phil Roberts; [email-masked]
Subject: RE: [mobile-ip] Regional Registration Last Call Resolution
Issue #2

At 03:37 PM 5/13/2002 -0400, Phil Roberts wrote:

>We would like to know whether folks agree or disagree with these
>proposed resolutions.
>
>Annika, we're going to need proposed text for each of them, and a
>pointer to where it would go in the draft.

se below...

>Thanks,
>Phil
>
>
> > -----Original Message-----
> > From: Annika Jonsson [mailto:[email-masked]]
> > Sent: Monday, May 13, 2002 11:53 AM
> > To: [email-masked]
> > Subject: [mobile-ip] Regional Registration Last Call
> > Resolution Issue #2
> >
> >
> > Hi
> >
> > Here are my conclusions and proposals for additions/changes
> > to solve the
> > backwards compatibility issues in the Regional Registrations draft:
> >
> > A: Backwards compatibility with RFC3220 MN:s.
> > FA:s must advertise their own address, since it is used for movement
> > detection by RFC3220 MN:s. This requires one change and one
> > clarification
> > to the draft:
>  > - To be backwards compatible, if the FA only advertises one
> > CoA it must be
> > its own address (not the GFA address as specified now). This
> > FA must be
> > able to act as a normal RFC3220 FA (that's in the draft already).

This would go into section 3.3. It would be changed to:

"
3.3. Advertising Foreign Agent and GFA

A foreign agent typically announces its presence via an Agent Advertisement 
message [9]. If the domain to which a foreign agent belongs supports 
regional registrations, the following changes are applied to the Agent 
Advertisement message.

The `I' flag (see Section 7) MUST be set to indicate that the domain 
supports regional tunnel management. If the `I' bit is set, there MUST be 
at least one care-of address in the Agent Advertisement message, but that 
address MAY be set to zero. If the `I' bit is set, and there is only one 
care-of address (i.e. not zero), it is the address of the FA. If the `I' 
bit is set, and there are multiple care-of addresses, the first care-of 
address is the local FA, and the last care-of address is the GFA. The 
FA-NAI (see section 7.2) SHOULD also be present to enable the mobile node 
to decide whether or not it is in its home domain. The decision is based on 
whether the realm part of the advertised FA-NAI matches the mobile node's 
realm. "

> > - clarify that if the FA advertises a zero address, it will
> > not support
> > RFC3220 MN:s. In some cases the owner of the network might
> > prefer this.
> >
> >

A new section about backwards compatibility:

"3.4 Backwards compatibility with RFC3220

A domain that supports Regional Regisratiosn SHOULD also be backwards 
compatible with RFC3220. If the Foreign Agent does not advertise a zero 
care-of-address, it MUST support registrations according to Mobile IPv4 
[9]. This allows mobile nodes that doesn't support Regional Registrations 
to register via this Foreign Agent using standard Mobile IPv4. If the 
Foreign Agent advertises both its own care- of address and a GFA care-of 
address, a mobile node that supports Regional Registrations but has a Home 
Agent that doesn't, will still be able to make use of Regional 
Registrations through that GFA care-of address. A Foreign Agent that 
advertises a zero care-of address will not be backwards compatible wiht 
RFC3220, since both mobile nodes and Home Agents have to understand the 
zero care-of address. If the mobile node sets the care-of address to zero, 
the mobile node and its home agent MUST support the GFA IP address
extension."

>
> > B: Backwards compatibility with RFC3220 HA:s
> > The problem here is that an RFC 3220 HA does not understand
> > the GFA IP
> > extension used if the MN sends a registration with zero CoA.
> > There are two
> > ways to solve this:
> >
> > B1: According to the draft right now, the MN MUST NOT send a
> > Registration
> > Request with zero CoA if it's HA doesn't support that. This
> > is simple, but
> > not very flexible. If the FA advertises a GFA CoA (in
> > addition to the FA
> > CoA), the MN should use that, and can then make use of regional
> > registrations even though it's HA does not support it. If the FA only
> > advertises it's own address, the MN can not make use of regional
> > registration unless it's HA supports it, but can still use
> > normal Mobile
> > IP. An FA that only advertises a zero address will not be
> > backwards compatible.
> >
> > B2: The other alternative is that the draft could be changed
> > by adding a
> > new error code from the GFA to tell the MN that the HA did
> > not support the
> > GFA IP extension. The MN could then try the advertised CoA
> > instead (or,
> > possibly, a new extension added so the the GFA could tell the
> > MN what CoA
> > to use).
> >
> > I see one problem with this: I'm not sure how an RFC3220 HA
> > would deal with
> > this kind of registration. In the draft today, the GFA IP
> > extension is
> > non-skippable (because the HA MUST support it if the MN uses
> > it). A HA that
> > doesn't support this would not answer to this registration at
> > all, it would
> > silently discard the message.
> >
> > If the extension was changed to be skippable, how would the HA react?
> > Either it would notice that something is wrong with the CoA,
> > and send a
> > reply with some error code (e.g. "poorly formed request??).
> > Or it would not
> > even check the CoA (I couldn't find this mentioned anywhere
> > in RFC3220). In
> > this case it would accept the registration, and set the CoA
> > to zero. The
> > GFA will then receive a reply without a GFA IP extension. In
> > both cases,
> > the GFA _could_ assume that the HA did not support the GFA IP
> > extension,
> > but it doesn't know for sure.
> >
> > To conclude: this option (B2) seems too uncertain, so I would
> > rather go for
> > the (more unflexible, but simple) B1 (i.e. no changes to the
> > current draft,
> > but it could be clarified a bit).
> >

see the proposed new section 3.4 above.

/Annika

> > /Annika