Re: [mpls-linux-general] Re: [MPLS-Linux] RSVP-TE (was: New mailing list)

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

On Fri, Dec 01, 2000 at 10:11:49AM +0530, Ramanjaneyulu Y T wrote:
<snip>
> > Are you refering to using RSVP-TE to create hierarchy, or are you refering
> > to how hierarchy works in general.
> 
> I am referring to create hierarcht.
>
> > 
> > If your refering to using RSVP-TE to create hierarchy, are you confused
> > about how to signal it or how (after it has been signaled) the ILM, NHLFE
> > are setup to actually do hierarchy?
> 
> 
> If I  remember right , hierarchy is achieved with help of PUSH and FWD
> operations in ILM and NHLFE . 
> 
>  Last night i refered some drafts and RSVP-TE supports Label stacks in
> LABEL object . My queastion is how LSR knows , how many labels pop ( i.e
> take off from) from LABEL object. Let me explain my probelm clealry.

When a LSR receives a labeled packet it extracts the label, bottotm of
stack bit, ttl, and EXP bits from the first shim.  It uses the label to
lookup in the ILM table associated with this interface.  The resulting ILM
entry contains an instruction of what to do.  If the operation is POP the
LSR POPs the top shim.  If the bottom of stack bit was set then the LSR looks
to the L3 PID stored in the ILM entry.  The ttl is coppied to the L3 header
and the packet is sent to the L3 protocol for porcessing.  If the bottom
of stack bit was not set, then the label, the bottom os stack bit, ttl and
EXP bits are exatrct from the next shim.  The process repeats until either
the bottom of stack bit is reached or an ILM entry with an intruction of
FWD is found.

>    LER1             LER21        LER22 ....   LER 2
>   |-----|          |-----| . .  | ----|       |-----|  
>   |     |----------|     |------|     |-------|     | 
>   |-----|          |-----|      |-----|       |-----|
> 
> 
> 
> 
> 
>        LER21 and LER22 is one MPLS domain. Suppose LER1 want to
> establish LSP to LER2. If one allows Hierarchy setting , it should make
> use of LSP between LER21 and LER22. when LER2 responded with RESV message, 
> How this RESV message is treated in MPLS domain ( beteen LSR21 and LER22)
> ?. IN normal case each LSR gets one new label for previous hop and it
> binds this with next hop label , which he got from next hop. , then it
> propagets to previous hop.
> 
>   If we r setting hierarchial lSPs , only resource reseravtion done at
> each LSR when RESV messagae comes. No label storing abd getting new label
> at each core LSRs in MPLS domain 1 , except at edge routers. So how core
> LSrs will ignore to store label info ? .

I'm a little unclear as to what you question is.  I'll give it my best shot:

      |------------EDGE TO EGDE Tunneled LSP ---------|

   ------                                           ------
  |      |                                         |      |
  |  PE  |                                         |  PE  |
  |  1   |---.  -----                   -----  .---|  2   |
   ------     \|     |                 |     |/     ------
               |  P  |-- . . . . . . --|  P  |
               |  1  |                 |  2  |
                -----                   -----

                  |----- CORE TE LSP -----|


In the above picture the core of the network is traffic engineered with RSVP-TE
with signalling starting at the P routers.  The ER HOP lists are made up of
the LSRIDs of each LSR the LSPs should traverse.

The Edge to Egde LSPs could be setup with many protocols.  So far I have
only seen providers design networks that would use LDP to build the edge to
egde LSPs.  You asked about RSVP-TE I'm 100% sure, but I know the basic
idea.

RSVP-TE signalling is initiated at the PE routes.  The ER HOP lists are
composed of LSRIDs until it reaches the core of the network, and is supposed
to tunnel inside of an existing LSP.  At which point the ER HOP is the IP
address associated with forwarding adjacency (term defined in
draft-kompella-mpls-bundle). After thet the ER HOP list is again composed
of LSRIDs.

When RSVP-TE receives a PATH message that has a top ER HOP which is associated
with a forwarding adjacency it is supposed to send the PATH message directly
to the remote LSR associated with the forwarding adjacency via normal unicast
routing. (I do not know all of the details of how that works or how the new
LSR knows that this incoming PATH message is assocaited with an FA-LSP).  When
it comes time for the RESV message, the remote LSR allocates a label and sends
it directly to this LSR via normal unicast routing.  This LSR know that the
RESV is associated with a forwarding adjacency (which is associated with an LSP)
and installes the outgoing label with the instruction to PUSH the new label
then PUSH on the label of the FA-LSP.

I hope I didn't get it too wrong :-)

Jim
-- 
James R. Leu