Re: [mpls-linux-general] Trying to understand mpls-linux...

[James R. L. <jl...@mi...>]

Hello Rafael,

See my response inline ....

On Thu, Jul 08, 2004 at 01:29:54PM +0200, Rafael Paoliello Guimaraes wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello,
> 
> First of all, thanks for the prompt reply! Second, sorry for the
> tag-switching, but the MPLS mechanism is somehow similar to a
> tag-switching and that's why I used the expression...
> 
> Well, in fact I am looking at the 1.922 version, which is the last
> available at sourceforge. But it was quite simple to follow the code
> using your instructions. Thank you. But there are a couple of things I
> still didn't understand.
> 
> 1 - In the mpls_output2 function, the output interface is supposed to be
> known and to complete the forwarding process, you just need to switch
> the label and send the packet to the destination interface. Is it
> correct? I didn't understand why could we have an operation that returns
> MPLS_RESULT_FWD.

This is a piece of code that is needed to support more sophisticated label
forwarding.  When you see MPLS_RESULT_FWD in the output path, it is there
to handle the case where a NHLFE uses a NHLFE as the next hop (ie
hierarchical LSPs).  There are two ways to achieve hierarchy, one way is
to push multiple labels, the other is to chain NHLFE.  The later fits well
with the case where different MPLS signaling protocols learn about a separate
label in hierarchy.

> 2 - Probably a stupid question, but why are the MOIs organized in a
> radix tree if they are directly linked to a MII? I mean, once the MII is
> ~ identified, the MOI can be directly obtained without searching in the
> MOI radix tree...

They need to be stored some where so the user interface can find them :-)
(ie add/delete/bind all refer to NHLFE via an index, the index is the
key in to the tree)

> 3 - In the MII structure there is a list of MOIs (struct list_head
> ~       moi_entry). What is this? The same happens in the MOIs structure,
> where there is a list o MOIs? I thought that for each MII there was only
> one associated MOI...

This is not part of the forwarding path, these lists are required as part
of the error handling.  If the outgoing interface used by a NHLFE is
removed from the system, the NHLFE must be deleted and we need to notify
all of the ILM that link to the NHLFE that it is going away.

> Sorry for bothering you so much, but I would really link to understand
> this topics... And thank you again.
> 
> Best regards,
> 
> ===========================================
> ~ Rafael Paoliello Guimaraes
> ~ PhD Student - Computer Networking Group
> ~ Department of Computer Architecture (DAC)
> ~ Polytechnic University of Catalonia (UPC)
> ~ Phone: +34-934017187   Fax: +34-934017055
> ~ URL: http://people.ac.upc.es/rpaoliel
> ===========================================
> 
> 
> James R. Leu wrote:
> | Hello,
> |
> | First of all it's not 'tag-switching' ;-)
> |
> | Your basic understanding of what is happening is correct.
> | What version of mpls linux are you working with?  I'm going to point you
> | at code in 1.930.
> |
> | When mpls-linux initialized (see net/mpls/mpls_init.c:mpls_init_module())
> | it registers with the network stack that any packets with protocol ID
> | 0x8847 are to be sent to the function
> net/mpls/mpls_input.c:mpls_skb_recv().
> | After mpls_skb_recv() has prepared the necessary data structures and
> extracted
> | the top label (not popped, just extracts) it hands the skb off to
> mpls_input().
> | mpls_input() does an ILM lookup, then processes the instructions for
> the ILM.
> | (one of the instructions is probably a POP) If the last instruction
> was DLV
> | or PEEK and there are no more labels, the packet is delivered locally to
> | layer 3.  If the last instruction is FWD, the packet is label
> switched.  The
> | FWD instructions contains a pointer to the NHLFE that will push the
> new label
> | and TX the skb on the outgoing interface.  The FWD instruction is built in
> | net/mpls/mpls_opcode_all.c:mpls_build_opcode_fwd(), which is called
> when the
> | users binds a ILM to a NHLFE.  mpls_build_opcode_fwd() looks up a
> NHLFE via
> | the index the user provides.  So as you see there is not a NHLFE lookup
> | while the packet is being forwarded.  The only lookup that occurs is to
> | find the ILM, from that point no further lookups will occur until the
> packet
> | hits layer 3 (or the next hop does it's ILM lookup).
> |
> | I hope this give you a better understanding of how a packet gets to
> | mpls_output().  Let me know if you have any further questions.
> |
> |
> | On Wed, Jul 07, 2004 at 05:24:57PM +0200, Rafael Paoliello Guimaraes
> wrote:
> |
> | Hello All,
> |
> | I am trying to figure out the basic idea of the mpls-linux
> | implementation. I have read the "MPLS for Linux Developers' Guide" but I
> | still have some doubts, in fact I didn't understand how label switching
> | is done (I think I missed the more important part!).
> |
> | Well, as far as I understood, the device struct of network interfaces
> | are extended, so that whenever a packet arrives, a callback function
> | (mpls_in) is called. This function looks for the received label in the
> | MII radix tree and gets information about the label. Then, if the
> | packet's destination is the current node, it sends the packet to upper
> | layers. But if the packet should be forwarded, it somehow finds it's
> | output label and switchs this value in the packet. Then it sends the
> | packet to the outgoing interface.
> |
> | Is this the correct process? How does it find new label? In what data
> | structure is it stored (I suppose it is in the MOI radix tree)? Could
> | somebody please detail me how this tag switching is done in the current
> | implementation?
> |
> | Thank you very much!!!
> |
> | Best regards,
> |
> 
> - -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> mpls-linux-general mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-general
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFA7TAy8Y15Z+P2WUARAp18AJ9rgoSCjdmUBbx4cHh9mKdRvZO84QCgw0vi
> ml2eS5UuvL43sGCfJWWPObg=
> =2+7v
> -----END PGP SIGNATURE-----

-- 
James R. Leu
jl...@mi...