Re: [mpls-linux-general] Trying to understand mpls-linux...
Status: Beta
Brought to you by:
jleu
|
From: James R. L. <jl...@mi...> - 2004-07-07 16:20:27
|
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: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 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, > > - -- > > =========================================== > ~ 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 > =========================================== > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.2 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFA7BXJ8Y15Z+P2WUARAivoAKDDhqAmlMDxqt349TFOX4XzsRTkwQCfWXdV > zhL/opdcrMqY4Nb5QnJ3JMI= > =l87y > -----END PGP SIGNATURE----- > > > ------------------------------------------------------- > 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 -- James R. Leu jl...@mi... |