mpls-linux-general

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

[Rafael P. G. <raf...@ac...>]

-----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-----

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

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

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...

RE: [mpls-linux-general] help required

[Muhammad R. S. <sa...@cc...>]

I am using qdiscs and tc filters to classify and queue packets at my
ingress, and then assigning different label/EXP pairs to different flows. My
question is that do I require to maintain my QoS policies even at the LSRs,
also I want to maintain the EXP bits value throughout till the egress, for
this do I have to tell the LSR to do it or by default it would swap the
label and keep the EXP value as is.
Regards,

Muhammad R. Sami 
Research Assistant, 
Computer Engineering Department 
P.O.Box 354 
King Fahd University of Petroleum & Minerals 
Dhahran 31261 
Saudi Arabia. 
Tel: +96638601423 
Cell: +96657982951 
www.ccse.kfupm.edu.sa/sami
-----Original Message-----
From: mpl...@li...
[mailto:mpl...@li...] On Behalf Of James
R. Leu
Sent: Wednesday, July 07, 2004 7:20 PM
To: Rafael Paoliello Guimaraes
Cc: mpl...@li...
Subject: Re: [mpls-linux-general] Trying to understand mpls-linux...

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...


-------------------------------------------------------
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

Re: [mpls-linux-general] help required

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

On Wed, Jul 07, 2004 at 08:46:22PM +0300, Muhammad R. Sami wrote:
> I am using qdiscs and tc filters to classify and queue packets at my
> ingress, and then assigning different label/EXP pairs to different flows. My
> question is that do I require to maintain my QoS policies even at the LSRs,
> also I want to maintain the EXP bits value throughout till the egress, for
> this do I have to tell the LSR to do it or by default it would swap the
> label and keep the EXP value as is.
> Regards,
> 

In a fully diffserv aware MPLS network every node (even LSRs) apply some
sort of PHB to the packets as they traverse the LSPs.  So the short answer
is yes, I would think you would want to want to install QoS policies on the
LSRs.

I have not verified this, but it is my theory that the EXP values will be
preserved at LSRs that do not interpret them.  Looking at the code it looks
like I "pop" the EXP bits from the top label and popogate then to the "pushed"
label.  I'm not sure I thought through the hierachy cases though, so if
you plan on popping or pushing more then one label your results may vary :-)

Also, after you have a working setup, I know I, and I'm sure others, would
like to see any scripts or examples of your configuration that you can provide.

Thanks

> Muhammad R. Sami 
> Research Assistant, 
> Computer Engineering Department 
> P.O.Box 354 
> King Fahd University of Petroleum & Minerals 
> Dhahran 31261 
> Saudi Arabia. 
> Tel: +96638601423 
> Cell: +96657982951 
> www.ccse.kfupm.edu.sa/sami
> -----Original Message-----
> From: mpl...@li...
> [mailto:mpl...@li...] On Behalf Of James
> R. Leu
> Sent: Wednesday, July 07, 2004 7:20 PM
> To: Rafael Paoliello Guimaraes
> Cc: mpl...@li...
> Subject: Re: [mpls-linux-general] Trying to understand mpls-linux...
> 
> 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...
> 
> 
> -------------------------------------------------------
> 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...

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

[Rafael P. G. <raf...@ac...>]

-----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.

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...

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...

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-----

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...

[mpls-linux-general] Problems in configuring multiple LSPs on same physical link

[Muhammad R. S. <sa...@cc...>]

I am having problems in configuring multiple LSPs on the same physical link
destined to a single IP address (hop).  The message I get is "RTNETLI NK:
File exists". Am I doing something wrong or is this not possible. If it is
not possible to configure multiple LSPs to a single IP address on the same
physical link, can I use virtual links to accomplish this task?
Regards,

Muhammad R. Sami 
Research Assistant, 
Computer Engineering Department 
P.O.Box 354 
King Fahd University of Petroleum & Minerals 
Dhahran 31261 
Saudi Arabia. 
Tel: +96638601423 
Cell: +96657982951 
www.ccse.kfupm.edu.sa/sami
-----Original Message-----
From: mpl...@li...
[mailto:mpl...@li...] On Behalf Of James
R. Leu
Sent: Thursday, July 08, 2004 5:34 PM
To: Rafael Paoliello Guimaraes
Cc: mpl...@li...
Subject: Re: [mpls-linux-general] Trying to understand mpls-linux...

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...


-------------------------------------------------------
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

