Subject: [Mipshop] RE: on 'Dist' field

From: Soliman Hesham <[email-masked]>
Date: Mon, 24 Nov 2003 10:46:24 -0500

Gab, 

I'll clarify the text you quote below in the next rev. The "hierarchy"
in the text you quote was referring to a hierarchy
of routers, not MAPs, i.e. the routers in the core
network of the operator. Obviously a better word is needed
here given the confusion with the title. 

This text from section 10.1 indicates (not strongly) that
one level of hierarchy exists:

   There are no benefits foreseen in selecting more than one MAP and 
   forcing packets to be sent from the higher MAP down through a 
   hierarchy of MAPs. This approach may add forwarding delays and 
   eliminate the robustness of IP routing between the highest MAP and 
   the mobile node. Hence, allowing more than one MAP (above the AR) 
   within a network should not imply that the mobile node forces packets 
   to be routed down the hierarchy of MAPs. However, placing more than 
   one MAP above the AR can be used for redundancy and as an 
   optimisation for the different mobility scenarios experienced by 
   mobile nodes. The MAPs are used independently from each other by the 
   MN (e.g. each MAP is used for communication to a certain set of CNs).

I'll add text to make this clearer in the introduction and MN operations
sections, is this ok? Also the scenario in the last sentence above
should be discouraged (i.e. a MAP for a set of CNs). 

Hesham

 > Soliman Hesham wrote:
 > >>The 'Dist' field seems to be the number of levels of MAP hierarchy
 > >>if one updates them via the dynamic MAP technique. If so, 
 > perhaps saying
 > >>so would help. 
 > > 
 > > 
 > > => The Dist field is there to tell the MN how "far"
 > > the MAP is. There is only one level of hierarchy in HMIPv6, 
 > 
 > Is this an unspoken assumption? If so, it must be made explicit.
 > These statements are why I thought there were multiple levels:
 > 
 >     For these reasons a new Mobile IPv6 node, called the 
 > Mobility Anchor
 >     Point is used and can be located at any level in a hierarchical
 >     network of routers, including the Access Router (AR).
 > 
 > ...
 >     In this manner, information about a MAP at a certain level in a
 >     hierarchy can be dynamically passed to a mobile node.
 > ...
 > 
 >     The MAP option is propagated down the hierarchy. Each 
 > router along
 >     the path to the access router will increment the 
 > Distance field by
 >     one. If a router that is also a MAP receives advertisements from
 >     other MAPs, it MUST add its own MAP option and propagate 
 > both options
 >     to the next level in the hierarchy.
 > 
 > The above mandates that at each level of the hierarchy the 'Dist'
 > value get incremented by one. If this is incorrect, then 
 > there's work to do
 > in clearing all this up.
 > 
 > > so the Dist doesn't say anything about levels of hierarchy.
 > 
 > Not what the text implies.
 > 
 > > The purpose of this field is to aid the MN in selecting
 > > the right MAP. The knowledge that the MN should have in order
 > > to use this field is really link layer specific (i.e.
 > > speed for instance) so we couldn't put more info than
 > > that in the draft. I can add more text to explain this.
 > 
 > Please, specially if you're using this in conjunction with link-layer
 > specific information.
 > 
 > >>Also, it is not clear if the proper use of this field
 > >>implies that the newly arriving MN should spend some time 
 > in learning
 > >>mode before it hears about the different values of 'Dist'. 
 > In one of the
 > >>MAP discovery schemes (dynamic scheme) all 'Dist' values 
 > within any 
 > >>given branch of the hierarchical tree are supposed to be available
 > >>in a MAP advertisement.
 > > 
 > > 
 > > => There is no "hierarchical tree", perhaps this should
 > > be made clearer, i.e. there are no tree-based hierarchies 
 > in HMIPv6. 
 > > All MAP options are advertised within a MAP domain, independently
 > > of the MAP discovery mechanism. The MN would listen to MAP
 > > options in the RA when it moves, or before movement (if 
 > > anticipation is used).
 > 
 > Yes, perhaps needs to be made clearer. Things like this:
 > 
 >     Upon reception of a router advertisement with the MAP option, the
 >     receiving router MUST copy the option and re-send it after
 >     incrementing the Distance field by one.
 > 
 > imply that there is. If so, some comments below may still 
 > apply. I'll stop here
 > to wait for further clarification.
 > 
 > tnx,
 > 
 > -gabriel
 > 
 > > 
 > > 
 > >  But this says nothing of the other branches.
 > > 
 > >>Nor of MAP discovery via other methods. If the MN must 
 > learn, should
 > >>there be an indication that this is the case? 
 > > 
 > > 
 > > => I'm not sure I follow. This is taken out of section 2.1:
 > > 
 > >    Upon arrival in a visited network, the mobile node will 
 > discover the 
 > >    global address of the MAP. This address is stored in the Access 
 > >    Routers and communicated to the mobile node via Router 
 > Advertisements 
 > >    (RAs). A new option for RAs is proposed later in this 
 > specification. 
 > >    This is needed to inform mobile nodes about the 
 > presence of the MAP 
 > >    (MAP discovery). The discovery phase will also inform 
 > the mobile node 
 > >    of the distance of the MAP from the mobile node. For 
 > example, the MAP 
 > >    function could be implemented as shown in Figure 1 and 
 > at the same 
 > >    time also in AR1 and AR2. In this case the mobile node 
 > can choose the 
 > >    first hop MAP or one further in the hierarchy of 
 > routers. The details 
 > >    on how to choose a MAP are provided in section 10. 
 > >     
 > >    The process of MAP discovery continues as the mobile 
 > node moves from 
 > >    one subnet to the next. As the mobile node roams within 
 > a MAP domain, 
 > > 
 > >    ARs are configured to announce the same MAP address or 
 > addresses. If 
 > >    a change in the advertised MAP's address is received, 
 > the mobile node 
 > >    MUST act on the change by performing movement detection 
 > and sending 
 > >    the necessary Binding Updates to its HA and 
 > correspondent nodes. 
 > > 
 > > Does this clarify the issue for the MN?
 > > 
 > > 
 > > 
 > >>But if learning is in order, does this add delay precisely during
 > >>the handoff period when things are supposed to run quickly? 
 > > 
 > > 
 > > => No more delays than movement detection. The "learning" means
 > > being able to parse the MAP option and understanding it. Bascially,
 > > like any other option in the RA.
 > > 
 > > 
 > >>Or are
 > >>MAP advertisements possible to learn before arriving in 
 > that particular
 > >>branch of the hierarchy. 
 > > 
 > > 
 > > => If we decide to have a framework for merger of HMIP and 
 > FMIP, we 
 > > would allow the MN to learn the MAP option before it moves.
 > > This is already possible btw, FMIP ARs send rtr_adv for proxy
 > > to the MN before it moves. The MAP option can be included in
 > > those RAs. 
 > > 
 > 

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

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 24 Nov 2003 21:29:06 +0100

> one level of hierarchy exists:

Ok, thanks.

<snip>

> should be discouraged (i.e. a MAP for a set of CNs). 

Sounds good, thanks.

-gabriel