Re: [mpls-linux-general] Problems in configuring multiple LSPs on same physical link

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

Can you send me the commands you are issuing and the MPLS kernel debugging
from when thoses commads are issued?

On Sat, Jul 10, 2004 at 05:10:37AM +0300, Muhammad R. Sami wrote:
> I am having problems in configuring multiple LSPs on the same physical link
> destined to a single IP address (hop).  The message I get is "RTNETLI NK:
> File exists". Am I doing something wrong or is this not possible. If it is
> not possible to configure multiple LSPs to a single IP address on the same
> physical link, can I use virtual links to accomplish this task?
> Regards,
> 
> Muhammad R. Sami 
> Research Assistant, 
> Computer Engineering Department 
> P.O.Box 354 
> King Fahd University of Petroleum & Minerals 
> Dhahran 31261 
> Saudi Arabia. 
> Tel: +96638601423 
> Cell: +96657982951 
> www.ccse.kfupm.edu.sa/sami
> -----Original Message-----
> From: mpl...@li...
> [mailto:mpl...@li...] On Behalf Of James
> R. Leu
> Sent: Thursday, July 08, 2004 5:34 PM
> To: Rafael Paoliello Guimaraes
> Cc: mpl...@li...
> Subject: Re: [mpls-linux-general] Trying to understand mpls-linux...
> 
> 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...
> 
> 
> -------------------------------------------------------
> 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...

RE: [mpls-linux-general] Problems in configuring multiple LSPs on same physical link

[Muhammad R. S. <sa...@cc...>]

When I give another route to the same destination IP address with different
label, then I get the RTNETLINK error message: file exists. So I assume that
there is something wrong with iproute2. below are my configuration commands:

---MPLS commands @ ingress-----

./mplsadm2 -A -0 0
./mplsadm2 -0 0x2 -o push:gen:60:set:eth0:ipv4: 172.16.1.2
./mplsadm2 -A -0 0
./mplsadm2 -0 0x3 -o push:gen:70:set:eth0:ipv4: 172.16.1.2

------iproute2 commands @ ingress-----

./ip route add 192.168.11.2/32 via 172.16.1.2 spec_nh 0x8847 0x2
./ip route add 192.168.11.2/32 via 172.16.1.2 spec_nh 0x8847 0x3
RTNETLINK answers: file exists


Is this because in both cases, the next hop is same, but for me this is
necessary, cuz this is what I want to do:


Ingress------------------LSR---------LSR1
			\
			  \
			    \
  			      \
		            	    LSR2

Muhammad R. Sami 
Research Assistant, 
Computer Engineering Department 
P.O.Box 354 
King Fahd University of Petroleum & Minerals 
Dhahran 31261 
Saudi Arabia. 
Tel: +96638601423 
Cell: +96657982951 
www.ccse.kfupm.edu.sa/sami
-----Original Message-----
From: James R. Leu [mailto:jl...@mi...] 
Sent: Sunday, July 11, 2004 5:52 AM
To: Muhammad R. Sami
Cc: mpl...@li...
Subject: Re: [mpls-linux-general] Problems in configuring multiple LSPs on
same physical link

Can you send me the commands you are issuing and the MPLS kernel debugging
from when thoses commads are issued?

On Sat, Jul 10, 2004 at 05:10:37AM +0300, Muhammad R. Sami wrote:
> I am having problems in configuring multiple LSPs on the same physical
link
> destined to a single IP address (hop).  The message I get is "RTNETLI NK:
> File exists". Am I doing something wrong or is this not possible. If it is
> not possible to configure multiple LSPs to a single IP address on the same
> physical link, can I use virtual links to accomplish this task?
> Regards,
> 
> Muhammad R. Sami 
> Research Assistant, 
> Computer Engineering Department 
> P.O.Box 354 
> King Fahd University of Petroleum & Minerals 
> Dhahran 31261 
> Saudi Arabia. 
> Tel: +96638601423 
> Cell: +96657982951 
> www.ccse.kfupm.edu.sa/sami
> -----Original Message-----
> From: mpl...@li...
> [mailto:mpl...@li...] On Behalf Of James
> R. Leu
> Sent: Thursday, July 08, 2004 5:34 PM
> To: Rafael Paoliello Guimaraes
> Cc: mpl...@li...
> Subject: Re: [mpls-linux-general] Trying to understand mpls-linux...
> 
> 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...
> 
> 
> -------------------------------------------------------
> 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...